Patent Grant
7721193
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document of the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
The invention relates generally to systems and methods for integrating applications.
E-commerce has become a major driving factor in the new economy. To be successful in the long-term, e-commerce will require many companies to engage in cross-enterprise collaborations. To achieve cross-enterprise integration, a company must first integrate its internal applications. Using existing technology and tools, application integration can be an expensive proposition. No integration solution exists that is easy to use, affordable, and based on industry standards. Neither does a solution exist that is based on an industry standard infrastructure, has universal connectivity, is capable of massive scalability, and has accessible business process tools.
Application integration to this point has been very inward-focused. Many existing integration systems have not focused on integrating applications between enterprises. Even when integration solutions were used for cross-enterprise integration, the solutions were still narrowly focused and aimed at vertical markets. This inward focus did little to help companies field external business-to-consumer and business-to-business applications, such as applications that can utilize the Internet to generate revenue and reduce costs. The requirement for Internet-enabled applications led to the rise of the application server market. To date, application servers have primarily been used to host external applications targeted at customers and partners. Application servers are themselves packaged applications that, instead of solving a specific problem, are general-purpose platforms that host vertical solutions.
The first attempts at application integration were primarily focused on low-level implementation details such as the format of the data, the byte ordering between machines, and character encoding. The focus on low-level data formats was necessary because, for the first generation of application integration solutions, there were no widely adopted standards for data encoding that could be deployed across multiple vertical applications.
The traditional approach involved connecting individual systems to, in effect, hardwire the systems together. This approach can be complex, as connecting different systems can require an intimate, low-level knowledge of the proprietary technologies of multiple systems.
Present integration systems, which have moved away from “hardwiring” systems together, still suffer from a lack of standards. Each integration vendor typically provides a proprietary solution for application integration, message transformation, message formats, message transport, and routing. Not one of these systems to date has achieved significant market share to enable its technologies to become the de-facto standard. This lack of standards has given packaged application vendors little incentive to integrate these systems with their. Further, each of these integration systems or servers has its own proprietary API, such that packaged application vendors cannot leverage development beyond a single integration server. This fragmentation of the integration market has provided little financial incentive for third parties.
Systems and methods in accordance with embodiments of the present invention allow communication to be passed between components, such as an enterprise system and a client application, by taking advantage of schemas. A schema can be used to ensure that a communication, such as a request or response, is in the proper format for one of the components. For instance, metadata can be received from an enterprise system in response to a request from a client application. That metadata can be transformed to a response document that conforms to a schema. The document can be validated against the schema and passed on to the client application.
Other features, aspects, and objects of the invention can be obtained from a review of the specification, the figures, and the claims.
Application integration components can be used to integrate a variety of applications and systems, such as Enterprise Information Systems (EISs). Information technology (IT) organizations typically utilize several highly-specialized applications. Without a common integration platform to facilitate application-level integration, these applications cannot be integrated without extensive, highly-specialized development efforts.
Application integration can utilize adapters to establish an enterprise-wide, united framework for integrating any current or future application. Adapters can simplify integration efforts by allowing each application to be integrated with an application server, instead of requiring that each application being integrated with every other application.
The development and widespread acceptance of standards such as the Java 2 Platform, Enterprise Edition (J2EE) from Sun Microsystems, Inc. of Santa Clara, Calif., as well as the extensible Markup Language (XML), has laid the groundwork for a standardized approach to the development of these adapters. Perhaps the most significant of these standards for application integration is the J2EE Connector architecture. The J2EE Connector architecture provides a standardized approach for the development of adapters for all types of applications, from legacy mainframe applications, such as CICS from IBM, to packaged applications such as PeopleSoft, Siebel, and SAP. The adoption of such standards enables businesses to develop adapters that work on any J2EE-compliant application server, for example.
Integration Architecture
Application integration can build on this standardized approach in an application integration framework by providing a standards-based architecture for hosting J2EE Connector architecture-based adapters. Developers can build J2EE Connector architecture-compliant adapters and deploy these adapters, in the integration framework, to connect enterprise applications to an application server.
These adapters can be used to define business-focused interfaces to an EIS, the interfaces referred to herein as “application views” of the respective adapters. An application view can provide a simple, self-describing, consistent interface to services and events in an application. Application views can make use of an adapter for an EIS, making it possible to expose existing information systems as business services. Unlike adapters, however, an application view does not require users to have intimate knowledge of the EIS or the client interface for that EIS, such that non-programmers or technical analysts can use application views. An application view can provide a business-oriented way for business analysts to access enterprise data without worrying about the programmatic details defined in an adapter. These same users may be otherwise unable to use an adapter directly, due to a lack of familiarity with the EIS.
An application integration component directed at enterprise application integration can have several primary aspects. If the functionality of an EIS such as a PeopleSoft system or an SAP system is to be invoked, an implementation of the J2EE Connector Architecture can be used. If something occurs inside an EIS system, such as a trigger going off, an event can be generated. This event may, in some embodiments, need to be communicated to an external application. An event architecture in an application integration component can handle this communication.
Application Views
An application view can provide significant value to an application integration component. An application view can abstract away much of the complexity in dealing with an application, such as a backend EIS system. Application views can also simplify the way in which adapters are accessed. Application views can provide a layer of abstraction, for example, between an adapter and the EIS functions exposed by that adapter. Instead of accessing an EIS by direct programming a user can simply: edit an adapter's application views, create new application views, or delete any obsolete application view(s). A layer of abstraction formed by application views can help non-programmers maintain the services and events exposed by an adapter. Each application view can be specific to a single adapter, and can define a set of business functions on that adapter's EIS. After an adapter is created, a Web-based interface for the adapter can be used to define application views.
If an application view is used as a primary user interface for an adapter, a number of features can be included that are not commonly found in existing enterprise application integration technologies. Application views can, for example, use XML as a common language among applications. Service and event definitions can be used to expose application capabilities. XML schemas can be used to define the data for services and events. Bidirectional communication can also be supported in adapters.
An application view can be an integral part of an integration framework. An application view can provide a view of the application capabilities exposed by an adapter that a user can customize to meet specific needs. A user can tailor an application view, for example, for a specific business purpose. As a result, the application view can provide an effective alternative to the “one size fits all” approach that many applications provide for the design of a client interface. An application view can be defined for only the business or other capabilities that are applicable for a specific purpose. The capabilities can be customized such as by naming, describing, and defining the data requirements.
In one example, shown in
Another example of a system is shown in
An application view is an object, which can be implemented in one embodiment as a stateless session JavaBean. There can be a Java interface to the application view for the client application. A Java application can be custom coded to use that object, such as by passing XML in and receiving XML back. In addition, a business process manager component can be included that allows process engineers to define workflows, and allows application views to be invoked as business services. In a workflow, a callout can be made to an EIS to get information such as a customer's credit record. The fact that the application view is a Java object or enterprise JavaBean can be hidden from the process and designer.
A web services interface can also be used with an application view. A protocol such as SOAP can be used to invoke a web service. Another protocol that may be used includes UDDI, a platform-independent, open framework for describing services, discovering businesses, and integrating business services using the Internet. A WSDL protocol can also be used, which is an XML format for describing network services. A web services layer can be provided on top of the application view so that any application view can be invoked as a web service.
In application integration, new application views can be hot-deployed against an existing EIS through a web-based interface. An application view is hot-deployed when it is deployed with the system running, without restarting the destination server. A new customer management tool for SAP, for example, can also be defined through a web browser.
Integration Framework
Application integration can utilize an integration framework, which can provide a systematic, standards-based architecture for hosting application views. Features of such a framework can include application views for exposing application functions and design-time graphical user interfaces (GUIs), such as web-based interfaces that can be used for creating application views. The integration framework utilizes adapters, instead of “hardwiring” enterprise systems together. Once an adapter is deployed for an EIS, other components and applications can use that adapter to access data on the EIS.
A framework in accordance with one embodiment of the present invention relies on XML as the standard format for messages. XML includes XSLT, a standard for transforming XML documents into other XML documents. XSLT is designed for use as part of XSL, which is a stylesheet language for XML. In XSLT, an XML document is used to specify the operations to perform on a class of XML documents in order to transform the documents' structure and content. An XSLT transformation can make use of any of the operations built into the Java programming language, or can make use of custom operations written either in Java or in native code. An integration framework allows a business process to invoke an XSLT engine in order to transform XML messages.
An integration framework can also rely on standards for transporting messages such as Java Message Service (JMS) and HTTPS. JMS is a standard API for interfacing with message transport systems. Using JMS, a framework can utilize any message transport mechanism that provides a JMS interface. The J2EE Connector architecture standard does not specify a message transport mechanism, but an application integration framework can specify such a transport mechanism.
An integration framework can be based on an existing standard infrastructure, such as an application server that supports J2EE, JMS, and the J2EE Connector architecture. Using such a standard infrastructure also provides for high availability and scalability, such as by clustering and resource pooling. The framework can provide for universal connectivity by enabling the construction of XML-based application adapters that can connect to any legacy and packaged application. An adapter development kit can be used to allow users such as customers, system integrators, and packaged application vendors to quickly develop J2EE connector architecture-compliant and integration framework-based adapters. The framework can utilize XML, which means that the same data format can be used for both within- and between-enterprise integration, since many e-commerce systems use XML as the standard message format.
An integration framework can also utilize a business-process engine to allow non-programmers to graphically construct and maintain business processes. An integration framework can implement a common model on top of the J2EE Connector architecture that is focused on business-level concepts. This model, which can consist of XML-encoded events and services, allows the management of a consistent integration environment, regardless of the interface required between adapters and their target applications. The business processes can react to events generated by applications, and they can invoke an application's functionality via services that are exposed by an application adapter.
Adapter Development
XML development tools, such as may be included in an ADK, can be considered part of a metadata support layer for a design-time framework. These tools, which can comprise an XML Toolkit, can include an XML schema API, which can be characterized by a Schema Object Model (SOM). This API can be used to programmatically build XML schemas. An adapter can call an enterprise system or EIS for specific request and response metadata, which can then be programmatically transformed into an XML schema. The SOM is a set of tools that can extract many of the common details, such as syntactical complexities of XML schema operations so that a user can focus on its more fundamental aspects. Another tool that can be included is an XML Document API, which can be characterized by IDocument. This API can provide an x-path interface to a document object model (DOM) document.
An IDocument, which can facilitate XML input and output from the CCI layer in an adapter, is a higher-order wrapper around the W3C Document Object Model (DOM). The primary value-add of the IDocument interface is that it provides an XPath interface to elements in an XML document. In other words, IDocument objects are queryable and updatable using XPath strings. For example, the following XML document describes a person named “Bob” and some of the details about “Bob.”
XCCI Design Pattern
A common design pattern that emerges when using an XCCI approach is to support the definition of services in an interaction implementation. In other words, a javax.resource.cci.Interaction implementation for an adapter can allow a client program to retrieve metadata from an underlying EIS in order to define an Integration service. Specifically, this means that the interaction must be able to generate the request and response XML schemas and additional metadata for a service. Additionally, the Interaction could also allow a client program to browse a catalog of functions provided by the EIS. This approach facilitates a thin client architecture for an adapter.
Data Transformation Method
Data transformation is the process of taking data from an enterprise system and transforming the data into an XML schema that can be read by the application server. For each event, a schema can define what the XML output looks like. This can accomplished by using SOM and IDocument class libraries.
The following sample code listings show one data transformation sequence. The following code can be used to transform data from an EIS into an XML schema:
The following example shows an XML schema created by the above code:
The following example shows a valid XML document created by the schema shown above:
The adapter can be tested and then deployed. An adapter can be deployed manually, or through a tool such as a server or integration console.
XML Toolkit
An XML toolkit can be utilized that can help to develop valid XML documents to transmit information from a resource or enterprise system to an application on the other side of an adapter. The toolkit can incorporate many of the operations required for XML manipulation into a single location, relieving the user of these often tedious chores.
An XML toolkit can be comprised primarily of two Java packages, such as a com.document package and a com.schema package. These packages can include complete Javadocs for each class, interface, and method.
IDOC
An IDocument, or IDoc, is a container that combines the W3C Document Object Model (DOM) with an XPath interface to elements in an XML document. This combination can make IDocument objects queryable and updatable simply by using XPath strings. These strings can eliminate the need to parse through an entire XML document to find specific information by allowing a user to specify just the elements the user wants to query and then returning the values of those queries.
An IDocument can be a public interface that represents an XML document. An IDocument can provide a document type name, which can be used to refer to a description of its structure and usage. In addition, IDocuments can be mutable, and can provide methods for retrieving, modifying, adding, and removing data elements. All IDocument objects can be queryable, and can be updatable such as by using XPath strings. Also, IDocument instances can be serializable to, and un-serializable from, XML. IDocument objects can implement a Java interface such as java.io.Serializable.
The default representation of the document represented by an IDocument can be a W3C DOM instance, such as org.w3c.dom.Document. The IDocument may at times be in an unparsed state. This can happen if the IDocument was explicitly constructed this way, by using a method such as DocumentFactory.createDocument (String, boolean), for example, where the boolean argument is ‘true.’ The internal state of an IDocument can be determined using a method such as isparsed( ). If this returns true, then the content of the document has been parsed into a DOM. If ‘false’ is returned, the IDocument may contain just the raw XML text.
In cases where an IDocument is in an unparsed state, the content can be parsed using a SAX parsing scheme that allows a user to build an in-memory representation of the document that is not DOM. A method such as from XML (ContentHandler) can be used for this purpose, allowing a user to parse the document's content manually using an interface such as an implementation of a ContentHandler interface. A user could achieve similar results by getting the raw content from the IDocument and creating/invoking a custom SAX parser.
IDocument can simplify the code necessary to query and find information in a document, as opposed to code such as DOM code. For example, the following XML document describes a person named “Bob” and some of the details about “Bob”:
In order to retrieve Jimmy's hair color from the <child> element by using IDocument, an XPath string can be created that seeks exactly that information, as shown the following IDocument data retrieval code sample:
A schema object model (SOM) is an interface useful for programmatically building schemas, such as XML schemas. SOM can comprise a set of tools that can extract and validate many of the common details, such as syntactical complexities of schema, so that a user can focus on more fundamental aspects. As shown in the method of
A flowchart for such a method is shown in
If the client should not receive an invalid XML document, a determination should be made whether an end condition has been met 416. An end condition can be set so that an infinite loop is not created if the metadata cannot be transformed into a valid XML document. “Valid” in this instance means that the XML document is valid against the XML schema, not that the document is a valid XML document. The client application may receive a document that conforms to the XML schema but that is not a proper XML document. If the end condition has not been met, another attempt can be made to transform the metadata into an XML document 404. If the end condition has been met, such as a number of iterations or timeout period end being reached, an error can be returned to the client application and processing of this request can stop 418.
An XML schema is like a contract between the EIS and an application on the other side of the adapter. This contract can specify how data coming from the EIS must appear in order for the application to manipulate it. A document, or an XML-rendered collection of metadata from an EIS, can be considered valid if it meets the rules specified in the schema, regardless of whether or not the XML is correct. For example, if a schema required a name to appear in a <name> element and that element required two child elements, such as <firstname> and <lastname>, to be valid, the document from the EIS would have to appear in a form such as:
and the schema would have to appear in a form such as:
No other form of <name></name>, such as “<name>Joe Smith</name>” would be valid, even though the XML is correct.
Creating the Schema
An XML schema can be created programmatically by using the classes and methods provided with SOM. One benefit of using such a tool is that it allows a user to tailor a schema for that user's needs simply by populating the variables in the program components. For instance, the following code examples create a schema that validates a purchase order document:
One benefit to such a tool is that it is only necessary to populate the variables in the program components to tailor a schema for particular needs. Attributes can be set in the same way that elements are created, such as:
To correctly set these attributes, their addressability should be maintained. Like complexTypes, simpleTypes can be added to the root of the schema, such as:
The addSequence( ) method of a SOMComplexType object can return a SOMSequence reference, allowing a user to modify the element that was added to the element. In this way objects can be added to the schema, such as by implementing an addSequence( ) method to modify an element:
SOMSequence poType_seq=poType.addSequence( );
Attributes of an element within a schema can be set by calling setter methods of a SOMElement object. For example, an the implementation of setMinOccurs( ) and setMaxOccurs( ) can be given by:
In this example, the items element for PurchaseOrderType was created before Items type. The reference can be created and the type set once the Items type object is available, such as by using:
poType_items.setType(itemType);
An element can also be added to the schema. Adding an element can be done by implementing an addElement( ) method of SOMSequence, or the add( ) method from a previously created SOMElement. These methods can be shown by:
When running the code shown in the previous examples, the following schema can be created:
Validating an XML Document
Once the schema is created, it can be used to validate a document sent from an EIS. SOM can be used to validate XML DOM documents by using a SOMSchema method such as isValid( ). SOMElement can have a corresponding isValid( ) method for validating an element instead of the DOM document. The isValid( ) method can determine if ‘document’ or ‘element’ is valid, and if not, can compile a list of the errors. If the document is valid, isValid( ) can return ‘true’ and the list of errors can be empty.
An isValid( ) method can be implemented in a number of different ways, including the following ways:
The isValid( ) method can return a boolean value of ‘true’ if the document is valid with respect to this schema. If the document is not valid with respect to the schema, isValid( ) can return ‘false’ and the errorList can be populated. The errorList is a java.util.List for reporting errors found in the document, doc. The error list is cleared before validating the document. Therefore, the list implementation used must support the clear( ) method. If isValid( ) returns false, the error list is populated with a list of errors found during the validation procedure. The items in the list are instances of the class com.bea.schema.SOMValidationException. If isValid( ) returns true, errorList is empty. The following shows an example of an isValid( ) implementation:
The foregoing description of preferred embodiments of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations will be apparent to one of ordinary skill in the art. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention for various embodiments and with various modifications that are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the following claims and their equivalence.
This application claims priority to U.S. Provisional Patent Application No. 60/347,919, filed Oct. 18, 2001, entitled “APPLICATION VIEW,” as well as Application No. 60/347,901, filed Oct. 18, 2001, entitled “EVENT ADAPTER,” each of which is hereby incorporated herein by reference. The following applications are cross-referenced and incorporated herein by reference: U.S. patent application Ser. No. 10/271,194 entitled “APPLICATION VIEW COMPONENT FOR SYSTEM INTEGRATION,” by Mitch Upton, filed Oct. 15, 2002. U.S. patent application Ser. No. 10/271,162 entitled “SYSTEM AND METHOD FOR PROVIDING A JAVA INTERFACE TO AN APPLICATION VIEW COMPONENT,” by Mitch Upton, filed Oct. 15, 2002. U.S. patent application Ser. No. 10/271,244 entitled “SYSTEM AND METHOD FOR INVOKING BUSINESS FUNCTIONALITY FOR A WORKFLOW,” by Mitch Upton, filed Oct. 15, 2002. U.S. patent application Ser. No. 10/271,414 entitled “SYSTEM AND METHOD FOR USING WEB SERVICES WITH AN ENTERPRISE SYSTEM,” by Mitch Upton, filed Oct. 15, 2002. U.S. patent application Ser. No. 10/271,157 entitled “SYSTEM AND METHOD FOR IMPLEMENTING AN EVENT ADAPTER,” by Mitch Upton, filed Oct. 15, 2002. U.S. patent application Ser. No. 10/271,156 entitled “SYSTEM AND METHOD USING A CONNECTOR ARCHITECTURE FOR APPLICATION INTEGRATION,” by Mitch Upton, filed Oct. 15, 2002. U.S. patent application Ser. No. 10/271,402 entitled “SYSTEM AND METHOD UTILIZING AN INTERFACE COMPONENT TO QUERY A DOCUMENT,” by Mitch Upton, filed Oct. 15, 2002. U.S. patent application Ser. No. 10/271,423 entitled “SYSTEM AND METHOD USING ASYNCHRONOUS MESSAGING FOR APPLICATION INTEGRATION,” by Mitch Upton, filed Oct. 15, 2002. U.S. patent application Ser. No. 10/271,423 entitled “SYSTEM AND METHOD USING ASYNCHRONOUS MESSAGING FOR APPLICATION INTEGRATION,” by Mitch Upton, filed Oct. 15, 2002. U.S. patent application Ser. No. 10/271,410 entitled “SYSTEM AND METHOD FOR IMPLEMENTING A SERVICE ADAPTER,” by Mitch Upton, filed Oct. 15, 2002.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5321841 | East et al. | Jun 1994 | A |
| 5469562 | Saether | Nov 1995 | A |
| 5604860 | McLaughlin et al. | Feb 1997 | A |
| 5630131 | Palevich et al. | May 1997 | A |
| 5748975 | Van De Vanter | May 1998 | A |
| 5801958 | Dangelo et al. | Sep 1998 | A |
| 5835769 | Jervis et al. | Nov 1998 | A |
| 5836014 | Faiman, Jr. | Nov 1998 | A |
| 5862327 | Kwang et al. | Jan 1999 | A |
| 5867822 | Sankar | Feb 1999 | A |
| 5933838 | Lomet | Aug 1999 | A |
| 5944794 | Okamoto et al. | Aug 1999 | A |
| 5950010 | Hesse et al. | Sep 1999 | A |
| 5961593 | Gabber et al. | Oct 1999 | A |
| 5966535 | Benedikt et al. | Oct 1999 | A |
| 6012083 | Savitzky et al. | Jan 2000 | A |
| 6016495 | McKeehan et al. | Jan 2000 | A |
| 6018730 | Nichols et al. | Jan 2000 | A |
| 6023578 | Birsan et al. | Feb 2000 | A |
| 6023722 | Colyer | Feb 2000 | A |
| 6028997 | Leymann et al. | Feb 2000 | A |
| 6029000 | Woolsey et al. | Feb 2000 | A |
| 6044217 | Brealey et al. | Mar 2000 | A |
| 6067623 | Blakley et al. | May 2000 | A |
| 6070184 | Blount et al. | May 2000 | A |
| 6085030 | Whitehead et al. | Jul 2000 | A |
| 6092102 | Wagner | Jul 2000 | A |
| 6119149 | Notani | Sep 2000 | A |
| 6125363 | Buzzeo et al. | Sep 2000 | A |
| 6141686 | Jackowski et al. | Oct 2000 | A |
| 6141701 | Whitney | Oct 2000 | A |
| 6148336 | Thomas et al. | Nov 2000 | A |
| 6154738 | Call | Nov 2000 | A |
| 6185734 | Saboff et al. | Feb 2001 | B1 |
| 6189044 | Thomson et al. | Feb 2001 | B1 |
| 6212546 | Starkovich et al. | Apr 2001 | B1 |
| 6222533 | Notani | Apr 2001 | B1 |
| 6226675 | Meltzer et al. | May 2001 | B1 |
| 6226788 | Schoening et al. | May 2001 | B1 |
| 6230287 | Pinard et al. | May 2001 | B1 |
| 6230309 | Turner | May 2001 | B1 |
| 6237135 | Timbol | May 2001 | B1 |
| 6243737 | Flanagan et al. | Jun 2001 | B1 |
| 6256676 | Taylor et al. | Jul 2001 | B1 |
| 6269373 | Apte et al. | Jul 2001 | B1 |
| 6282711 | Halpern et al. | Aug 2001 | B1 |
| 6292932 | Baisley et al. | Sep 2001 | B1 |
| 6311327 | O'Brien et al. | Oct 2001 | B1 |
| 6324681 | Sebesta | Nov 2001 | B1 |
| 6330569 | Baisley et al. | Dec 2001 | B1 |
| 6334114 | Jacobs et al. | Dec 2001 | B1 |
| 6336122 | Lee et al. | Jan 2002 | B1 |
| 6338064 | Ault et al. | Jan 2002 | B1 |
| 6343265 | Glebov et al. | Jan 2002 | B1 |
| 6345283 | Anderson | Feb 2002 | B1 |
| 6348970 | Marx | Feb 2002 | B1 |
| 6349408 | Smith | Feb 2002 | B1 |
| 6353923 | Bogel et al. | Mar 2002 | B1 |
| 6356906 | Lippert et al. | Mar 2002 | B1 |
| 6360221 | Gough et al. | Mar 2002 | B1 |
| 6360358 | Elsbree et al. | Mar 2002 | B1 |
| 6367068 | Vaidyanathan et al. | Apr 2002 | B1 |
| 6377939 | Young | Apr 2002 | B1 |
| 6393605 | Loomans | May 2002 | B1 |
| 6408311 | Baisley et al. | Jun 2002 | B1 |
| 6411698 | Bauer et al. | Jun 2002 | B1 |
| 6438594 | Bowman-Amuah | Aug 2002 | B1 |
| 6445711 | Scheel et al. | Sep 2002 | B1 |
| 6463503 | Jones et al. | Oct 2002 | B1 |
| 6470364 | Prinzing | Oct 2002 | B1 |
| 6516322 | Meredith | Feb 2003 | B1 |
| 6549949 | Bowman-Amuah | Apr 2003 | B1 |
| 6560769 | Moore et al. | May 2003 | B1 |
| 6567738 | Gopp et al. | May 2003 | B2 |
| 6584454 | Hummel et al. | Jun 2003 | B1 |
| 6594693 | Borwankar | Jul 2003 | B1 |
| 6594700 | Graham et al. | Jul 2003 | B1 |
| 6601113 | Koistinen et al. | Jul 2003 | B1 |
| 6604198 | Beckman et al. | Aug 2003 | B1 |
| 6609115 | Mehring et al. | Aug 2003 | B1 |
| 6615258 | Barry et al. | Sep 2003 | B1 |
| 6636491 | Kari et al. | Oct 2003 | B1 |
| 6637020 | Hammond | Oct 2003 | B1 |
| 6643652 | Helgeson et al. | Nov 2003 | B2 |
| 6654932 | Bahrs et al. | Nov 2003 | B1 |
| 6662357 | Bowman-Amuah | Dec 2003 | B1 |
| 6678518 | Eerola | Jan 2004 | B2 |
| 6684388 | Gupta et al. | Jan 2004 | B1 |
| 6687702 | Vaitheeswaran et al. | Feb 2004 | B2 |
| 6687848 | Najmi | Feb 2004 | B1 |
| 6721740 | Skinner et al. | Apr 2004 | B1 |
| 6721779 | Maffeis | Apr 2004 | B1 |
| 6732237 | Jacobs et al. | May 2004 | B1 |
| 6738975 | Yee et al. | May 2004 | B1 |
| 6748420 | Quatrano et al. | Jun 2004 | B1 |
| 6754884 | Lucas et al. | Jun 2004 | B1 |
| 6757689 | Battas et al. | Jun 2004 | B2 |
| 6789054 | Makhlouf | Sep 2004 | B1 |
| 6795967 | Evans et al. | Sep 2004 | B1 |
| 6799718 | Chan et al. | Oct 2004 | B2 |
| 6802000 | Greene et al. | Oct 2004 | B1 |
| 6804686 | Stone et al. | Oct 2004 | B1 |
| 6823495 | Vedula et al. | Nov 2004 | B1 |
| 6832238 | Sharma et al. | Dec 2004 | B1 |
| 6836883 | Abrams et al. | Dec 2004 | B1 |
| 6847981 | Song et al. | Jan 2005 | B2 |
| 6850979 | Saulpaugh et al. | Feb 2005 | B1 |
| 6859180 | Rivera | Feb 2005 | B1 |
| 6874143 | Murray et al. | Mar 2005 | B1 |
| 6877023 | Maffeis et al. | Apr 2005 | B1 |
| 6889244 | Gaither et al. | May 2005 | B1 |
| 6915519 | Williamson et al. | Jul 2005 | B2 |
| 6918084 | Slaughter et al. | Jul 2005 | B1 |
| 6920461 | Hejlsberg et al. | Jul 2005 | B2 |
| 6922827 | Vasilik et al. | Jul 2005 | B2 |
| 6950872 | Todd, II | Sep 2005 | B2 |
| 6959307 | Apte | Oct 2005 | B2 |
| 6959340 | Najmi | Oct 2005 | B1 |
| 6963914 | Breitbart et al. | Nov 2005 | B1 |
| 6971096 | Ankireddipally et al. | Nov 2005 | B1 |
| 6976086 | Sadeghi et al. | Dec 2005 | B2 |
| 7000219 | Barrett et al. | Feb 2006 | B2 |
| 7017146 | Dellarocas et al. | Mar 2006 | B2 |
| 7043722 | Bau, III | May 2006 | B2 |
| 7051072 | Stewart et al. | May 2006 | B2 |
| 7051316 | Charisius et al. | May 2006 | B2 |
| 7054858 | Sutherland | May 2006 | B2 |
| 7062718 | Kodosky et al. | Jun 2006 | B2 |
| 7069507 | Alcazar et al. | Jun 2006 | B1 |
| 7072934 | Helgeson et al. | Jul 2006 | B2 |
| 7073167 | Iwashita | Jul 2006 | B2 |
| 7076772 | Zatloukal | Jul 2006 | B2 |
| 7089584 | Sharma | Aug 2006 | B1 |
| 7096422 | Rothschiller et al. | Aug 2006 | B2 |
| 7107578 | Alpern | Sep 2006 | B1 |
| 7111243 | Ballard et al. | Sep 2006 | B1 |
| 7117504 | Smith et al. | Oct 2006 | B2 |
| 7127704 | Van De Vanter et al. | Oct 2006 | B2 |
| 7134072 | Lovett et al. | Nov 2006 | B1 |
| 7143186 | Stewart et al. | Nov 2006 | B2 |
| 7146422 | Marlatt et al. | Dec 2006 | B1 |
| 7155705 | Hershberg et al. | Dec 2006 | B1 |
| 7165041 | Guheen et al. | Jan 2007 | B1 |
| 7181731 | Pace et al. | Feb 2007 | B2 |
| 7184967 | Mital et al. | Feb 2007 | B1 |
| 7231421 | Kawakura et al. | Jun 2007 | B2 |
| 7240331 | Vion-Dury et al. | Jul 2007 | B2 |
| 7260599 | Bauch et al. | Aug 2007 | B2 |
| 7260818 | Iterum et al. | Aug 2007 | B1 |
| 7269625 | Willhide et al. | Sep 2007 | B1 |
| 7406664 | Morton et al. | Jul 2008 | B1 |
| 20010032263 | Gopal et al. | Oct 2001 | A1 |
| 20020004848 | Sudarshan et al. | Jan 2002 | A1 |
| 20020010781 | Tuatini | Jan 2002 | A1 |
| 20020010803 | Oberstein et al. | Jan 2002 | A1 |
| 20020016759 | Marcready et al. | Feb 2002 | A1 |
| 20020035604 | Cohen et al. | Mar 2002 | A1 |
| 20020038336 | Abileah et al. | Mar 2002 | A1 |
| 20020049788 | Lipkin et al. | Apr 2002 | A1 |
| 20020073080 | Lipkin | Jun 2002 | A1 |
| 20020073236 | Helgeson et al. | Jun 2002 | A1 |
| 20020073396 | Crupi et al. | Jun 2002 | A1 |
| 20020078365 | Burnett et al. | Jun 2002 | A1 |
| 20020083075 | Brummel et al. | Jun 2002 | A1 |
| 20020091944 | Anderson et al. | Jul 2002 | A1 |
| 20020111922 | Young et al. | Aug 2002 | A1 |
| 20020116454 | Dyla et al. | Aug 2002 | A1 |
| 20020120685 | Srivastava et al. | Aug 2002 | A1 |
| 20020138582 | Chandra et al. | Sep 2002 | A1 |
| 20020143960 | Goren et al. | Oct 2002 | A1 |
| 20020152106 | Stoxen et al. | Oct 2002 | A1 |
| 20020152244 | Dean et al. | Oct 2002 | A1 |
| 20020161826 | Arteaga et al. | Oct 2002 | A1 |
| 20020165936 | Alston et al. | Nov 2002 | A1 |
| 20020169644 | Greene | Nov 2002 | A1 |
| 20020174178 | Stawikowski | Nov 2002 | A1 |
| 20020174241 | Beged-Dov et al. | Nov 2002 | A1 |
| 20020184145 | Sijacic et al. | Dec 2002 | A1 |
| 20020184610 | Chong et al. | Dec 2002 | A1 |
| 20020188486 | Gil et al. | Dec 2002 | A1 |
| 20020188513 | Gil et al. | Dec 2002 | A1 |
| 20020194221 | Strong et al. | Dec 2002 | A1 |
| 20020194244 | Raventos | Dec 2002 | A1 |
| 20020194267 | Flesner et al. | Dec 2002 | A1 |
| 20020194495 | Gladstone et al. | Dec 2002 | A1 |
| 20030004746 | Kheirolomoom et al. | Jan 2003 | A1 |
| 20030005181 | Bau, III et al. | Jan 2003 | A1 |
| 20030014439 | Boughannam | Jan 2003 | A1 |
| 20030018661 | Darugar | Jan 2003 | A1 |
| 20030018665 | Dovin et al. | Jan 2003 | A1 |
| 20030018832 | Amierisetty et al. | Jan 2003 | A1 |
| 20030018963 | Ashworth et al. | Jan 2003 | A1 |
| 20030023957 | Bau, III et al. | Jan 2003 | A1 |
| 20030028579 | Kulkami et al. | Feb 2003 | A1 |
| 20030039594 | Pikus | Feb 2003 | A1 |
| 20030041050 | Smith et al. | Feb 2003 | A1 |
| 20030041198 | Exton et al. | Feb 2003 | A1 |
| 20030043191 | Tinsley et al. | Mar 2003 | A1 |
| 20030046266 | Mullins et al. | Mar 2003 | A1 |
| 20030046591 | Asghari-Kamrani et al. | Mar 2003 | A1 |
| 20030051063 | Skufca et al. | Mar 2003 | A1 |
| 20030051066 | Pace et al. | Mar 2003 | A1 |
| 20030055868 | Fletcher et al. | Mar 2003 | A1 |
| 20030055878 | Fletcher et al. | Mar 2003 | A1 |
| 20030065827 | Skufca et al. | Apr 2003 | A1 |
| 20030069975 | Abjanic et al. | Apr 2003 | A1 |
| 20030074217 | Beisiegel et al. | Apr 2003 | A1 |
| 20030074467 | Oblak et al. | Apr 2003 | A1 |
| 20030079029 | Garimella et al. | Apr 2003 | A1 |
| 20030084203 | Yoshida et al. | May 2003 | A1 |
| 20030093470 | Upton | May 2003 | A1 |
| 20030110117 | Saidenberg et al. | Jun 2003 | A1 |
| 20030110446 | Nemer | Jun 2003 | A1 |
| 20030126136 | Omoigui | Jul 2003 | A1 |
| 20030149791 | Kane et al. | Aug 2003 | A1 |
| 20030167358 | Marvin et al. | Sep 2003 | A1 |
| 20030196168 | Hu | Oct 2003 | A1 |
| 20030233631 | Curry | Dec 2003 | A1 |
| 20040019645 | Goodman et al. | Jan 2004 | A1 |
| 20040040011 | Bosworth et al. | Feb 2004 | A1 |
| 20040068568 | Griffin | Apr 2004 | A1 |
| 20040078373 | Ghoneimy et al. | Apr 2004 | A1 |
| 20040103406 | Patel | May 2004 | A1 |
| 20040133660 | Junghuber et al. | Jul 2004 | A1 |
| 20040148336 | Hubbard et al. | Jul 2004 | A1 |
| 20040204976 | Oyama et al. | Oct 2004 | A1 |
| 20040216086 | Bau | Oct 2004 | A1 |
| 20040225995 | Marvin et al. | Nov 2004 | A1 |
| 20040260715 | Mongeon et al. | Dec 2004 | A1 |
| 20050050068 | Vaschillo et al. | Mar 2005 | A1 |
| 20050223392 | Cox et al. | Oct 2005 | A1 |
| 20050256935 | Overstreet et al. | Nov 2005 | A1 |
| 20050278585 | Spencer | Dec 2005 | A1 |
| 20060085797 | Connelly | Apr 2006 | A1 |
| 20060206856 | Breeden et al. | Sep 2006 | A1 |
| 20060234678 | Juitt et al. | Oct 2006 | A1 |
| 20070038500 | Hammitt et al. | Feb 2007 | A1 |
| 20070174486 | Holstege | Jul 2007 | A1 |
| Number | Date | Country |
|---|---|---|
| 2248634 | Mar 2000 | CA |
| 1 006 443 | Jun 2000 | EP |
| 1 061 445 | Dec 2000 | EP |
| WO9923558 | May 1999 | WO |
| 0029924 | May 2000 | WO |
| 0190884 | Nov 2001 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 20030182452 A1 | Sep 2003 | US |
| Number | Date | Country | |
|---|---|---|---|
| 60347919 | Oct 2001 | US | |
| 60347901 | Oct 2001 | US |
