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”);
`Compumotor Motion Toolbox User Guide, A Library of LabView Virtual Instruments for Motion Control (“Motion Toolbox”).
`
`Defendants assert that, based on the scope of the claims as asserted by AMS in its infringement contentions, disclosures of WOSA,
`ODBC, Brockschmidt, and Motion Toolbox 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 Motion Toolbox reference,
`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 “Motion
`Toolbox” is used to refer to both the disclosures of the Motion Toolbox reference 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, Motion Toolbox, 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.
`
`“Instead of having to learn a different set of APIs for each implementation of a service, programmers
`
`Page 1 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, and ODBC
`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.”
`Cashin at 49.
`
`
`
`
`Page 2 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, and ODBC
`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
`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
`
`Page 3 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, and ODBC
`can include printers, magnetic stripe readers/writers, PIN pads, cash dispensers, check readers, and
`image scanners. See Cashin at 126.
`
`
`Page 4 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`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
`
`Cashin, Motion Toolbox, and ODBC
`Motion Toolbox was a library of motion control software instruments (“virtual instruments,” or
`“VIs”) for LabVIEW, developed by Snider Consultants, Inc. for Computmotor’s 6000 series of
`motion controllers. Motion Toolbox allows LabVIEW programmers to develop motion control
`systems for a wide range of applciations incluing automated test and manufacturing, machine control,
`and laboratory automation. Motion Toolbox provided developers with motion control capabilities
`including velocity, acceleration, deceleration, go, stop, kill, etc. See Motion Toolbox at 1.
`
`Motion Toolbox contains a library of VIs that programmers could use to develop motion control
`systems and programs. The Cashin architecture as applied to the VIs of Motion Toolbox would result
`in an API with functions that could be called from application programs to define a desired motion
`sequence.
`
`Motion Toolbox defines VIs including Initiate Motion, Stop Motion, Set Distance, Set Velocity, Set
`Acceleration, Set Deceleration, Set Direction, Set Position, and Set Path Velocity and Acceleration.
`See Motion Toolbox at 85-93.
`
`See, e.g., Motion Toolbox at 85 (Initiate Motion VI):
`
`See, e.g., Motion Toolbox at 86 (Stop Motion VI):
`
`
`
`Page 5 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, and ODBC
`
`See, e.g., Motion Toolbox at 86 (Set Distance VI):
`
`
`
`See, e.g., Motion Toolbox at 88 (Set Velocity VI):
`
`
`
`Page 6 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, and ODBC
`
`See, e.g., Motion Toolbox at 88 (Set Acceleration VI):
`
`See, e.g., Motion Toolbox at 89 (Set Deceleration VI):
`
`
`
`
`
`Page 7 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, and ODBC
`
`See, e.g., Motion Toolbox at 89 (Set Direction VI):
`
`See, e.g., Motion Toolbox at 91 (Set Position VI):
`
`
`
`
`
`Page 8 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, and ODBC
`
`See, e.g., Motion Toolbox at 93 (Set Path Vel & Acc VI):
`
`
`
`Page 9 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, and ODBC
`
`
`
`Page 10 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`[1B] a non-primitive
`operation that does not meet
`the definition of a primitive
`operation;
`
`Cashin, Motion Toolbox, and ODBC
`Motion Toolbox was a library of motion control software instruments (“virtual instruments,” or
`“VIs”) for LabVIEW, developed by Snider Consultants, Inc. for Computmotor’s 6000 series of
`motion controllers. Motion Toolbox allows LabVIEW programmers to develop motion control
`systems for a wide range of applciations incluing automated test and manufacturing, machine control,
`and laboratory automation. Motion Toolbox provided developers with motion control capabilities
`including velocity, acceleration, deceleration, go, stop, kill, etc. See Motion Toolbox at 1.
`
`Motion Toolbox contains a library of VIs that programmers could use to develop motion control
`systems and programs. The Cashin architecture as applied to the VIs of Motion Toolbox would result
`in an API with functions that could be called from application programs to define a desired motion
`sequence.
`
`Motion Toolbox defines an “Initiate Linear Interpolated Motion” VI that is based upon an end point
`dictated by the Set Distance VI, and velocity and acceleration determined by the Set Path Vel & Acc
`VI. In other words, the Initiate Linear Interpolated Motion VI defines a motion operation that may be
`simulated using a combination of other operations including the Set Distance VI and the Set Path Vel
`& Acc VI. Motion Toolbox at 90-91:
`
`
`
`Page 11 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, and ODBC
`
`
`Motion Toolbox also discloses that the Set Path Vel & Acc VI can be used for contouring moves.
`Motion Toolbox at 93.
`
`
`
`
`
`Motion Toolbox also discloses Go Home, Run Path, and Run Program VIs:
`
`See, e.g., Motion Toolbox at 90 (Go Home VI):
`
`
`
`Page 12 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, and ODBC
`
`
`See, e.g., Motion Toolbox at 92 (Run Path VI):
`
`
`
`Page 13 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, and ODBC
`
`See, e.g., Motion Toolbox at 93 (Run Program VI):
`
`
`
`
`
`
`
`Page 14 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`[1C] a core set of core driver
`functions, where each core
`driver function is associated
`with one of the primitive
`operations;
`
`Cashin, Motion Toolbox, 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:
`
`Page 15 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, and ODBC
`
`
`“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:
`
`
`
`Page 16 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, and ODBC
`
`
`
`
`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
`
`Page 17 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, 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”):
`
`Page 18 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, and ODBC
`
`
`
`
`
`“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
`
`Page 19 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, 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.
`
`
`Page 20 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, and ODBC
`
`
`
`Page 21 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, and ODBC
`
`ODBC Programmer’s Guide at 5-6.
`
`
`
`
`Page 22 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, and ODBC
`
`
`
`Page 23 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, and ODBC
`
`
`ODBC Programmer’s Guide at 11-12.
`
`
`
`
`Page 24 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`[1D] an extended set of
`extended driver functions,
`where each extended driver
`function is associated with
`one of the non-primitive
`operations;
`
`Cashin, Motion Toolbox, 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.
`
`
`Page 25 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, and ODBC
`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:
`
`
`
`Page 26 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, and ODBC
`
`
`
`
`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
`
`Page 27 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, 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”):
`
`Page 28 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, and ODBC
`
`
`
`
`
`“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
`
`Page 29 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, 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.
`
`
`Page 30 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, and ODBC
`
`
`
`Page 31 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, and ODBC
`
`ODBC at 5-6.
`
`
`
`
`Page 32 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, and ODBC
`
`
`
`Page 33 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, and ODBC
`
`
`ODBC at 11-12.
`
`
`
`
`Page 34 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`[1E] a set of component
`functions;
`
`Cashin, Motion Toolbox, 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
`
`Page 35 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, 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 solutions for each new service implementation. Programmers
`can provide access to new implementations by plugging existing components together.” Cashin at 11.
`
`“With a standard API to access a variety of back-end services, WOSA reduces the burden on the
`back-end service vendor in both of these areas. Because new implementations of back-end services
`can be accessed from a common API, the vendor’s system software requirement is limited to
`providing the service provider interface library for their service. Applications that use WOSA to
`integrate services from various back-ends can be used without modification with new
`implementations of the service.” Cashin at 15.
`
`See also Cashin at 1-2, 5, Figure 1.1 at 7, 10-12, Figure 1.2 at 17, 46, Figure 2.3 at 47, 49, Figure 3.1
`at 50.
`
`Cashin describes many specific examples of software systems based on WOSA that contain libraries
`of hardware-independent and/or service-independent functions 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
`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.”
`
`Page 36 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, and ODBC
`
`Cashin at 18-19.
`
`See, e.g., Cashin at Figure 4.2, p. 61 (“ODBC”):
`
`
`“Applications can now access different databases as needed for various tasks – as long as the target
`database conforms to ODBC conventions. A user may access Oracle, then Sybase, then Informix
`databases on various occasions as required. As long as the database is ODBC-compliant, the
`application itself remains unchanged.” Cashin at 67.
`
`“MAPI has been designed to assure developers who write front-end applications or back-end services
`
`
`
`Page 37 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, and ODBC
`for their operating environments that they will interoperate successfully. This is done by publishing
`the interfaces between these services in the form of APIs and SPIs (see Figure 1.1).” Cashin at 21.
`
`“It works similar to their print drivers, i.e., different print drivers work in conjunction with Windows
`software, rather than directly with each application. This allows applications to function with a
`variety of printers. MAPI’s messaging subsystem employs the same approach – different messaging
`applications can communicate with a variety of messaging services. MAPI is one of the first to
`integrate its services into the resident operating system.” Cashin at 85.
`
`“When an API is initiated, a command or function call is invoked. It tells the underlying messaging
`subsystem what action is required. The messaging subsystem does not replace functionality provided
`by packages such as X.400, Novell’s MHS, etc. Rather, it performs services that shield the user from
`the distinctness present in these packages.” Cashin at 85.
`
`“As depicted in Figure 5.3, MAPI APIs service the application, MAPI SPIs accommodate different
`message system providers, and Windows messaging subsystem capabilities ensure that all users have
`the same tools.” Cashin at 86.
`
`“The core elements of XFS are definitions for a set of APIs, along with their corresponding SPIs, plus
`supporting services, that allow Windows applications to access financial services software and
`hardware. These standard APIs allow applications to access differing service providers without
`altering application code, much like all WOSA components.” Cashin at 125.
`
`“The XFS architecture is shown in Figure 1.8. As shown, applications communicate with services
`and devices via the XFS Manager, using the API set. Most of these APIs can be initiated
`synchronously or asynchronously. In the former, the Manager causes the application to wait until the
`API’s function is completed. With asynchronous, the application regains control immediately, while
`the function is performed in parallel.” Cashin at 125.
`
`See, e.g., Cashin at Figure 1.8, p. 32 (“WOSA/XFS”):
`
`Page 38 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`
`Cashin, Motion Toolbox, and ODBC
`
`[1F] component code
`associated with each of the
`component functions, where
`the component code
`associates at least some of the
`component functions with at
`
`
`See also Cashin at 22, 30, Figure 5.3 at 86, 87, 126.
`In WOSA, the APIs are linked to the SPIs using an intermediate software layer generally called the
`Driver Manager. This Driver Manager software layer receives the API function calls from the
`applications and calls the appropriate driver functions of the SPI in the appropriate software driver.
`
`“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
`
`
`
`Page 39 of 96
`
`RA v. AMS
`Ex. 1029
`
`

`
`Claim 1
`least some of the driver
`functions; and
`
`Cashin, Motion Toolbox, and ODBC
`Manager (MAPI.DLL, for example) makes the connection between the application and appropriate
`server driver, i.e., SPI.” Cashin at 8.
`
`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 Servic