`Cashin/GML/ODBC/Brockschmidt
`
`Prior Art: Windows Open System Architecture, Computer Technology Research Corp., Jerry Cashin (“Cashin”); ODBC 2.0
`Programmer’s Reference and SDK Guide (“ODBC Programmer’s Guide”); Inside OLE 2, Kraig Brockschmidt (“Brockschmidt”);
`IMC-201 Single-Axis Motion Controller GML V3.3 Programming Manual (“GML Programming Manual”); GML Programmer’s
`Workshop, User’s Manual, July 31, 1991 (“1991 GML Programmer’s Workshop”); GML Programmer’s Workshop, User Manual,
`November 17, 1993 (“1993 GML Programmer’s Workshop”).
`
`Defendants assert that, based on the scope of the claims as asserted by AMS in its infringement contentions, disclosures of WOSA,
`ODBC, Brockschmidt and GML in the documents described above are invalidating prior art under pre-AIA 35 U.S.C. § 102(a), (b)
`and/or (e), and that the underlying systems described in the Cashin reference, the GML references, Brockschmidt, and the ODBC
`reference are invalidating prior art by prior public use and/or on sale under pre-AIA 35 U.S.C.§ 102(a) or (b). Accordingly, as used
`herein, “Cashin” is used to refer to both the disclosures of the Cashin disclosure and the systems disclosed therein, ODBC is used to
`refer to both the disclosures of the ODBC reference and the systems disclosed therein, Brockschmidt is used to refer to both the
`disclosures of the Brockschmidt reference and the systems disclosed therein, and “GML” is used to refer to both the disclosures of the
`GML disclosures and the systems disclosed therein.
`
`Claim 1
`A system for generating a
`sequence of control
`commands for controlling a
`selected motion control
`device selected from a group
`of supported motion control
`devices, comprising:
`
`Cashin, GML, and ODBC
`Cashin discloses and describes the Windows Open Services Architecture (“WOSA”) that generally
`provides a software system that applications use to interact with local and remote hardware devices
`and services. WOSA can include a Driver Manager that connects the application to an appropriate
`server driver. WOSA provides a single interface for implementing a particular service, such that user
`applications can invoke specified APIs as appropriate to the functional service being sought,
`including functional services for interacting with devices.
`
`“Applications call protocols known as Application Programming Interfaces (APIs) to access services
`that have been standardized in the Windows environment. The specific nature, configuration, etc. of
`the called service is of no concern to the calling API, at least from the viewpoint of access
`procedures.” Cashin at 2.
`
`“WOSA’s operational plan (see Figure 1.1) includes an abstraction layer that provides interaction
`with heterogeneous computing devices via a set of APIs. Windows-based applications, using these
`APIs, can operate from a variety of end-user devices. New end-user devices can be added as they
`enter the marketplace. Meanwhile, applications remain unchanged as long as they employ WOSA
`APIs.” Cashin at 6.
`
`4818-9757-4452.1
`
`Page 1 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`
`Claim 1
`
`
`“Instead of having to learn a different set of APIs for each implementation of a service, programmers
`creating WOSA applications need only learn a single set of APIs for all implementations of a
`particular service. In addition, applications remain stable no matter what changes are made to
`functional services as long as these services communicate through the WOSA interface.” Cashin at 6.
`
`“Figure 3.1 depicts the major elements of this model where user applications invoke specified APIs as
`appropriate to the functional service being sought.” Cashin at 49.
`
`See, e.g., Cashin at Figure 1.1, 7:
`
`
`“Figure 3.1 depicts the major elements of this model where user applications invoke specified APIs as
`appropriate to the functional service being sought, e.g. messaging service. The actual service
`provider, in this case MAPI, is accessed through SPIs developed for specific messaging functions.”
`2
`
`
`
`4818-9757-4452.1
`
`Page 2 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`
`Claim 1
`
`Cashin at 49.
`
`See, e.g., Cashin at Figure 3.1, p. 50:
`
`
`
`
`See also Cashin at 8, 46, Figure 1.2 at 17, Figure 2.3 at 47.
`
`Cashin also describes many specific examples of software systems that applications can use that are
`based on WOSA including, for example, Open Database Connectivity (“ODBC”), Messaging API
`(“MAPI”), and Windows Extensions for Financial Services (“WOSA/XFS”).
`
`See also Cashin at 18-19, 21-22, 30, Figure 1.8 at 32, Figure 4.2 at 61, 85-87, 125.
`
`Cashin also describes examples of communication between an application program and many
`hardware devices, including printers and financial devices.
`
`“In 1992, Microsoft formed a consortium of firms interested in financial services markets in order to
`3
`
`4818-9757-4452.1
`
`Page 3 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`Claim 1
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`standardize the end-user interface. … Their basic goal was to allow any application using Windows to
`employ standard interfaces for access to financial data and devices.” Cashin at 29-30. These devices
`can include printers, magnetic stripe readers/writers, PIN pads, cash dispensers, check readers, and
`image scanners. See Cashin at 126.
`
`
`4818-9757-4452.1
`
`4
`
`Page 4 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`Claim 1
`[1A] a set of motion control
`operations, where each
`motion control operation is
`either a primitive operation
`the implementation of which
`is required to operate other
`motion control devices and
`cannot be simulated using
`other motion control
`operations or
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`GML was a graphical programming language for use with a number of different motion controllers.
`(1991 GML Programmer’s Workshop at 1-3; 1993 GML Programmer’s Workshop at 1-3; 10-11.) A
`design program called GML Programmer’s Workshop allowed users to create GML programs on
`Microsoft Windows. (1991 GML Programmer’s Workshop at 1-4; 1993 GML Programmer’s
`Workshop at 1-10.) Once installed, users could graphically build a motion control program using the
`provided set of GML graphical “blocks.” (1991 GML Programmer’s Workshop, e.g., at 13-15; 1993
`GML Programmer’s Workshop, e.g. at 13-17.)
`
`GML contains a library of motion operations (e.g., “blocks”) that programmers could use to build
`motion control programs. The Cashin architecture as applied to the motion operations of GML would
`result in an API with functions that could be called from application programs to define a desired
`motion sequence.
`
`GML defines a “Direct Drive Control” block, a “Move Axis” block, a “Jog Axis” block, and a “Show
`Axis Position” block. (GML at 88, 98-1 01, 106, and 138.) A “Direct Drive Control” block applies
`to servo operation and “directly sets the servo output to the specified percentage of 10V” based on the
`desired axis and direction. (Id. at 88.) A “Move Axis” block can run in a few different modes, but
`when running in “Incremental” mode it simply moves the targeted axis by the specified amount. (Id.
`at 98-101.) A “Jog Axis” block “jogs (moves continuously) an axis in the specified direction at a
`specified speed and using a specified acceleration and deceleration.” (Id. at 106.) A “Show Axis
`Position” block queries the specified axis and reports on “the current actual position of the chosen
`axis.” (Id. at 138.)
`
`See, e.g., GML Programming Manual at 88 (“Direct Drive Control” Block):
`
`4818-9757-4452.1
`
`5
`
`Page 5 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`
`Claim 1
`
`
`See, e.g., GML Programming Manual at 98-101 (“Move Axis” Block):
`
`
`
`
`4818-9757-4452.1
`
`6
`
`Page 6 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`
`Claim 1
`
`
`See, e.g., GML Programming Manual at 106 (“Jog Axis” Block):
`
`
`
`
`See, e.g., GML Programming Manual at 138 (“Show Axis Position” Block):
`
`
`
`4818-9757-4452.1
`
`7
`
`Page 7 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`
`Claim 1
`
`4818-9757-4452.1
`
`8
`
`Page 8 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`Claim 1
`[1B] a non-primitive
`operation that does not meet
`the definition of a primitive
`operation;
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`GML was a graphical programming language for use with a number of different motion controllers.
`(1991 GML Programmer’s Workshop at 1-3; 1993 GML Programmer’s Workshop at 1-3; 10-11.) A
`design program called GML Programmer’s Workshop allowed users to create GML programs on
`Microsoft Windows. (1991 GML Programmer’s Workshop at 1-4; 1993 GML Programmer’s
`Workshop at 1-10.) Once installed, users could graphically build a motion control program using the
`provided set of GML graphical “blocks.” (1991 GML Programmer’s Workshop, e.g., at 13-15; 1993
`GML Programmer’s Workshop, e.g. at 13-17.)
`
`GML contains a library of motion operations (e.g., “blocks”) that programmers could use to build
`motion control programs. The Cashin architecture as applied to the motion operations of GML would
`result in an API with functions that could be called from application programs to define a desired
`motion sequence.
`
`GML defines a “Home Axis” block, and a “Move Axis” block running in “Absolute” mode. (Id. at
`95, 98-101.) The “Home Axis” block has a number of different modes, but they all perform a
`“homing” operation that move the selected axis based on the home setting on the axis. For example,
`when a “Home Axis” block is run in “Active” mode, the specified “axis is homed using the power-up
`Homing Configuration as set in the Machine Setup Menu.” (Id. at 95.) The “Homing Configuration”
`includes a “home” position for the axes and the “Home Axis” operation moves, among other things,
`the specified axis to its “home” position during the “homing” operation. A “Move Axis” block
`running in “Absolute” mode moves the targeted axis to the indicated position and this operation could
`be done by using an “Incremental” “Move Axis” operation to the specified position based on the
`difference between the target and current position. (Id. at 100.).
`
`See, e.g., GML Programming Manual at 95 (“Home Axis” Block):
`
`4818-9757-4452.1
`
`9
`
`Page 9 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`
`Claim 1
`
`
`See, e.g., GML Programming Manual at 98-101 (“Move Axis” Block):
`
`
`
`4818-9757-4452.1
`
`10
`
`Page 10 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`
`Claim 1
`
`
`
`
`
`
`GML also provided the ability to build composite blocks that were built using individual lower-level
`blocks. (1991 GML Programmer’s Workshop at 43-46; 1993 GML Programmer’s Workshop at 13-
`18.) Such composite blocks – referred to as “modules” – could be duplicated, copied, moved, and
`connected and used within diagrams just as with the lower-level blocks. (1991 GML Programmer’s
`Workshop at 43-46; 1993 GML Programmer’s Workshop at 13-18.) A user could define a higher-
`level motion module that included, for example, a combination of lower-level motion operations such
`as “Move Axis” blocks and “Jog Axis” blocks. (1991 GML Programmer’s Workshop at 43-46; 1993
`GML Programmer’s Workshop at 13-18.) At execution time, the module would carry-out the lower-
`level blocks that were included in its definition. (1991 GML Programmer’s Workshop at 43-46; 1993
`GML Programmer’s Workshop at 13-18.) Once defined, this module could then be duplicated,
`copied, or moved within a GML diagram just as with any other GML block. (1991 GML
`Programmer’s Workshop at 43-46; 1993 GML Programmer’s Workshop at 13-18.)
`
`4818-9757-4452.1
`
`11
`
`Page 11 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`Claim 1
`[1C] a core set of core driver
`functions, where each core
`driver function is associated
`with one of the primitive
`operations;
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`WOSA uses a Service Provider Interface (“SPI”) layer that contains function definitions that service-
`providers and/or device-providers implement in software drivers to facilitate communication with and
`control over the targeted service and/or device. In WOSA, the APIs are linked to the SPIs using an
`intermediate software layer called the Driver Manager. A WOSA SPI is constructed to be similar to
`the API and the functions of the SPI layer will generally conform to the functions of the API layer so
`that if the API contains a function, the SPI will generally contain a corresponding function.
`
`“At the service-provider end, additional interfaces link to diverse functional packages. These include
`numerous database packages, mail utilities, etc. As with the aforementioned end-user APIs, service-
`provider interfaces can be expanded to encompass new products. Applications will remain
`unchanged as long as functional packages support the interface conventions defined by its SPI.”
`Cashin at 6.
`
`“WOSA solves this problem by communicating to servers through APIs. The can be linked in at
`runtime via Windows Dynamic Link Libraries (DLLs). For each functional service, a Driver
`Manager (MAPI.DLL, for example) makes the connection between the application and appropriate
`server driver, i.e., SPI.” Cashin at 8.
`
`“Additional implementations of existing services can be added by building a service provider
`interface library for the new service provider. Applications can take advantage of new service
`implementations without being modified and can take advantage of entirely new services only when
`they need to do so.” Cashin at 12.
`
`“Figure 3.1 depicts the major elements of this model where user applications invoke specified APIs as
`appropriate to the functional service being sought, e.g. messaging service. The actual service
`provider, in this case MAPI, is accessed through SPIs developed for specific messaging functions.”
`Cashin at 49.
`
`See, e.g., Cashin at Figure 3.1, p. 50:
`
`4818-9757-4452.1
`
`12
`
`Page 12 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`
`Claim 1
`
`
`“On a more detailed level, there are software drivers appended to the Windows operating system that
`aid the WOSA process (see Figure 3.2). Labeled WOSA drivers, they are used by SPIs to access a
`particular type of back-end functionality.” Cashin at 49.
`
`See, e.g., Cashin at Figure 3.2, p. 51:
`
`
`
`4818-9757-4452.1
`
`13
`
`Page 13 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`
`Claim 1
`
`
`
`
`See also Cashin at 15.
`
`Cashin describes many specific examples of software systems based on WOSA that use an
`intermediate Driver Manager software layer and hardware-dependent and/or service-dependent driver
`software including, for example, Open Database Connectivity (“ODBC”), Messaging API (“MAPI”),
`and Windows Extensions for Financial Services (“WOSA/XFS”).
`
`“ODBC provides a common data access API. Each application uses the same function calls to talk to
`many types of data sources through DBMS-specific drivers. A driver manager sits between the
`14
`
`4818-9757-4452.1
`
`Page 14 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`Claim 1
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`applications and the drivers, just like a print manager sits between applications and print drivers. In
`the Windows operating system, the driver manager and the drivers are implemented as DLLs.”
`Cashin at 18-19.
`
`“The ODBC driver manager loads drivers dynamically as they are needed. The driver, developed
`separately from the application, sits between the application and the network. The driver processes
`ODBC function calls and translates them to the commands required by the target data source.”
`Cashin at 20.
`
`“There are various Drivers which are activated by the Driver Manager on behalf of an application.
`Each Driver processes ODBC function calls, forwards SQL requests to the appropriate Data Source,
`and returns results to the initiating application. A Driver performs whatever syntax modification to
`the request that may be needed in order to conform to the target DBMS.” Cashin at 60.
`
`See, e.g., Cashin at Figure 4.2, p. 61 (“ODBC”):
`
`4818-9757-4452.1
`
`15
`
`Page 15 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`
`Claim 1
`
`
`
`
`
`“The Driver Manager, as described earlier, has as its primary mission the loading of
`Drivers….Drivers are DLLs that implement ODBC function calls and interact with a Data Source.
`The latter could be local or remote, utilizing one of several operating systems and network
`configurations, and feature one of the data storage products listed in Table 4.1.” Cashin at 62.
`
`“The benefits of a common user interface extend to service integration at the desktop. Services such
`as facsimile, voice support, conventional mail, and links to third-party information utilities such as
`CompuServe can be accessed from the one, universal client application (see Figure 5.4). Appropriate
`16
`
`4818-9757-4452.1
`
`Page 16 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`Claim 1
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`Drivers would be installed for each type of service offered.” Cashin at 90.
`
`“The XFS Manager maps specified APIs to the corresponding SPI, which then routes this request to
`the appropriate service provider. As illustrated in Figure 1.8, the Manager refers to a registration
`database to direct the API to the proper service provider access point.” Cashin at 126.
`
`“It is planned that manufacturers of financial peripheral devices will develop the actual service
`providers for their units.” Cashin at 126.
`
`Cashin’s description of the WOSA/XFS implementation of WOSA for the financial services industry
`states that the SPI should have similar structure to the API. See Cashin at 130 (“the SPI is
`constructed in a manner similar to the API”).
`
`See also Cashin at 21-22, Figure 1.8 at 32, 30, 86, Figure 5.3 at 86.
`
`ODBC, a software system described in Cashin as an example of WOSA, describes a driver
`architecture in which a Driver Manager relates function calls from applications to drivers via a Driver
`Manager. ODBC Programmer’s Guide at 6-7. ODBC describes a Driver Manager that passes
`function calls to drivers. The ODBC API defines core functions and two extended sets of
`functionality that extend functionality beyond the core functions. Id. at 11-12.
`
`
`4818-9757-4452.1
`
`17
`
`Page 17 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`
`Claim 1
`
`4818-9757-4452.1
`
`18
`
`Page 18 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`
`Claim 1
`
`ODBC Programmer’s Guide at 5-6.
`
`
`
`
`4818-9757-4452.1
`
`19
`
`Page 19 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`
`Claim 1
`
`4818-9757-4452.1
`
`20
`
`Page 20 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`
`Claim 1
`
`
`ODBC at 11-12.
`
`
`
`
`4818-9757-4452.1
`
`21
`
`Page 21 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`Claim 1
`
`[1D] an extended set of
`extended driver functions,
`where each extended driver
`function is associated with
`one of the non-primitive
`operations;
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`ODBC describes the Driver Manager which associates the ODBC function calls with the driver
`function calls. ODBC Programmer’s Guide at 14-15, 23-28. ODBC indicates that the Driver
`Manager can emulate functions unsupported by the driver but can also pass through function calls if
`the driver supports them. (Id.)
`WOSA uses a Service Provider Interface (“SPI”) layer that contains function definitions that service-
`providers and/or device-providers implement in software drivers to facilitate communication with and
`control over the targeted service and/or device. In WOSA, the APIs are linked to the SPIs using an
`intermediate software layer called the Driver Manager. A WOSA SPI is constructed to be similar to
`the API and the functions of the SPI layer will generally conform to the functions of the API layer so
`that if the API contains a function, the SPI will generally contain a corresponding function.
`
`“At the service-provider end, additional interfaces link to diverse functional packages. These include
`numerous database packages, mail utilities, etc. As with the aforementioned end-user APIs, service-
`provider interfaces can be expanded to encompass new products. Applications will remain
`unchanged as long as functional packages support the interface conventions defined by its SPI.”
`Cashin at 6.
`
`“WOSA solves this problem by communicating to servers through APIs. The can be linked in at
`runtime via Windows Dynamic Link Libraries (DLLs). For each functional service, a Driver
`Manager (MAPI.DLL, for example) makes the connection between the application and appropriate
`server driver, i.e., SPI.” Cashin at 8.
`
`“Additional implementations of existing services can be added by building a service provider
`interface library for the new service provider. Applications can take advantage of new service
`implementations without being modified and can take advantage of entirely new services only when
`they need to do so.” Cashin at 12.
`
`“Figure 3.1 depicts the major elements of this model where user applications invoke specified APIs as
`appropriate to the functional service being sought, e.g. messaging service. The actual service
`provider, in this case MAPI, is accessed through SPIs developed for specific messaging functions.”
`Cashin at 49.
`
`
`4818-9757-4452.1
`
`22
`
`Page 22 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`
`Claim 1
`
`See, e.g., Cashin at Figure 3.1, p. 50:
`
`
`“On a more detailed level, there are software drivers appended to the Windows operating system that
`aid the WOSA process (see Figure 3.2). Labeled WOSA drivers, they are used by SPIs to access a
`particular type of back-end functionality.” Cashin at 49.
`
`See, e.g., Cashin at Figure 3.2, p. 51:
`
`
`
`4818-9757-4452.1
`
`23
`
`Page 23 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`
`Claim 1
`
`
`
`
`See also Cashin at 15.
`
`Cashin describes many specific examples of software systems based on WOSA that use an
`intermediate Driver Manager software layer and hardware-dependent and/or service-dependent driver
`software including, for example, Open Database Connectivity (“ODBC”), Messaging API (“MAPI”),
`and Windows Extensions for Financial Services (“WOSA/XFS”).
`
`“ODBC provides a common data access API. Each application uses the same function calls to talk to
`many types of data sources through DBMS-specific drivers. A driver manager sits between the
`24
`
`4818-9757-4452.1
`
`Page 24 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`Claim 1
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`applications and the drivers, just like a print manager sits between applications and print drivers. In
`the Windows operating system, the driver manager and the drivers are implemented as DLLs.”
`Cashin at 18-19.
`
`“The ODBC driver manager loads drivers dynamically as they are needed. The driver, developed
`separately from the application, sits between the application and the network. The driver processes
`ODBC function calls and translates them to the commands required by the target data source.”
`Cashin at 20.
`
`“There are various Drivers which are activated by the Driver Manager on behalf of an application.
`Each Driver processes ODBC function calls, forwards SQL requests to the appropriate Data Source,
`and returns results to the initiating application. A Driver performs whatever syntax modification to
`the request that may be needed in order to conform to the target DBMS.” Cashin at 60.
`
`See, e.g., Cashin at Figure 4.2, p. 61 (“ODBC”):
`
`4818-9757-4452.1
`
`25
`
`Page 25 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`
`Claim 1
`
`
`
`
`
`“The Driver Manager, as described earlier, has as its primary mission the loading of
`Drivers….Drivers are DLLs that implement ODBC function calls and interact with a Data Source.
`The latter could be local or remote, utilizing one of several operating systems and network
`configurations, and feature one of the data storage products listed in Table 4.1.” Cashin at 62.
`
`“The benefits of a common user interface extend to service integration at the desktop. Services such
`as facsimile, voice support, conventional mail, and links to third-party information utilities such as
`CompuServe can be accessed from the one, universal client application (see Figure 5.4). Appropriate
`26
`
`4818-9757-4452.1
`
`Page 26 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`Claim 1
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`Drivers would be installed for each type of service offered.” Cashin at 90.
`
`“The XFS Manager maps specified APIs to the corresponding SPI, which then routes this request to
`the appropriate service provider. As illustrated in Figure 1.8, the Manager refers to a registration
`database to direct the API to the proper service provider access point.” Cashin at 126.
`
`“It is planned that manufacturers of financial peripheral devices will develop the actual service
`providers for their units.” Cashin at 126.
`
`Cashin’s description of the WOSA/XFS implementation of WOSA for the financial services industry
`states that the SPI should have similar structure to the API. See Cashin at 130 (“the SPI is
`constructed in a manner similar to the API”).
`
`See also Cashin at 21-22, Figure 1.8 at 32, 30, 86, Figure 5.3 at 86.
`
`ODBC, a software system described in Cashin as an example of WOSA, describes a driver
`architecture in which a Driver Manager relates function calls from applications to drivers via a Driver
`Manager. ODBC Programmer’s Guide at 6-7. ODBC describes a Driver Manager that passes
`function calls to drivers. The ODBC API defines core functions and two extended sets of
`functionality that extend functionality beyond the core functions. Id. at 11-12.
`
`
`4818-9757-4452.1
`
`27
`
`Page 27 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`
`Claim 1
`
`4818-9757-4452.1
`
`28
`
`Page 28 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`
`Claim 1
`
`ODBC at 5-6.
`
`
`
`
`4818-9757-4452.1
`
`29
`
`Page 29 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`
`Claim 1
`
`4818-9757-4452.1
`
`30
`
`Page 30 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`
`Claim 1
`
`
`ODBC at 11-12.
`
`
`
`
`4818-9757-4452.1
`
`31
`
`Page 31 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`Claim 1
`
`[1E] a set of component
`functions;
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`ODBC describes the Driver Manager which associates the ODBC function calls with the driver
`function calls. ODBC Programmer’s Guide at 14-15, 23-28. ODBC indicates that the Driver
`Manager can emulate functions unsupported by the driver but can also pass through function calls if
`the driver supports them. (Id.)
`The APIs of WOSA contain “component functions.” The Cashin architecture as applied to the
`motion operations of GML would result in an API that contained “component functions” that could
`be programmed and called from application programs to “define a desired motion sequence.”
`
`“The great attraction of WOSA to Windows software developers is that standardization of the
`interface to multiple software services enables their product to reach a wider audience. If, for
`example, a front-end database access product follows WOSA interface conventions, it will be able to
`interact with various database offerings, as long as the latter also follow WOSA dictates.” Cashin at
`1-2.
`
`“Applications call protocols known as Application Programming Interfaces (APIs) to access services
`that have been standardized in the Windows environment. The specific nature, configuration, etc. of
`the called service is of no concern to the calling API, at least from the viewpoint of access
`procedures.” Cashin at 2.
`
`“WOSA’s operational plan (see Figure 1.1) includes an abstraction layer that provides interaction
`with heterogeneous computing devices via a set of APIs. Windows-based applications, using these
`APIs, can operate from a variety of end-user devices. New end-user devices can be added as they
`enter the marketplace. Meanwhile, applications remain unchanged as long as they employ WOSA
`APIs.” Cashin at 6.
`
`“Instead of having to learn a different set of APIs for each implementation of a service, programmers
`creating WOSA applications need only learn a single set of APIs for all implementations of a
`particular service. In addition, applications remain stable no matter what changes are made to
`functional services as long as these services communicate through the WOSA interface.” Cashin at 6.
`
`“WOSA provides a single, consistent, system level interface between Windows-based PCs and
`various enterprise computing resources (see Figure 1.2). By exploiting the WOSA interface, a
`
`4818-9757-4452.1
`
`32
`
`Page 32 of 90
`
`RA v. AMS
`Ex. 1028
`
`
`
`Claim 1
`
`First Amended Exhibit N2 – Invalidity Claim Chart for U.S. Patent No. 6,516,236
`Cashin/GML/ODBC/Brockschmidt
`Cashin, GML, and ODBC
`Windows-driven desktop application need not know anything about computing resources on the
`network in order to gain access to enterprise functions such as mail, databases, licensing, or remote
`procedure calls (RPCs).” Cashin at 8.
`
`“WOSA solves this problem by communicating to servers through APIs. The can be linked in at
`runtime via Windows Dynamic Link Libraries (DLLs). For each functional service, a Driver
`Manager (MAPI.DLL, for example) makes the connection between the application and appropriate
`server driver, i.e., SPI.” Cashin at 8.
`
`“By providing access to various implementations of back-end services, WOSA eliminates the need
`for application developers to develop sol