Patent Grant
8458467
This application claims the benefit under 35 U.S.C. §119(e) of provisional application 60/692,715, filed Jun. 21, 2005, the entire contents of which is hereby incorporated by reference as if fully set forth herein. This application is generally related to prior application Ser. No. 10/991,792, filed Nov. 17, 2004.
The present invention generally relates to data processing techniques performed within network infrastructure elements such as routers and switches. The invention relates more specifically to techniques for transforming network message payloads into different internal formats.
The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Software applications operating in a network environment produce or consume application messages. For example, a client software element hosted at an end station device such as a personal computer or workstation may form and send a message to a corresponding application server that is hosted in a network. Each message typically comprises one or more headers and a payload that contains application-specific information. Messages may be contained in more than one data frame, packet, segment, or other unit of organization under a network communication protocol. In the description herein, a “message” is a set of data relating to an application and associated with Layer 5, 6 or 7 of the OSI network reference model.
Such application-layer messages often need to be changed or transformed so that applications consuming the messages can handle them. These messages can arrive at a network device over different lower-layer protocols, such as HTTP, HTTPS, JMS, MQ, RV, and certain proprietary protocols that use TCP or UDP as a transport. Typically, a receiving application must receive a message in a particular format that the application understands. As a result, some intermediary processing unit must transform an inbound message to the required format for the application.
Generally, in past approaches such transformations have been performed using applications or mechanisms that are running on a host associated with an application endpoint. For example, an application server may include transformation logic. But as applications and their message formats evolve, each sending and receiving application is required to accommodate an increasing number of different application-layer message formats. The transformation logic at each application server requires modification to accommodate new formats. This is time-consuming and requires significant resources in programming labor. There is a need for an improved approach for performing application-layer transformation that does not require re-coding or modifying application servers, clients, or other end stations.
Further, in typical past approaches, application message transformation is performed either by an application consuming the message, or by a process or mechanisms running on a host on behalf of the application consuming the message. Alternatively, message transformation is performed by the application producing the message, based on the target application endpoint.
In all these cases, the number of points at which transformation is performed increases based on the number of application endpoints producing or consuming the message. For example, if seven instances of a database application were hosted in a particular server, then in the conventional approach, all seven instances would have to perform message payload transformation. This is a waste of application processing resources. There is a need for a more efficient approach that can somehow consolidate, at a single processing point, all message payload transformation work for a plurality of instances of an application or for multiple different applications.
One approach for performing message transformation is described in prior application Ser. No. 10/991,792, filed Nov. 17, 2004, of Pravin Singhal et al. (“Singhal et al.”), and assigned to the assignee hereof. The approach of Singhal et al. provides mechanisms for transport protocol message brokering. For example, the approach of Singhal et al. can receive a message that uses the HTTP protocol and change that message into an MQ message. However, the approach of Singhal et al. does not change, modify or transform data contained within a payload portion of the inbound message. Thus, if an inbound HTTP message contains an XML document as a payload, but a receiving application requires a particular kind of FIX or COBOL CopyBook message payload as input, the approach of Singhal does not provide a solution. In contrast, Singhal et al. would be able to change the inbound HTTP message into an IBM MQ message carrying the same XML document as a payload.
Further, if the inbound message has an XML payload containing a “date” data field that is expressed in “MMDDYY” format, but the receiving application requires all dates to be expressed in “YYYYMMDD” format, the approach of Singhal does not provide a solution.
Thus, based on the clear deficiencies of past approaches, there is a need for an approach that can perform message payload transformation independent of the application transport protocols that carry such payloads.
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
A method and apparatus for application message payload transformation in a network infrastructure element are described. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.
Embodiments are described herein according to the following outline:
1.0 General Overview
The needs identified in the foregoing Background, and other needs and objects that will become apparent for the following description, are achieved in the present invention, which comprises, in one aspect, a data processing apparatus comprising a plurality of network interfaces that are coupled to a data network for receiving one or more packets therefrom and sending one or more packets thereto; one or more processors; a switching system coupled to the one or more processors and packet forwarding logic, wherein the switching system and packet forwarding logic are configured to receive packets on a first network interface, determine a second network interface on which to send the packets, and to send the packets on the second network interface; and application message transformation logic comprising one or more stored sequences of instructions which, when executed by the one or more processors, cause the one or more processors to perform: receiving one or more packets representing an input application message logically associated with OSI network model Layer 5 or above; extracting an application message payload from the input application message; identifying one or more first content elements in the application message payload; transforming the first content elements into one or more second content elements of an output application message; and forwarding the output application message to a destination that is identified in the input application message.
In one feature of this aspect, the apparatus further comprises sequences of instructions which, when executed by the processor, cause the processor to perform transforming the first content elements into one or more second content elements of an output application message by any of field reordering, field enrichment, field filtering, and presentation transformation.
In another feature, the apparatus further comprises sequences of instructions which, when executed by the processor, cause the processor to perform transforming the first content elements into one or more second content elements of an output application message by any one of: structural reordering; complex map, schema, and dictionary-based transformation; content formatting at the presentation layer, such as XML to HTML and WML transformation, or transformation based on required media types of the receiver; personalization; security credential mapping; content aggregation; content splitting; service interface virtualization; performing content-based lookup, extraction, routing and distribution; content validation; data validation; and code page translation.
In a further feature, the application message payload transformation logic comprises a transformer bladelet that uses a transformation service, and a transformer factory that creates a transformer function that is registered in the transformation service. In another feature, the transformer function is coupled to an extensible XSLT transformer that comprises an XSLT processor and an XML reader. In yet another feature, the transformer function comprises a translet-based transformation function, and wherein the transformer function is coupled to an XSLTC compiler, and wherein the transformer function comprises logic configured to invoke the XSLTC compiler to compile an XSL transform file into one or more translets.
In still another feature, the apparatus comprises any of a packet data router and a packet data switch in a packet-switched network. In yet another feature, a transformation policy is received, and specifies what transformation operations to perform on the application message payload, which translator to use, and a content type of the output message, and the transforming step is performed based on the transformation policy.
In other aspects, the invention encompasses a machine-implemented method and a computer-readable medium configured to carry out the foregoing steps.
2.0 Structural and Functional Overview
Referring first to
A commercial embodiment of network elements 110A may comprise routers or switches from Cisco Systems, Inc., San Jose, Calif., with blades having Application-Oriented Networking Services (AONS) capabilities. In some embodiments, network elements 110A are termed “AONS nodes” or “AONS endpoints.” Other network elements 10B may be non-AONS nodes. Further, network elements 110A need not use Cisco AONS technology; the network elements can comprise routers or switches that use other internal elements for performing message inspection, processing or transformation within the network elements. Thus, the use of AONS in an embodiment is not required, and all references herein to AONS elements are provided merely to illustrate a clear example, and not as limitations.
As seen in
AONS endpoints may use different formats for the messages that they produce or consume. For example, a message produced by an endpoint may conform to a format that may be different from the format expected by an endpoint that consumes the message. Further an endpoint may produce or consume XML or non-XML messages or use a different structure for message content. In the example of
In other examples, transformation of an application message payload may be needed for the sender 102 and receiver 106 to communicate and process requests and responses. Example message payload transformations include field reordering, field enrichment, field filtering, and presentation transformation.
In Field Reordering, sender 102 sends a message that contains fields in a certain order that is different from an order that receiver 106 requires. For example, sender 102 sends a message with the fields of Table 1A below, but receiver 106 requires fields in the order of Table 1B:
In Field Enrichment and Field Filtering, sender 102 sends some information that receiver 106 does not expect. Thus, the information needs to be filtered so that receiver 106 can correctly process the message. For example, sender 102 may include a <middle-name> field in data representing a person in a shipping address, but the receiver 106 may not expect that field. In response, in the approach herein an application message payload transformation process removes the unexpected field before delivering the message to the receiver 106. Alternatively, if receiver 106 does expect a middle name field but sender 102 sends a message that does not have that field, then the application message payload transformation logic 108 inserts an empty middle-name field.
In Presentation Transformation, a message payload is transformed to conform to a specific presentation format that the receiver 106 expects. For example, assume that receiver 106 sends a response carrying an XML payload, but sender 102 needs to display the response on a browser associated with the sender. The application message payload transformation logic 108 transforms the XML data into an HTML document and places the HTML document into the message payload before forwarding the message to the sender 102. As a result, sender 102 can display the content of the payload. Alternatively, if the receiver 106 is using a device that requires content in a message payload to be displayed be in WML, then the application message payload transformation logic 108 converts the message payload to WML so that the receiver can correctly display the content.
As another example, the application message payload transformation logic 108 can transform a non-XML message payload to a corresponding XML format. For example, assume that a message payload that is in CSV format needs to be presented to receiver 106 in an XML format. Alternatively, assume that sender 102 sends a FIX message, but receiver 106 expects the message to be in FIXML format. In both cases, the application message payload transformation logic 108 transforms the payload from FIX format to FIXML format and forwards the message to the receiver 106.
Generally, in all the preceding cases, the application message payload transformation logic 108 performs a transformation function on an in-coming message and produces an out-going message. In an embodiment, local network 112 is associated with one or more receiving application servers 106A, which host one or more instances of one or more applications. Thus, in the arrangement of
Alternatively, if router 110 is located in local network 103, the router can perform application message payload transformation when sender 102 emits messages and before the messages reach the application servers 106A. In all such cases, the data processing efficiency of the application servers 106A is greatly improved because router 110 is responsible for message transformation, and the application servers are responsible only for performing substantive application functions.
Thus, according to one embodiment, message payload transformation is performed in a network device based on the requirements of a consuming application. In this approach, a message is transformed outside the application producing or consuming such message. In a specific embodiment, message payload transformation is performed in a network infrastructure element, such as a router or a switch in a packet-switched network.
When message payload transformation is performed in a network device, the transformation can be performed on a device that is closer to the application that is producing the message or the application that is consuming the message. As a result, if there are multiple instances of an application running, possibly on different hosts, then a single device through which all the messages are passing can perform the needed transformation. Accordingly, efficiency of the overall network is improved.
In an embodiment, message payload transformation is specified by declarative policies based on the source and target endpoints of the application and contents of the message. A policy can define a “custom” message payload transformation in terms of particular message attributes, variables or values. A policy defines what part of a message is operated upon, how to transform the message, and the form of the output. The policies can be deployed on a network device at which the message payload transformation is performed.
In this approach, applications do not need to change based on changes in the kind of message that the applications consume. Further, when message payload transformation is performed on a network device, the transformation can be performed at fewer locations in the network, thus reducing application processing resources.
In one embodiment, XSLT-based Transformation Engines perform XML and non-XML message transformation. The XSLT-based Transformation Engines implement the XSLT 1.x and XSLT 2.0 specifications as defined by the W3C consortium (w3c.org). At the time of this writing, XSLT specifications are available online in the folder /TR/xslt of the domain “w3c.org” on the World Wide Web. In one embodiment, the application message payload transformation logic 108 is extensible in its use of XSLT processor. Thus, the application message payload transformation logic 108 is structured to allow the use of a different XSLT processor if required.
In an embodiment, the application message payload transformation logic 108 is extensible. The application message payload transformation logic 108 can be augmented by integrating a third party application that provides a specialized transformation function. For example, a scriptlet can be used to build a transformation component that uses a third-party tool or application. The application message payload transformation logic 108 performs transformations only on message payloads, and is not involved in the transport mechanism that is used to move the message among network elements.
Extensions to the application message payload transformation logic 108 can be implemented by providing a Parser Plugin and Custom Transformer extension. In an embodiment, the Parser Plugin and Custom Transformer extension are JAVA language object implementations, and are developed using the JAVA development environment. For example, creating a Parser Plugin Package in JAVA can be performed to extend the application message payload transformation logic 108.
In one embodiment, Transform and Transform Parser bundles, Transformation Policies, Transformation Flows are created and deployed to network elements 106. After such deployment, network elements 106 can receive and transform messages. In an embodiment, application message payload transformation logic 108 performs one or more message payload transformations include any of field reordering, field enrichment, field filtering, and presentation transformation. Such transformations may include structural reordering; complex map, schema, and dictionary-based transformation; content formatting at the presentation layer, such as XML to HTML and WML transformation, or transformation based on required media types of the receiver; personalization; security credential mapping; and other transformations.
Transformations also may include content aggregation and splitting. For example, multiple MIME parts in a message can be aggregated or split. In a SOAP message, the headers can be split from the body and each piece can be used in different ways. The aggregation, splitting, enrichment, filtering, and mapping techniques described herein can be implemented to provide interoperability of application messages across different standards. Further, content encoding can be performed. Service interface virtualization techniques can be achieved by using transformations to carry out interface splitting and interface versioning.
Further, application message payload transformation logic 108 may be configured to parse message content and then perform content-based lookup, extraction, routing and distribution. For example, a transformation can specify extracting particular content from an application message payload, placing the content in a new message, and distributing the new message to another node, such as a monitoring node.
Additionally or alternatively, application message payload transformation logic 108 may be configured to perform content validation and data validation based on data structure and data type, for either a source message or destination message. In this embodiment, application message payload transformation logic 108 examines payload field values and determines, based on a transformation schema, whether the field values are valid in terms of structure and content. If field values are not valid, then the transformation schema specifies how to transform the values into valid values. Thus, semantic message content transformation for an application payload can be performed.
Additionally or alternatively, application message payload transformation logic 108 may be configured to perform code page translation. In code page translation, normalized content as maintained by a service (e.g., Unicode character encoded content) is mapped to a locale-specific content encoding. Elements representing times, dates, calendar entries, etc., can be transformed into an encoding or format that a receiving application requires. Alternatively, a request message that conforms to a locally required content encoding may be transformed into a normalized content encoding and then sent to a service.
Embodiments allow adaptation and extension of the mechanisms that perform application message payload transformation. For example, an administrator or other user can add new or different XSLT Transforms, Parser Plugin Transforms, or Custom Transforms to accomplish particular desired forms of application message payload transformation. Thus, the user can build upon existing transform logic that is available, using transforms that have been uploaded by the same user or other user. Therefore, a user can dynamically apply transform logic without bringing down the host device to install new software.
Further, “chain” transformation processing is supported in which a network element may apply transform logic successively on an application message payload. Thus, more than one transform may be applied successively to a content payload that is retrieved from an incoming message before the payload is transformed into result content in an outgoing message. In an embodiment, an overall transform step comprises one or more transform steps, implemented in one or more transform bladelets in a workflow that successively transforms the content.
Embodiments are implemented in network elements such as routers and switches. As a result, embodiments implement the notion of sandboxing, in which message transformation is performed within a network element before messages reach applications. This approach provides isolation of the transformation functions and allows a single network element to transform all messages destined to multiple instances of an application.
3.0 Application Message Payload Transformation Approaches
This section describes functions performed to accomplish application message payload transformation for an incoming message represented in an XML format.
3.1 XSLT-Based Transformation
In one embodiment, XSL Transform (“XSLT”) based transformation is performed. In this approach, an XSLT specifies how an input message is transformed to produce an output message.
The XSLT is created in advance of message processing, based on known schema of input messages and output messages. The XSLT can be created using any existing XSLT design tool. During runtime, an XSLT processor in the application message payload transformation logic 108 receives the XSLT and an input message. The XSLT processor applies the transform to the message and produces an output message. The application message payload transformation logic 108 then directs other functional elements of the network element 106 to forward the message to its destination.
The XSLT can produce an output message having an XML payload or a non-XML payload.
In another embodiment, when a non-XML input message is used, during design time an extension to the AON Message Parser component is made and registered with AON so that a non-XML input message can be parsed to produce a corresponding DOM Source 206, or emit SAX events that a SAX reader 208 reads, for an equivalent XML input message. The DOM Source 206, or output of the SAX reader 208 after processing by a SAX transformation handler 212, provides the XSLT translator 202 with input equivalent to an XML input message. The translator 202 applies a previously created XSLT transform 210 to the message, resulting in generating an output message 214.
Thus, the xmlDoc reader, non-XML Doc Reader, CSV Reader, and FIX Reader referenced in
In one embodiment, translator 202 comprises the XALAN processor, which is supplied with the JAVA Development Kit from Sun Microsystems, Inc. Alternatively, the JD-XSLT processor may be used.
The binary Translets files 216 are used to transform an incoming message to an out-going message. Once XSL transforms are compiled, Translet classes are created and can be packaged in a JAR file and made available to the XSLTC translator 202. During runtime, the XSLTC translator 202 uses the Translets to apply a transformation to an incoming message.
3.2 Message Flow within a Network Element
In one embodiment that is implemented using Cisco AONS, transformation of data present in a message is accomplished by designing a flow comprising of three tasks: data extraction, transformation and composition. Each of the tasks is implemented using an AONS Bladelet. An input message is processed through various components before data present in the message is transformed and put in the outbound message, as now described.
In step 2, a Transformer Bladelet 306 receives a list of content to transform and a transform profile name. Based on the transform profile, the Transform Bladelet 306 transforms contents from the input content list by invoking a transform handler (step 3) of the XSLT transformer 202. The invocation of step 3 causes the XSLT transformer 202 to invoke a runtime element of XSLT processor 310, at step 3a.
The Transform Bladelet 306 receives an additional parameter (not shown) to decide if the contents in the input content list should be replaced by the transformed contents. If not, the Transform Bladelet 306 places the transformed contents in an output content list flow variable, which is passed to MIMEBuilder 308, which takes the transformed contents from the flow variable content list and takes a MIME Content object. The MIMEBuilder element attaches the transformed content and creates an output MIME content object.
A CreateMessage Bladelet 312 takes the MIME content object that has the transformed content, creates an output message 314, and sends the output message to the indicated destination using the parameters from the inbound message 302. In an embodiment, all steps of
In one embodiment, the transformation algorithms and logic described herein are implemented in a Transformation Bladelet and Transformation Service, which are described further herein. In general, the Transformation Bladelet receives an input content list and applies a transformation to result in creating an outgoing transformed content list. The Transformation Bladelet also receives an overwrite option, which specifies whether the contents in the input content list should be replaced by the corresponding result content. The Transformation Bladelet also receives two profile parameters; a first profile parameter specifies a style sheet to use, and the second profile parameter specifies a specific parser plug-in to use.
As indicated at step 404, for each content element in the input content list, the following steps are performed. In step 406, a content element is selected from the list, and a transform Source object (in Src) is created. In one embodiment, step 406 comprises determining whether a content stream is available (step 408), and if so, creating a stream source (step 410). Applications sometimes use content streams as a means for reducing the memory requirements for storing message payloads. Otherwise, as tested at step 412, if the content element comprises XML or SOAP content, then a DOM Source is created at step 414.
In step 416, a Stream Result object is created to hold the result of the transformation. Streaming transform for XML (STX) may be used to create stream results.
In step 418, a TransformService.transform method is invoked. The following elements are passed to the method: in Src, styleSheetProfile, parserPluginProfile. A “result” variable of the method contains the result of the transformation.
In step 420, a resultContent object is prepared from the result of the transformation. In one embodiment, step 420 involves inspecting the content to determine if it is XML content, and if so, creating an XML result content value from the result data returned in step 418. Otherwise, the result is in stream content.
As indicated at step 422, if more content is present in the input content list, then control transfers to step 404.
At step 424, if the overwrite flag is true, then in step 426 the contents in the input content list are replaced with the corresponding result content object.
In step 428, the result of the content object list is placed in the flow variable TransformedContents. In step 430, the output Path Success is set and control returns to a calling method. When the process of
If an exception occurs, as indicated at step 432, a BladeletException is created and the exception is thrown.
3.3 Transformation Design Example
This section describes parameters that may be used, in one embodiment, with the Transformation Bladelet and Transformation Service.
3.3.1 Transformation Bladelet and Parameters
This section describes input, output and exported parameters for the Transformation Bladelet, according to one embodiment. In an embodiment, input parameters include “Input,” “OverwriteContent,” “Stylesheet Profile,” “ParserPluginProfile,” and “Update Message.”
The Input Parameter has the type ContentListIterator. This parameter specifies a list of contents to be transformed. Content can be XML or SOAP content, or stream content that may have some non-XML data.
The OverwriteContent parameter is a Boolean value that specifies if the contents in the input list should be replaced with the transformed contents. If true, the input contents are replaced with the transformed result content. If false, a list is created with the resulting transformed contents, and the list is exported in the TransformationResult flow variable.
The StylesheetProfile parameter is a Policy parameter that specifies the name of the transformation profile to use. Each transformation profile comprises information about which XSLT Transform file to use, Vendor name and Transform Package name. Using the attributes defined in a profile, the transformation service selects a transform from a vendor-specific transform package and applies the transform to the input parameter. A profile also can specify a particular XSLT Processor to use.
The ParserPluginProfile is a Policy parameter that specifies a parser plugin profile. It also specifies a default factory for XSLT based transformation. Customer developed parser plugin to parse specific non-xml content can be provided ain transform parser bundle and can be specified in this profile.
The UpdateMessage parameter is a Message that specifies if message content should be replaced by transformed content. The UpdateMessage parameter can take a flow variable value that corresponds to request or response message.
In an embodiment, one output parameter is provided and comprises a TransformedContents parameter of type ContentListlterator. The Transformed Contents parameter defines a flow variable that contains the list of transformed contents.
In an embodiment, one exception is defined, and may be named the Transform-Failures exception. If the transformation operations defined herein are successful, an output path of Success is set. However, if an exception occurs, an exception ID is set, and a recoverable Bladelet Exception is thrown. An exception can occur, for example, due to an incorrect transformation or parser profile, bad input data, use of a bad transform, etc.
3.3.2 Transformation Policy Configuration
In one embodiment, a transformation policy file defines a set of properties that specify which XSLT Transform to use from a specific Transform Bundle. Table 2 identifies example attribute names and attribute descriptions that can be used in an implementation.
3.3.3 Transform Parser Policy Configuration
In an embodiment, a transformation parser policy file defines a set of properties that specify a Content Parser Plugin to use in transformation. Table 3 identifies example attribute names and attribute descriptions that may be used in an embodiment.
3.3.4 Class Implementation
Table 4 describes interfaces and classes that can be used to implement a transformation service.
The Transformation Service class of
The Parser Extension class of
A transformation server 710 runs logically on the preceding elements of
A transformation bladelet 712 runs logically on the transformation service and performs the functions previously described to generate one or more transformed messages 714. The transformation bladelet 712 also can generate first and second messages 716, 718 or signals indicating whether a message was transformed (message 716) or not transformed (message 718).
One or more transformation functions 720 are coupled to transformation bladelet 712 and determine what specific transformation operations are performed. For example, an XSLT-based transformation function 722 may comprise a mapping of name-value pairs for input messages and output messages. Functions 720 include an enumeration 724 of all installed functions and a result transformation 726 that indicates how to map the source message to a flow variable for output.
3.3.5 Creating and Deploying Transformations
Referring first to
At step 4, an administrator logs in to a configuration and provisioning server. At step 5, the administrator initiates an upload function. As shown at step 6, the XSLT style sheets or custom code that was stored at step 3 is uploaded from the file system to the configuration and provisioning server, and packaged appropriately for provisioning or deployment. At step 7, the XSLT style sheets or custom transformation code is provisioned to a network device 110.
In one embodiment, the network device 110 hosts an AONS Design Studio (ADS) application and an AONS blade.
Referring now to
The transform bundle and the transform parser plugin bundle are uploaded and registered in an AONS management application as follows. The user logs on to an AONS Management Console (AMC) 604 that the user uses to manage one or more AONS nodes 606 in the user's network. The user selects the Admin Tab, selects the Transform button, and selects the Upload Transform Package menu item. The user selects the transform bundle file 608 file and clicks UPLOAD. In response, the user interface displays all extensions provided in the package. The user selects Register to register the extensions in AMC 604. The same steps are followed to load the transform parser plugin bundle 610 for registering any transform parser extensions.
Registration causes AMC 604 to create and store a transform policy 612 that references the transform bundle 608 and contains an instantiated class based on the XSLT transform specified in the transform bundle 608. Registration also causes AMC 604 to create and store an XML parser plugin 614 that references the parser plugin bundle 610 and contains an instantiated class for the parser plugin class defined in the bundle.
To deploy the bundles in an AONS node 606, the following steps are utilized. Working with AMC 604, the user selects a Policy Tab, Application Policy, and Global Level menu item. The user selects the bundle that has the packages registered in steps above. The user selects Deploy to deploy the bundle.
In an embodiment, transformation information metadata is provided as part of a transformation bundle. The metadata defines all transformation extensions that are present in a corresponding transformation bundle, which can be either an XSLT transform bundle or a content parser plugin bundle. One or more extensions can be present in a particular bundle. In an XSLT transform bundle, each extension specifies a name that is used to identify the extension and serves as a filename, a display name, and version information. If the bundle is a parser plugin bundle, similar fields specify the class name that implements the XMLReader interface, the display name of the extension, and version information. Table 5 presents an example Transformation Bladelet Info File. Table 6 presents an example XML schema defining the transformation information.
4.0 Implementation Mechanisms—Hardware Overview
Computer system 800 includes a bus 802 or other communication mechanism for communicating information, and a processor 804 coupled with bus 802 for processing information. Computer system 800 also includes a main memory 806, such as a random access memory (RAM), flash memory, or other dynamic storage device, coupled to bus 802 for storing information and instructions to be executed by processor 804. Main memory 806 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 804. Computer system 800 further includes a read only memory (ROM) 808 or other static storage device coupled to bus 802 for storing static information and instructions for processor 804. A storage device 810, such as a magnetic disk, flash memory or optical disk, is provided and coupled to bus 802 for storing information and instructions.
A communication interface 818 may be coupled to bus 802 for communicating information and command selections to processor 804. Interface 818 is a conventional serial interface such as an RS-232 or RS-422 interface. An external terminal 812 or other computer system connects to the computer system 800 and provides commands to it using the interface 814. Firmware or software running in the computer system 800 provides a terminal interface or character-based command interface so that external commands can be given to the computer system.
A switching system 816 is coupled to bus 802 and has an input interface 814 and an output interface 819 to one or more external network elements. The external network elements may include a local network 822 coupled to one or more hosts 824, or a global network such as Internet 828 having one or more servers 830. The switching system 816 switches information traffic arriving on input interface 814 to output interface 819 according to pre-determined protocols and conventions that are well known. For example, switching system 816, in cooperation with processor 804, can determine a destination of a packet of data arriving on input interface 814 and send it to the correct destination using output interface 819. The destinations may include host 824, server 830, other end stations, or other routing and switching devices in local network 822 or Internet 828.
The invention is related to the use of computer system 800 for application message payload transformation in a network infrastructure element. According to one embodiment of the invention, application message payload transformation in a network infrastructure element is provided by computer system 800 in response to processor 804 executing one or more sequences of one or more instructions contained in main memory 806. Such instructions may be read into main memory 806 from another computer-readable medium, such as storage device 810. Execution of the sequences of instructions contained in main memory 806 causes processor 804 to perform the process steps described herein. One or more processors in a multi-processing arrangement may also be employed to execute the sequences of instructions contained in main memory 806. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.
The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to processor 804 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 810. Volatile media includes dynamic memory, such as main memory 806. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 802. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.
Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.
Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor 804 for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 800 can receive the data on the telephone line and use an infrared transmitter to convert the data to an infrared signal. An infrared detector coupled to bus 802 can receive the data carried in the infrared signal and place the data on bus 802. Bus 802 carries the data to main memory 806, from which processor 804 retrieves and executes the instructions. The instructions received by main memory 806 may optionally be stored on storage device 810 either before or after execution by processor 804.
Communication interface 818 also provides a two-way data communication coupling to a network link 820 that is connected to a local network 822. For example, communication interface 818 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 818 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 818 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.
Network link 820 typically provides data communication through one or more networks to other data devices. For example, network link 820 may provide a connection through local network 822 to a host computer 824 or to data equipment operated by an Internet Service Provider (ISP) 826. ISP 826 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet” 828. Local network 822 and Internet 828 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 820 and through communication interface 818, which carry the digital data to and from computer system 800, are exemplary forms of carrier waves transporting the information.
Computer system 800 can send messages and receive data, including program code, through the network(s), network link 820 and communication interface 818. In the Internet example, a server 830 might transmit a requested code for an application program through Internet 828, ISP 826, local network 822 and communication interface 818. In accordance with the invention, one such downloaded application provides for application message payload transformation in a network infrastructure element as described herein.
The received code may be executed by processor 804 as it is received, and/or stored in storage device 810, or other non-volatile storage for later execution. In this manner, computer system 800 may obtain application code in the form of a carrier wave.
5.0 Extensions and Alternatives
In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
The preceding description has disclosed an approach for performing application message payload transformation in a network device. The application message payload transformation is performed based on policies that are defined declaratively in terms of application endpoints and application message content. The approach herein provides an improved application message payload transformation approach because a network device is more efficient in performing such transformations, which occur outside the application and the host of the application.
The approach herein has numerous benefits over prior approaches. For example, the approach reduces the number of processing locations at which a message is transformed. Application endpoints are not required to perform message payload transformation. As a result, application resources can focus on core application functions, rather than transforming the messages that the application needs to consume based on all other sending applications that are producing such messages.
Further, separating the management of message transformation policies from the actual message transformation enables a user or system to define such policies declaratively in a single place, and apply them on all the network devices where the transformation is done.
The approach herein is useful for any network gear vendor that needs mechanisms to provide message transformation capability in a networking device to enable easier application integration.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5796743 | Bunting et al. | Aug 1998 | A |
| 6012090 | Chung et al. | Jan 2000 | A |
| 6085234 | Pitts et al. | Jul 2000 | A |
| 6115378 | Hendel et al. | Sep 2000 | A |
| 6125391 | Meltzer et al. | Sep 2000 | A |
| 6145079 | Mitty et al. | Nov 2000 | A |
| 6167438 | Yates et al. | Dec 2000 | A |
| 6226675 | Meltzer et al. | May 2001 | B1 |
| 6321264 | Fletcher et al. | Nov 2001 | B1 |
| 6337856 | Schanhals et al. | Jan 2002 | B1 |
| 6363477 | Fletcher et al. | Mar 2002 | B1 |
| 6389462 | Cohen et al. | May 2002 | B1 |
| 6510464 | Grantges, Jr. et al. | Jan 2003 | B1 |
| 6611526 | Chinnaswamy et al. | Aug 2003 | B1 |
| 6683881 | Mijares et al. | Jan 2004 | B1 |
| 6766330 | Chen et al. | Jul 2004 | B1 |
| 6766361 | Venigalla | Jul 2004 | B1 |
| 6771646 | Sarkissian et al. | Aug 2004 | B1 |
| 6772211 | Lu et al. | Aug 2004 | B2 |
| 6785673 | Fernandez et al. | Aug 2004 | B1 |
| 6785732 | Bates et al. | Aug 2004 | B1 |
| 6813690 | Lango et al. | Nov 2004 | B1 |
| 6820133 | Grove et al. | Nov 2004 | B1 |
| 6826694 | Dutta et al. | Nov 2004 | B1 |
| 6832249 | Ciscon et al. | Dec 2004 | B2 |
| 6836778 | Manikutty et al. | Dec 2004 | B2 |
| 6862270 | Ho | Mar 2005 | B1 |
| 6868426 | Mankoff | Mar 2005 | B1 |
| 6901445 | McCanne et al. | May 2005 | B2 |
| 6944678 | Lu et al. | Sep 2005 | B2 |
| 6950822 | Idicula et al. | Sep 2005 | B1 |
| 7031314 | Craig et al. | Apr 2006 | B2 |
| 7051042 | Krishnaprasad et al. | May 2006 | B2 |
| 7058973 | Sultan | Jun 2006 | B1 |
| 7065086 | Basso et al. | Jun 2006 | B2 |
| 7080158 | Squire | Jul 2006 | B1 |
| 7089586 | Kilgore | Aug 2006 | B2 |
| 7103611 | Murthy et al. | Sep 2006 | B2 |
| 7120645 | Manikutty et al. | Oct 2006 | B2 |
| 7127492 | Calo | Oct 2006 | B1 |
| 7134075 | Hind et al. | Nov 2006 | B2 |
| 7177952 | Wurch et al. | Feb 2007 | B1 |
| 7185063 | Kasriel et al. | Feb 2007 | B1 |
| 7185365 | Tang et al. | Feb 2007 | B2 |
| 7188216 | Rajkumar et al. | Mar 2007 | B1 |
| 7215637 | Ferguson et al. | May 2007 | B1 |
| 7245620 | Shankar | Jul 2007 | B2 |
| 7281205 | Brook | Oct 2007 | B2 |
| 7281206 | Schnelle et al. | Oct 2007 | B2 |
| 7321556 | Parekh et al. | Jan 2008 | B1 |
| 7362763 | Wybenga et al. | Apr 2008 | B2 |
| 7386567 | Manikutty et al. | Jun 2008 | B2 |
| 7392259 | Lee et al. | Jun 2008 | B2 |
| 7415512 | Moon | Aug 2008 | B1 |
| 7437451 | Tang et al. | Oct 2008 | B2 |
| 7469300 | De Bonet et al. | Dec 2008 | B2 |
| 7475108 | Di Giulio et al. | Jan 2009 | B2 |
| 7483421 | Compton | Jan 2009 | B2 |
| 7496750 | Kumar et al. | Feb 2009 | B2 |
| 7509431 | Singhal et al. | Mar 2009 | B2 |
| 7551567 | Anthias et al. | Jun 2009 | B2 |
| 7590704 | Yuan et al. | Sep 2009 | B2 |
| 7590843 | Khalil et al. | Sep 2009 | B1 |
| 7606267 | Anthias et al. | Oct 2009 | B2 |
| 7664879 | Chan et al. | Feb 2010 | B2 |
| 7725934 | Kumar et al. | May 2010 | B2 |
| 8255932 | Clemm et al. | Aug 2012 | B1 |
| 20010000083 | Crow et al. | Mar 2001 | A1 |
| 20010027104 | Hameleers et al. | Oct 2001 | A1 |
| 20010047422 | McTernan et al. | Nov 2001 | A1 |
| 20010056504 | Kuznetsov | Dec 2001 | A1 |
| 20020012433 | Haverinen et al. | Jan 2002 | A1 |
| 20020015485 | Bhusri | Feb 2002 | A1 |
| 20020032871 | Malan et al. | Mar 2002 | A1 |
| 20020069279 | Romero et al. | Jun 2002 | A1 |
| 20020072379 | Chen et al. | Jun 2002 | A1 |
| 20020083817 | Hoshino | Jul 2002 | A1 |
| 20020101848 | Lee et al. | Aug 2002 | A1 |
| 20020105911 | Pruthi et al. | Aug 2002 | A1 |
| 20020107951 | Teague et al. | Aug 2002 | A1 |
| 20020114274 | Sturges | Aug 2002 | A1 |
| 20020141393 | Eriksson et al. | Oct 2002 | A1 |
| 20020143981 | Delima et al. | Oct 2002 | A1 |
| 20020152399 | Smith | Oct 2002 | A1 |
| 20020163933 | Benveniste | Nov 2002 | A1 |
| 20020165957 | Devoe et al. | Nov 2002 | A1 |
| 20020191622 | Zdan | Dec 2002 | A1 |
| 20020194342 | Lu et al. | Dec 2002 | A1 |
| 20030004672 | Thurman | Jan 2003 | A1 |
| 20030005117 | Kang et al. | Jan 2003 | A1 |
| 20030014665 | Anderson et al. | Jan 2003 | A1 |
| 20030018726 | Low et al. | Jan 2003 | A1 |
| 20030026268 | Navas | Feb 2003 | A1 |
| 20030028616 | Aoki et al. | Feb 2003 | A1 |
| 20030036897 | Flores et al. | Feb 2003 | A1 |
| 20030046429 | Sonksen | Mar 2003 | A1 |
| 20030055818 | Faybishenko et al. | Mar 2003 | A1 |
| 20030069975 | Abjanic et al. | Apr 2003 | A1 |
| 20030078031 | Masuda | Apr 2003 | A1 |
| 20030084279 | Campagna | May 2003 | A1 |
| 20030086422 | Klinker et al. | May 2003 | A1 |
| 20030093530 | Syed | May 2003 | A1 |
| 20030095569 | Wengrovitz et al. | May 2003 | A1 |
| 20030099232 | Kudou et al. | May 2003 | A1 |
| 20030112809 | Bharali et al. | Jun 2003 | A1 |
| 20030115448 | Bouchard | Jun 2003 | A1 |
| 20030140140 | Lahtinen | Jul 2003 | A1 |
| 20030163539 | Piccinelli | Aug 2003 | A1 |
| 20030163603 | Fry et al. | Aug 2003 | A1 |
| 20030177183 | Cabrera et al. | Sep 2003 | A1 |
| 20030182419 | Barr et al. | Sep 2003 | A1 |
| 20030188192 | Tang et al. | Oct 2003 | A1 |
| 20030189935 | Warden et al. | Oct 2003 | A1 |
| 20030204626 | Wheeler | Oct 2003 | A1 |
| 20030204719 | Ben-Itzhak | Oct 2003 | A1 |
| 20030217171 | Von Stuermer et al. | Nov 2003 | A1 |
| 20030217176 | Beunings | Nov 2003 | A1 |
| 20030236883 | Takeshima et al. | Dec 2003 | A1 |
| 20040006613 | Lemieux et al. | Jan 2004 | A1 |
| 20040022250 | Chen et al. | Feb 2004 | A1 |
| 20040022255 | Chen et al. | Feb 2004 | A1 |
| 20040024881 | Elving et al. | Feb 2004 | A1 |
| 20040032881 | Arai | Feb 2004 | A1 |
| 20040039940 | Cox et al. | Feb 2004 | A1 |
| 20040044766 | Pauly et al. | Mar 2004 | A1 |
| 20040054886 | Dickinson, III et al. | Mar 2004 | A1 |
| 20040064581 | Shitama et al. | Apr 2004 | A1 |
| 20040088460 | Poisner | May 2004 | A1 |
| 20040088585 | Kaler et al. | May 2004 | A1 |
| 20040128360 | Petri et al. | Jul 2004 | A1 |
| 20040133775 | Callas et al. | Jul 2004 | A1 |
| 20040162871 | Pabla et al. | Aug 2004 | A1 |
| 20040167986 | Gilfix et al. | Aug 2004 | A1 |
| 20040177160 | Seto et al. | Sep 2004 | A1 |
| 20040186883 | Nyman et al. | Sep 2004 | A1 |
| 20040194112 | Whittenberger et al. | Sep 2004 | A1 |
| 20040205136 | Whittenberger et al. | Oct 2004 | A1 |
| 20040205336 | Kessler et al. | Oct 2004 | A1 |
| 20040205770 | Zhang et al. | Oct 2004 | A1 |
| 20040264481 | Darling et al. | Dec 2004 | A1 |
| 20040267920 | Hydrie et al. | Dec 2004 | A1 |
| 20040267930 | Giulio et al. | Dec 2004 | A1 |
| 20040267933 | Przybylski et al. | Dec 2004 | A1 |
| 20040268357 | Joy et al. | Dec 2004 | A1 |
| 20050005031 | Gordy et al. | Jan 2005 | A1 |
| 20050015619 | Lee | Jan 2005 | A1 |
| 20050041670 | Lin et al. | Feb 2005 | A1 |
| 20050050000 | Kwok et al. | Mar 2005 | A1 |
| 20050050362 | Peles | Mar 2005 | A1 |
| 20050054346 | Windham et al. | Mar 2005 | A1 |
| 20050063377 | Bryant et al. | Mar 2005 | A1 |
| 20050076332 | Jawaharlal et al. | Apr 2005 | A1 |
| 20050080914 | Lerner et al. | Apr 2005 | A1 |
| 20050086342 | Burt et al. | Apr 2005 | A1 |
| 20050094611 | Cheong et al. | May 2005 | A1 |
| 20050097455 | Zhou et al. | May 2005 | A1 |
| 20050114394 | Kaipa et al. | May 2005 | A1 |
| 20050117576 | McDysan et al. | Jun 2005 | A1 |
| 20050148314 | Taglienti et al. | Jul 2005 | A1 |
| 20050165828 | Lango et al. | Jul 2005 | A1 |
| 20050165834 | Nadeau et al. | Jul 2005 | A1 |
| 20050169171 | Cheng et al. | Aug 2005 | A1 |
| 20050188103 | Chen | Aug 2005 | A1 |
| 20050190758 | Gai et al. | Sep 2005 | A1 |
| 20050198351 | Nog et al. | Sep 2005 | A1 |
| 20050213591 | Nakazamwa et al. | Sep 2005 | A1 |
| 20050229243 | Svendsen et al. | Oct 2005 | A1 |
| 20050283539 | Betts et al. | Dec 2005 | A1 |
| 20050289538 | Black-Ziegelbein et al. | Dec 2005 | A1 |
| 20060015699 | Fujiwara et al. | Jan 2006 | A1 |
| 20060021010 | Atkins et al. | Jan 2006 | A1 |
| 20060031374 | Lu et al. | Feb 2006 | A1 |
| 20060064467 | Libby | Mar 2006 | A1 |
| 20060077221 | Vaideesvuaran et al. | Apr 2006 | A1 |
| 20060080467 | Gould et al. | Apr 2006 | A1 |
| 20060106941 | Singhal et al. | May 2006 | A1 |
| 20060123425 | Ramarao et al. | Jun 2006 | A1 |
| 20060123467 | Kumar et al. | Jun 2006 | A1 |
| 20060123477 | Raghavan et al. | Jun 2006 | A1 |
| 20060123479 | Kumar et al. | Jun 2006 | A1 |
| 20060129575 | Lee et al. | Jun 2006 | A1 |
| 20060129650 | Anthias et al. | Jun 2006 | A1 |
| 20060129689 | Ho et al. | Jun 2006 | A1 |
| 20060155862 | Kathi et al. | Jul 2006 | A1 |
| 20060155969 | Yoda et al. | Jul 2006 | A1 |
| 20060168334 | Potti et al. | Jul 2006 | A1 |
| 20060248225 | Batz et al. | Nov 2006 | A1 |
| 20060256768 | Chan | Nov 2006 | A1 |
| 20060288208 | Dashora et al. | Dec 2006 | A1 |
| 20070005786 | Kumar et al. | Jan 2007 | A1 |
| 20070005801 | Kumar et al. | Jan 2007 | A1 |
| 20070011223 | Calvignac et al. | Jan 2007 | A1 |
| 20070028001 | Phillips et al. | Feb 2007 | A1 |
| 20070055864 | Tock et al. | Mar 2007 | A1 |
| 20070112975 | Cassar | May 2007 | A1 |
| 20070156919 | Potti et al. | Jul 2007 | A1 |
| 20070192444 | Ackaouy et al. | Aug 2007 | A1 |
| 20070253346 | Nguyen et al. | Nov 2007 | A1 |
| 20080021916 | Schnelle et al. | Jan 2008 | A1 |
| 20080025230 | Patel et al. | Jan 2008 | A1 |
| 20080047008 | Cho et al. | Feb 2008 | A1 |
| 20080209413 | Kakumani et al. | Aug 2008 | A1 |
| 20100094945 | Chan et al. | Apr 2010 | A1 |
| Number | Date | Country |
|---|---|---|
| 0986229 | Aug 1999 | EP |
| 0986229 | Mar 2000 | EP |
| 0 986 229 | Apr 2000 | EP |
| 1217804 | Feb 2002 | EP |
| 1217804 | Jun 2002 | EP |
| WO 9907116 | Feb 1999 | WO |
| WO 0227507 | Apr 2002 | WO |
| WO 0237730 | May 2002 | WO |
| WO 0237730 | May 2002 | WO |
| WO 02075547 | Sep 2002 | WO |
| WO 03021465 | Mar 2003 | WO |
| WO 2006055406 | May 2006 | WO |
| Entry |
|---|
| Oracle9i Application Developer's Guide-Advanced Queuing Release 2(9.2), 2002, pp. 1-93. |
| International Searching Authority, “Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration,” PCT/US2006/024375, dated Oct. 17, 2006, 10 pages. |
| Current Claims, PCT/US2006/024375, 6 pages. |
| Decasper, Dan et al., “Router Plugins: A Software Architecture for Next-Generation Routers,” IEEE ACM Transactions on Networking, vol. 9, No. 1, Feb. 2000, XP011038838, 14 pages. |
| Chiu, Kenneth, et al., “Investigating the Limits of SOAP Performance for Scientific Computing”, Nov. 7, 2002, IEEE Computer Society, 8 pages. |
| State Intellectual Property Office of the People's Republic of China, “The First Office Action”, filing No. 200580031571.0, Dated Dec. 19, 2008, 9 pages. |
| Claims, filing No. 200580031571.0, 8 pages. |
| State Intellectual Property Office of the People's Republic of China, “The First Office Action”, filing No. 200580045932.7, Dated Nov. 28, 2008, 8 pages. |
| Claims, filing No. 200580045932.7, 8 pages. |
| European Patent Office, “European Search Report”, application No. EP 05820894, Feb. 6, 2009, 8 pages. |
| Claims, application No. EP 05820894, 6 pages. |
| The Patent Office of the People's Republic of China, “The Second Office Action”, Application No. 200580045932.7, dated May 8, 2009, 9 pages. |
| Pending Claims, Application No. 200580045932.7, 8 pages. |
| European Patent Office, “Communication pursuant to Article 94(3) EPC”, Application No. 05820894.3-2211/1812870, dated May 28, 2009, 9 pages. |
| Amended Claims, Application No. 05820894.3-2211/1812870, 6 pages. |
| International Searching Authority, “Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration”, International application No. PCT/US05/46149, dated Jul. 20, 2007, 9 pages. |
| Claims, International application No. PCT/US05/46149, 10 pages. |
| State Intellectual Property Office of the People's Republic of China, “The First Office Action”, application No. 200580031604.1, Dated Jun. 27, 2008, 15 pages. |
| Claims, application No. 200580031604.1, 6 pages. |
| Sharp R L et al. “Network Security in a Heterogeneous Environment,” AT & T Technical Journal, American Telephone and Telegraph Co. New York, US vol. 73, No. 5 Sep. 1, 1994, pp. 52-59. |
| European Patent Office, “European Search Report,” dated Dec. 6, 2010, application No. EP 05 85 3162, 11 pages. |
| Current Claims for European application No. EP 05 85 3162 , 6 Pages. |
| European Patent Office, “European Search Report”, dated Nov. 30, 2010, application No. EP 05 85 3164, 8 pages. |
| Current Claims for European application No. EP 05 85 3164, 5 Pages. |
| Sharp R.L. et al. “Network Security in a Heterogeneous Environment”, AT&T Journal, American Telephone and Telegraph Co. New York, US, vol. 73, No. 5, Sep. 1, 1994 pp. 52-59. |
| European Patent Office, “European Search Report”, application No. 0583164.1, applicant: Cisco Technology Inc., Dated Nov. 30, 2010, 8 pages. |
| Current Claims for European application 0583164.1, 5 pages. |
| European Patent Office, “European Search Report”, application No. 05853162.5, applicant Cisco Technology, Inc., Dated Dec. 6, 2010, 11 pages. |
| Current Claims for European application 05853162.5, 6 pages. |
| Government of India Patent Office Intellectual Property Building, “Office Action in Application No. 2216/DELNP/2007”, Applicant: Cisco Technology, Inc., Dated Jul. 14, 2011, 2 pages. |
| Current Claims in Application No. 2216/DELNP/2007, Dated Jul. 2011, 9 pages. |
| The Patent Office of the People's Republic of China, Office Action in Application No. 200580041996, Applicant: Cisco Technology, Inc., dated May 25, 2011, 11 pages. |
| Current Claims for Application No. 200580041996, Application: Cisco Technology Inc., dated May 2011, 9 pages. |
| State Intellectual Property Office of the Peoples Republic of China, Office Action PCT Application No. 200580041997.4, Applicant: Cisco Technology Inc., Dated Feb. 11, 2011, 5 pages. |
| Current Claims, Application No. 200580041997.4, Applicant: Cisco Technology Inc., 6 pages. |
| First Examination Report from IN for foreign patent application No. 3288/DELNP/2007 dated Aug. 26, 2011, 1 page. |
| Current claims in IN patent application No. 3288/DELNP/2007, dated Aug. 2011, 6 pages. |
| India Patent Office, India First Examination Report in International Application No. 2212/DELNP/2007 dated Oct. 14, 2011, 1 page. |
| Current Claims, Application No. 2212/DELNP/2007, 6 pages. |
| India Patent Office, India First Examination Report in International Application No. 3205/DELNP/2007dated Oct. 14, 2011, 1 page. |
| Current Claims, Application No. 3205/DELNP/2007, 10 pages. |
| Sharp R. L. et al., “Network security in a Heterogeneous Environment”, AT&T Technical Journal, American Telephone & Telegraph Co. New York, US, vol. 73, No. 5, Sep. 1, 1994 (8 pages) XP000475911, ISSN: 8756-2324. |
| India Patent Office, IN Office Action in International Application No. 3290/DELNP/2007 dated Dec. 21, 2011 (2 pages). |
| Current Claims, Application No. 3290/DELNP/2007 (3 pages). |
| China Patent Office, CN Office Action in International Application No. 201010622659.2 dated Oct. 17, 2011 (12 pages). |
| Current Claims, Application No. 201010622659.2 (7 pages). |
| India Patent Office, IN First Examination Report in International Application No. 3287/DELNP/2007 dated Jan. 24, 2012 (2 pages). |
| The Patent Office of the People's Republic of China, The Third Office Action in Application No. 200580041996.X, Applicant: Cisco Technology, Inc., dated Sep. 15, 2011, 5 pages. |
| Current Claims in Application No. 200580041996, dated Sep. 2011, 5 pages. |
| India Patent Office, IN First Examination Report in International Application No. 3155/DELNP/2007 dated Mar. 1, 2012 (1 page). |
| Current Claims, Application No. 3155/DELNP/2007 ( 6 pages). |
| China Patent Office CN 4th Office Action in International Application No. 200580041996.X dated Jun. 26, 2012 (8 pages). |
| U.S. Appl. No. 11/455,011, filed Jun. 25, 2006, Notice of Allowance, May 21, 2012. |
| U.S. Appl. No. 12/638,159, filed Dec. 15, 2009, Office Action. |
| China Patent Office, CN 4th Office Action received in International Application No. 200580041996.X dated Jun. 26, 2012 (8 pages). |
| Current Claims, Application No. 200580041996.X (5 pages), dated Jun. 2012. |
| U.S. Appl. No. 11/472,796, filed Jun. 21, 2006, Notice of Allowance. |
| U.S. Appl. No. 11/090,920, filed Mar. 24, 2005, Final Office Action. |
| Number | Date | Country | |
|---|---|---|---|
| 20060288208 A1 | Dec 2006 | US |
