WOSA
`
`(Windows"' Open Services Architecture)
`
`Extensions for Financial Services
`
`A C1ient—Server Architecture
`
`for Financial Enterprise Computing
`
`under Microsoft® Windows
`
`Revision 1.1
`
`April 14, 1994
`
`Develo d b the members of the Bankin S stems Vendor Council:
`
`Andersen Consulting
`AT&T Global Information Solutions
`
`Digital Equipment Corporation
`
`EDS Corporation
`
`International Computers Limited
`Microsoft Corporation
`Ing. C. Olivetti & C. S.p.A.
`Siemens Nixdorf Informationssysteme AG
`Tandem Computers
`Unisys Corporation
`
`AMS
`
`Exhibit 2005
`
`RA v AMS
`
`IPR20 1 7—00049
`
`ABB Inc’
`EXHIBIT 1003
`
`Page 1 of 228
`
`

`

`WOSA Extensions for Financial Services, Revision 1.1
`
`
`April 14, 1994
`
`ii
`
`Revision History:
`0.71
`1.0
`1.01
`
`
`
`
`December 17, 1992
`May 24, 1993
`
`June 11, 1993
`
`
`Preliminary release of API specification
`Initial release of API and SPI specification
`Minor updates to BSVC member contact list
`
`1.1
`
`
`
`April 14, 1994
`
`
`
`Major updates and additions
`
`
`
`
`
`
`
`
`The information in this document was contributed by members of the Banking Systems Vendor Council and
`represents its current views on the issues discussed as of the date of publication. It is furnished for
`informational purposes only and is subject to change without notice. The Banking Systems Vendor Council
`makes no warranty, express or implied, with respect to this document.
`
`Microsoft is a registered trademark, and Windows and Windows NT are trademarks of Microsoft
`Corporation.
`
`
`Apple and Macintosh are registered trademarks of Apple Computer, Inc.
`
`IBM and NetView are registered trademarks of International Business Machines Corporation.
`
`UNIX is a registered trademark of UNIX Systems Laboratories.
`
`Microsoft part number: 098-54431
`Page 2 of 228
`
`
`
`
`
` AMS
` Exhibit 2005
` RA v AMS
` IPR2017-00049
`
`

`

`WOSA Extensions for Financial Services, Revision 1.1
`
`
`April 14, 1994
`
`iii
`
`Table of Contents
`
`1. Introduction
`1.1 Background
`1.2 Objectives
`1.3 Strategies
`1.4 Benefits
`2. WOSA Extensions for Financial Services Overview
`2.1 Architecture
`2.2 API and SPI Summary
`2.3 Device Classes
`3. Other WOSA Components
`3.1 Enterprise Communications
`3.1.1 Windows SNA APIs
`3.1.2 Windows RPC (Remote Procedure Call)
`3.1.3 Windows Sockets
`3.2 MAPI (Messaging API)
`3.3 ODBC (Open Database Connectivity)
`3.4 License Service API
`3.5 Windows Telephony API
`3.6 WOSA Extensions for Real-Time Market Data
`4. The Future of WOSA and the Extensions for Financial Services
`4.1 Financial Transaction Messaging and Management
`4.2 Network and System Management
`4.3 Security
`4.4 Emerging technologies
`5. Architectural and Implementation Issues
`5.1 The XFS Manager
`5.2 Service Providers
`5.2.1 Service Provider Functionality
`5.2.2 Service Provider “Packaging”
`5.3 Asynchronous, Synchronous and Immediate Functions
`5.3.1 Asynchronous Functions
`5.3.2 Synchronous Functions
`5.3.3 Immediate Functions
`5.4 Processing API Functions
`5.5 Opening a session
`5.6 Closing a Session
`5.7 Configuration Information
`5.8 Exclusive Service and Device Access
`5.8.1 Lock Policy for Independent Devices
`5.8.2 Compound Devices
`5.9 Timeout
`5.10 Function Status Return
`5.11 Notification Mechanisms — Registering for Events
`5.12 Application Processes, Threads and Blocking Functions
`5.13 Memory Management
`
`1
`1
`1
`2
`3
`4
`5
`8
`9
`10
`10
`10
`11
`11
`11
`11
`12
`12
`12
`13
`13
`13
`13
`13
`14
`14
`15
`15
`16
`16
`16
`16
`17
`17
`18
`19
`20
`23
`23
`24
`26
`26
`27
`29
`31
`
`
`
`Page 3 of 228
`
` AMS
` Exhibit 2005
` RA v AMS
` IPR2017-00049
`
`

`

`WOSA Extensions for Financial Services, Revision 1.1
`
`
`April 14, 1994
`
`6. Application Programming Interface (API) Functions
`6.1 WFSCancelAsyncRequest
`6.2 WFSCancelBlockingCall
`6.3 WFSCleanUp
`6.4 WFSClose
`6.5 WFSAsyncClose
`6.6 WFSCreateAppHandle
`6.7 WFSDeregister
`6.8 WFSAsyncDeregister
`6.9 WFSDestroyAppHandle
`6.10 WFSExecute
`6.11 WFSAsyncExecute
`6.12 WFSFreeResult
`6.13 WFSGetInfo
`6.14 WFSAsyncGetInfo
`6.15 WFSGetSCode
`6.16 WFSIsBlocking
`6.17 WFSLock
`6.18 WFSAsyncLock
`6.19 WFSOpen
`6.20 WFSAsyncOpen
`6.21 WFSRegister
`6.22 WFSAsyncRegister
`6.23 WFSSetBlockingHook
`6.24 WFSStartUp
`6.25 WFSUnhookBlockingHook
`6.26 WFSUnlock
`6.27 WFSAsyncUnlock
`
`iv
`
`33
`35
`36
`37
`38
`39
`40
`41
`42
`44
`45
`47
`49
`50
`52
`54
`55
`56
`58
`60
`63
`66
`68
`70
`71
`73
`74
`75
`
`
`
`Page 4 of 228
`
` AMS
` Exhibit 2005
` RA v AMS
` IPR2017-00049
`
`

`

`April 14, 1994
`
`WOSA Extensions for Financial Services, Revision 1.1
`
`
`7. Service Class Definitions
`7.1 Printers
`7.1.1 Banking Printer Types
`7.1.2 Forms Model
`7.1.3 Command Overview
`7.1.4 Info Commands
`7.1.4.1 WFS_INF_PTR_STATUS
`7.1.4.2 WFS_INF_PTR_CAPABILITIES
`7.1.4.3 WFS_INF_PTR_FORM_LIST
`7.1.4.4 WFS_INF_PTR_MEDIA_LIST
`7.1.4.5 WFS_INF_PTR_QUERY_FORM
`7.1.4.6 WFS_INF_PTR_QUERY_MEDIA
`7.1.4.7 WFS_INF_PTR_QUERY_FIELD
`7.1.5 Execute Commands
`7.1.5.1 WFS_CMD_PTR_CONTROL_MEDIA
`7.1.5.2 WFS_CMD_PTR_PRINT_FORM
`7.1.5.3 WFS_CMD_PTR_READ_FORM
`7.1.5.4 WFS_CMD_PTR_RAW_DATA
`7.1.5.5 WFS_CMD_PTR_MEDIA_EXTENTS
`7.1.6 Execute Events
`7.1.6.1 WFS_EXEE_PTR_NOMEDIA
`7.1.6.2 WFS_EXEE_PTR_MEDIAINSERTED
`7.1.6.3 WFS_EXEE_PTR_FIELDERROR
`7.1.6.4 WFS_EXEE_PTR_FIELDWARNING
`7.1.7 Form and Media Definition
`7.1.7.1 Form Definition
`7.1.7.2 Field Definition
`7.1.7.3 Media Definition
`7.2 Magnetic Stripe Readers and Writers
`7.2.1 Info Commands
`7.2.1.1 WFS_INF_IDC_STATUS
`7.2.1.2 WFS_INF_IDC_CAPABILITIES
`7.2.2 Execute Commands
`7.2.2.1 WFS_CMD_IDC_READ_TRACK
`7.2.2.2 WFS_CMD_IDC_WRITE_TRACK
`7.2.2.3 WFS_CMD_IDC_EJECT_CARD
`7.2.2.4 WFS_CMD_IDC_RETAIN_CARD
`7.2.2.5 WFS_CMD_IDC_RESET_COUNT
`7.2.2.6 WFS_CMD_IDC_RESET
`7.2.3 Messages
`7.2.3.1 WFS_EXEE_IDC_INVALIDTRACKDATA
`7.2.3.2 WFS_EXEE_IDC_NOMEDIA
`7.2.3.3 WFS_EXEE_IDC_MEDIAINSERTED
`7.2.3.4 WFS_EXEE_IDC_MEDIAREMOVED
`7.2.3.5 WFS_SRVE_IDC_CARDACTION
`7.2.3.6 WFS_USRE_IDC_RETAINBINFULL
`7.2.4 Form Description
`7.3 Cash Dispensers
`7.3.1 Info Commands
`7.3.1.1 WFS_INF_CDM_STATUS
`7.3.1.2 WFS_INF_CDM_CAPABILITIES
`7.3.1.3 WFS_INF_CDM_CASH_UNIT_INFO
`7.3.1.4 WFS_INF_CDM_TELLER_INFO
`7.3.1.5 WFS_INF_CDM_TELLER_POSITIONS
`7.3.1.6 WFS_INF_CDM_CURRENCY_EXP
`7.3.1.7 WFS_INF_CDM_MIX_TYPES
`7.3.1.8 WFS_INF_CDM_MIX_TABLE
`
`v
`
`76
`77
`78
`78
`80
`81
`81
`83
`84
`84
`85
`87
`88
`90
`90
`91
`93
`94
`95
`96
`96
`96
`96
`97
`98
`98
`99
`102
`103
`104
`104
`106
`108
`108
`109
`110
`110
`111
`111
`112
`112
`112
`112
`112
`113
`113
`114
`116
`117
`117
`118
`120
`122
`123
`123
`124
`125
`
`
`
`Page 5 of 228
`
` AMS
` Exhibit 2005
` RA v AMS
` IPR2017-00049
`
`

`

`WOSA Extensions for Financial Services, Revision 1.1
`
`
`April 14, 1994
`
`7.3.2 Execute Commands
`7.3.2.1 WFS_CMD_CDM_DENOMINATE
`7.3.2.2 WFS_CMD_CDM_DISPENSE
`7.3.2.3 WFS_CMD_CDM_PRESENT
`7.3.2.4 WFS_CMD_CDM_REJECT
`7.3.2.5 WFS_CMD_CDM_RETRACT
`7.3.2.6 WFS_CMD_CDM_CASH_IN
`7.3.2.7 WFS_CMD_CDM_OPEN_SHUTTER
`7.3.2.8 WFS_CMD_CDM_CLOSE_SHUTTER
`7.3.2.9 WFS_CMD_CDM_SET_TELLER_INFO
`7.3.2.10 WFS_CMD_CDM_SET_CASH_UNIT_INFO
`7.3.2.11 WFS_CMD_CDM_START_EXCHANGE
`7.3.2.12 WFS_CMD_CDM_END_EXCHANGE
`7.3.2.13 WFS_CMD_CDM_OPEN_SAFE_DOOR
`7.3.2.14 WFS_CMD_CDM_CHECK_VANDALISM
`7.3.3 Messages
`7.3.3.1 WFS_SRVE_CDM_SAFEDOOROPEN
`7.3.3.2 WFS_SRVE_CDM_SAFEDOORCLOSED
`7.3.3.3 WFS_USRE_CDM_CASHUNITTHRESHOLD
`7.3.3.4 WFS_SRVE_CDM_CASHUNITINFOCHANGED
`7.3.3.5 WFS_SRVE_CDM_TELLERINFOCHANGED
`7.3.3.6 WFS_EXEE_CDM_DELAYEDDISPENSE
`7.3.3.7 WFS_EXEE_CDM_STARTDISPENSE
`7.3.3.8 WFS_EXEE_CDM_CASHUNITERROR
`7.4 Personal Identification Number (PIN) Keypads
`7.4.1 Info Commands
`7.4.1.1 WFS_INF_PIN_STATUS
`7.4.1.2 WFS_INF_PIN_CAPABILITIES
`7.4.1.3 WFS_INF_PIN_KEY_LIST
`7.4.1.4 WFS_INF_PIN_KEY_DETAIL
`7.4.2 Execute Commands
`7.4.2.1 WFS_CMD_PIN_CRYPT
`7.4.2.2 WFS_CMD_PIN_GENERATE_KEY
`7.4.2.3 WFS_CMD_PIN_IMPORT_KEY
`7.4.2.4 WFS_CMD_PIN_TRANSLATE
`7.4.2.5 WFS_CMD_PIN_GET_PIN
`7.4.2.6 WFS_CMD_PIN_VALIDATE
`7.4.2.7 WFS_CMD_PIN_GET_PIN BLOCK
`7.4.2.8 WFS_CMD_PIN_GET_DATA
`7.4.2.9 WFS_CMD_PIN_ADMINISTRATION
`7.4.2.10 WFS_CMD_PIN_DISPLAY
`7.4.3 Messages
`7.4.3.1 WFS_EXEE_PIN_DIGIT
`7.5 Check Readers and Scanners
`7.5.1 Info Commands
`7.5.1.1 WFS_INF_CHK_STATUS
`7.5.1.2 WFS_INF_CHK_CAPABILITIES
`7.5.1.3 WFS_INF_CHK_FORM_LIST
`7.5.1.4 WFS_INF_CHK_QUERY_FORM
`7.5.1.5 WFS_INF_CHK_QUERY_FIELD
`7.5.2 Execute Commands
`7.5.2.1 WFS_CMD_CHK_READ_FORM
`7.5.2.2 WFS_CMD_CHK_MULTICOMMAND
`7.5.2.3 WFS_CMD_CHK_READ_IMAGE
`7.5.2.4 WFS_CMD_CHK_MODE_SWITCH
`7.5.3 Pragmatics of using the commands
`7.5.4 Execute Events, Results, Codes
`7.5.4.1 WFS_EXEE_CHK_NOMEDIA
`7.5.4.2 WFS_EXEE_CHK_MEDIAINSERTED
`7.5.5 Forms Language Usage
`
`vi
`
`126
`126
`129
`131
`131
`131
`132
`133
`133
`133
`134
`134
`135
`135
`135
`136
`136
`136
`136
`136
`136
`137
`137
`137
`138
`139
`139
`140
`142
`142
`143
`143
`145
`146
`147
`148
`150
`152
`153
`154
`155
`156
`156
`157
`158
`158
`159
`160
`160
`161
`162
`162
`164
`166
`167
`168
`168
`168
`168
`169
`
`
`
`Page 6 of 228
`
` AMS
` Exhibit 2005
` RA v AMS
` IPR2017-00049
`
`

`

`WOSA Extensions for Financial Services, Revision 1.1
`
`
`April 14, 1994
`
`8. Service Provider Interface (SPI) Functions
`8.1 WFPCancelAsyncRequest
`8.2 WFPClose
`8.3 WFPDeregister
`8.4 WFPExecute
`8.5 WFPGetInfo
`8.6 WFPLock
`8.7 WFPOpen
`8.8 WFPRegister
`8.9 WFPSetTraceLevel
`8.10 WFPUnloadService
`8.11 WFPUnlock
`9. Support Functions
`9.1 WFMAllocateBuffer
`9.2 WFMAllocateMore
`9.3 WFMFreeBuffer
`9.4 WFMGetTraceLevel
`9.5 WFMKillTimer
`9.6 WFMMakeResult
`9.7 WFMOutputTraceData
`9.8 WFMReleaseDLL
`9.9 WFMSetTimer
`9.10 WFMSetTraceLevel
`10. Configuration Functions
`10.1 WFMCloseKey
`10.2 WFMCreateKey
`10.3 WFMDeleteKey
`10.4 WFMDeleteValue
`10.5 WFMEnumKey
`10.6 WFMEnumValue
`10.7 WFMOpenKey
`10.8 WFMQueryValue
`10.9 WFMSetValue
`
`vii
`
`170
`171
`172
`173
`175
`177
`179
`180
`183
`184
`186
`187
`188
`188
`189
`189
`190
`190
`191
`191
`192
`193
`194
`196
`197
`197
`198
`198
`199
`200
`201
`202
`203
`
`
`
`Page 7 of 228
`
` AMS
` Exhibit 2005
` RA v AMS
` IPR2017-00049
`
`

`

`WOSA Extensions for Financial Services, Revision 1.1
`
`
`April 14, 1994
`
`Appendix A - Data Structures
`A.1 WFSRESULT
`A.2 WFSVERSION
`Appendix B - Messages
`B.1 Command Completions and Events
`B.1.1 Command Completion Messages
`B.1.2 Event Messages
`B.2 Timer Events
`B.3 Device Status Changes
`B.4 Undeliverable Messages
`B.5 Hardware Errors
`B.6 Version Negotiation Failures
`Appendix C - Error Codes
`Appendix D - Planned Enhancements and Extensions
`D.1 Event and System Management
`D.1.1 WFMReportEvent
`D.2 Administration Function Definitions
`D.2.1 WFSLoad
`D.2.2 WFSReset
`D.2.3 WFSResume
`D.2.4 WFSSuspend
`D.2.5 WFSUnload
`Appendix E - Banking System Vendor Council Contacts
`Appendix F - Other WOSA Specifications and Information
`
`viii
`
`1
`1
`2
`3
`3
`3
`3
`3
`4
`5
`6
`7
`8
`11
`11
`11
`12
`12
`12
`12
`13
`13
`14
`17
`
`
`
`Page 8 of 228
`
` AMS
` Exhibit 2005
` RA v AMS
` IPR2017-00049
`
`

`

`WOSA Extensions for Financial Services, Revision 1.1
`
`
`1.
`
`Introduction
`
`April 14, 1994
`
`1
`
`This is Revision 1.1 of the specification for the Windows Open Services Architecture, Extensions for
`Financial Services (WOSA/XFS). The Software Development Kit (SDK), which will supply the
`components and tools to allow the implementation of compliant applications and services, is now in beta
`testing. This specification is being distributed to the financial services community for continuing review
`and comment, which will provide additional input to the testing and enhancement of the SDK. An
`updated version of this specification will be included in the production version of the SDK.
`
`The members of the Banking Systems Vendor Council encourage banks and other financial services
`companies world-wide, as well as their technology suppliers, to get updated information on the status of
`the project, and to submit comments, questions, and requests for the SDK and updated specification
`(when available). This may be done on CompuServe, in the Microsoft developer services area in the
`Windows Extensions forum (“GO WINEXT”), in the WOSA/XFS message section and library, or via one
`of the member contacts listed in Appendix E.
`
`The Banking Systems Vendor Council is accepting applications for affiliate membership; interested
`parties should also contact one of the Council members.
`
`
`1.1
`
`Background
`
`The Banking Systems Vendor Council, an organization of leading vendors of information technology to the financial
`services industry, was formally announced at the American Bankers Association National Operations and
`Automation Conference (NOAC) in Denver on May 18, 1992. Revision 1.0 of this specification was released at
`NOAC in New Orleans on May 24, 1993.
`
`The charter members of the Banking Systems Vendor Council are:
`
`• Andersen Consulting
`• AT&T Global Information Solutions
`• Digital Equipment Corporation
`• EDS Corporation
`•
`International Computers Limited
`
`• Microsoft Corporation
`•
`Ing. C. Olivetti & C. S.p.A.
`• Siemens Nixdorf Informationssysteme AG
`• Tandem Computers
`• Unisys Corporation
`
`
`The Banking Systems Vendor Council has held many multi-vendor development meetings, in addition to numerous
`additional hours invested in defining this specification for the WOSA Extensions for Financial Services.
`
`
`
`1.2 Objectives
`
`The charter of the Banking Systems Vendor Council is to develop an approach to financial enterprise computing that
`will allow financial institutions to develop complete, consistent sets of solutions that meet these objectives:
`• Reduce the costs of software development and maintenance by:
`•
`improving the efficiency and productivity of development organizations,
`•
`reducing the costs of developer training, and
`•
`allowing the use of a much larger set of existing applications.
`Improve the "time to market" of new applications via easier development and rapid deployment.
`•
`• Allow institutions the flexibility to build systems modularly, using the largest possible range of hardware
`and software products from multiple vendors, and to upgrade these systems incrementally while maximizing
`the value of the original investment.
`• Define an architecture that allows scalability of solutions across a broad range of hardware platforms.
`• Encourage the development of more and better applications by promoting widespread adoption of standard
`interfaces and platforms.
`• Reduce the costs of training users.
`
`Page 9 of 228
`
`
`
` AMS
` Exhibit 2005
` RA v AMS
` IPR2017-00049
`
`

`

`WOSA Extensions for Financial Services, Revision 1.1
`
`April 14, 1994
`
`2
`
`1.3
`
`Strategies
`
`The following key strategies have been adopted by the Banking Systems Vendor Council to implement the objectives
`defined above:
`
`0 Use the Microsoft® Windows” operating systems family as the strategic platform for client—server
`computing.
`0 Adopt the Windows Open Service Architecture (WOSA) family of open interfaces and associated services
`for the integration of Windows and Windows-based applications into enterprise computing solutions.
`0 Utilize existing WOSA elenents wherever possible, defining new elements, or extensions to existing
`elements, only when no suitable candidate(s) exist in the evolving WOSA family that meet the needs of
`financial services computing. In all cases, existing formal or de facto standards will be utilized to the
`maximum degree possible.
`Enhance WOSA with the Extensions for Financial Services to meet the special requirements of financial
`applications for access to services and devices.
`0 Maintain the highest possible level of compatibility of both the API and SP] specifications as the Extensions
`for Financial Services evolve to include new and enhanced capabilities.
`
`0
`
`WOSA comprises a family of stable, open-ended interfaces for enterprise computing environments that hides system
`complexities from users and application developers. WOSA allows the integration of Windows and Windows-based
`applications seamlessly with all the services and enterprise capabilities that application developers and users need. It
`includes such interfaces as:
`
`0 Open Database Connectivity (ODBC) for standard access to databases,
`0 Messaging Application Prograrmning Interface (MAPI) for standard access to messaging services, and
`0
`communications support, including Windows SNA, RPC, and Sockets.
`Each of the elements of WOSA includes a set of Application Program Interfaces (APIS) and Service Provider
`Interfaces (SPIs), with associated supporting software. The architecture of WOSA is shown below:
`
`Window s-based
`
`
`
`W OSA: Windows 0 en Services Architecture
`
`For additional infomlation on WOSA, see the WOSA Backgrounder (Microsoft part number 098-34801).
`
`The Extensions for Financial Services extend WOSA by defining a Windows-based client—server architecture for
`financial applications. The extensions (as with the other elements of WOSA) include a set of APIs and SPIs
`corrunon to multiple financial applications.
`
`The WOSA Extensions for Financial Services are planned to include specifications for access to financial
`peripherals (such as passbook/joumallreceipt printers, magnetic card readerslwriters, PIN pads, etc.), financial
`transaction messaging and management, as well as related services for financial networks such as network and
`systems management and security. All these capabilities are specified for access from the familiar, consistent
`Microsoft Windows user interface and programming enviromnents. Whenever possible, the capabilities will be
`incorporated into the family of standard WOSA elements, and will utilize existing fomral and de facto standards.
`Page 10 of 228
`
`AMS
`
`Exhibit 2005
`
`RA V AMS
`
`IPR2017-00049
`
`applications
`
`Windows APIS
`
`Windows
`
`Windows SPIs
`
`Service
`
`providers
`
`

`

`WOSA Extensions for Financial Services, Revision 1.1
`
`
`1.4
`
`Benefits
`
`April 14, 1994
`
`3
`
`Adoption of the Windows platforms, the WOSA architecture and the Extensions for Financial Services will deliver a
`wide range of benefits to banks and other financial services institutions, satisfying the objectives stated above by
`allowing them to:
`• Access financial services and devices using standard Windows user and programming interfaces, with the
`resultant savings in user and developer training.
`• Utilize the large, growing range of Windows-based applications and development tools.
`• Exploit the variety of products that will be developed by the multiple vendors that will support this initiative.
`• Develop applications which will be able to run with few or no changes on the full range of Windows operating
`systems (and associated range of hardware platforms). The Windows family consists of the Windows version
`3.1, Windows™ for Workgroups and Windows NT™ operating systems. Future versions of the Windows
`operating systems family will also be supported.
`• Deploy modular and adaptable line of business solutions (financial services delivery systems, relationship
`banking, etc.) to address the changing conditions experienced in today's markets.
`
`
`Note that since the interfaces specified in WOSA are open and utilize many industry standards, vendors and users
`have many options to develop solutions that involve interoperatibility with other operating system platforms.
`
`
`
`Page 11 of 228
`
` AMS
` Exhibit 2005
` RA v AMS
` IPR2017-00049
`
`

`

`WOSA Extensions for Financial Services, Revision 1.1
`
`
`April 14, 1994
`
`4
`
`2. WOSA Extensions for Financial Services Overview
`
`A key element of the Extensions for Financial Services is the definition of a set of APIs, a corresponding set of SPIs,
`and supporting services, providing access to financial services for Windows-based applications. The definition of
`the functionality of the services, of the architecture, and of the API and SPI sets, is outlined in this section, and
`described in detail in Sections 5 through 10.
`
`The specification defines a standard set of interfaces such that, for example, an application that uses the API set to
`communicate with a particular service provider can work with a service provider of another conformant vendor,
`without any changes.
`
`The specification is intended to be usable within all implementations and versions of the Windows operating
`systems, from Windows version 3.1, Windows for Workgroups version 3.1 and the initial versions of Windows NT,
`and onwards. It thus provides for both 16 and 32 bit operating environments (operating under the Win32s subsystem
`in 16 bit environments).
`
`Although the WOSA Extensions for Financial Services define a general architecture for access to service providers
`from Windows-based applications, the initial focus of the Banking Systems Vendor Council has been on providing
`access to peripheral devices that are unique to financial institutions. Since these devices are often complex, difficult
`to manage and proprietary, the development of a standardized interface to them from Windows-based applications
`and Windows operating systems can offer financial institutions and their solution providers immediate enhancements
`to productivity and flexibility.
`
`Other issues critical to financial enterprise computing will also be addressed in the future by the Banking Systems
`Vendor Council, and similar definitions for these areas will be added to the Extensions for Financial Services (or as
`basic WOSA elements). These are expected to include:
`• Financial transaction messaging and management
`• Network and system management
`• Security
`• Emerging technologies such as object-oriented development, multimedia capabilities and pen computing
`
`
`See Section 4 for more detail.
`
`Page 12 of 228
`
`
`
`
`
` AMS
` Exhibit 2005
` RA v AMS
` IPR2017-00049
`
`

`

`WOSA Extensions for Financial Services, Revision 1.1
`
`April 14, 1994
`
`5
`
`2.1
`
`Architecture
`
`The architecture of the WOSA Extensions for Financial Services (WOSA/XFS) system is shown below.
`
`Windows-based
`
`applications
`
`
`
`WOSA/XFS APIs
`
`WOSA/XFS Manager
`Configumfion
`
`Information
`
`
`
`Service
`providers
`
`WOSA/XFS SPIs
`
`Figure 2.1 — WOSA Extensions for Financial Services Architecture
`
`The applications communicate with service providers, via the WOSA Extensions for Financial Services Manager,
`using the API set. Most of these APIs can be invoked either "synchronously" (the Manager causes the application to
`wait until the API's function is completed) or "asynchronously" (the application regains control immediately, while
`the function is performed in parallel).
`
`The common deliverable in all implementations of this WOSA Extensions for Financial Services specification is the
`WOSA Extensions for Financial Services Manager, which maps the specified API to the corresponding SPI, then
`routes this request to the appropriate service provider.
`'I‘he Manager uses the configuration information to route the
`API call (made to a "logical service" or a "logical device") to the proper service provider entry point (which is
`always local, even though the device or service that is the final target may be remote). Note that even though the
`API calls may be either synchronous or asynchronous, the SP1 calls are always asynchronous.
`
`The developers of financial services to be used via XFS and the manufacturers of financial peripherals will be
`responsible for the development and distribution of service providers for their services and devices. A setup routine
`for each device or service will also be necessary to define the appropriate configuration information. This
`infomiation will allow an application to request capability and status information about the devices and services
`available at any point in time.
`
`Page 13 of 228
`
`AMS
`
`Exhibit 2005
`
`RA V AMS
`
`IPR2017-00049
`
`

`

`WOSA Extensions for Financial Services, Revision 1.1
`
`
`April 14, 1994
`
`6
`
`The primary functions of the service providers are to:
`• Translate generic (e.g., forms-based) service requests to service-specific commands.
`• Route the requests to either a local service or device, or to one on a remote system, effectively defining a
`peer-to-peer interface among service providers.
`• Arbitrate access by multiple applications to a single service or device, providing exclusive access when
`requested.
`• Manage the hardware interfaces to services or devices.
`• Manage the asynchronous nature of the services and devices in an appropriate manner, always presenting
`this capability to the XFS Manager and the applications via Windows messages.
`
`
`The system design supports solution of complex problems, often not addressed by current systems, by providing for
`maximum flexibility in all its capabilities:
`• Multiple service providers, developed by multiple vendors, can coexist in a single system and in a network.
`• The service class definition is based on the logical functionalities of the service, with no assumption being
`made as to the physical configuration. A physical device that includes multiple distinct physical capabilities
`(referred to as a "compound device" in this specification) is treated as several logical services; the service
`provider resolves any conflicts. Note also that a logical service may include multiple physical devices (for
`example, a cash dispenser consisting of a note dispenser and coin dispenser).
`• Similarly, a physical device may be shared between two or more users (e.g., tellers), and the physical device
`synchronization is managed at the service provider level.
`• The API definition and associated services provide time-out functionality to allow applications to avoid
`deadlock of the type that can occur if two applications try to get exclusive access to multiple services at the
`same time.
`• The architecture is designed to provide a framework for future development of network and system
`monitoring, measurement, and management.
`
`
`Note that Figure 2.1 is a high level view of the architecture and, in particular, it makes no distinction between service
`providers and the services they manage. This specification focuses on service providers rather than on services,
`because the way a service provider communicates with a service is a vendor-specific internal design issue that
`applications and the XFS Manager are unaware of. In fact, there are many different ways that service providers can
`make services available to applications. Hence, this specification refers primarily to the service providers, since
`these are the modules with which the XFS Manager communicates. There are occasional references to 'service'
`where this is appropriate.
`
`
`
`
`Page 14 of 228
`
` AMS
` Exhibit 2005
` RA v AMS
` IPR2017-00049
`
`

`

`WOSA Extensions for Financial Services, Revision 1.1
`
`
`April 14, 1994
`
`7
`
`Example
`Figure 2.2 below shows a WOSA/XFS system supporting a set of financial peripherals. Note that in this framework
`the XFS Manager interfaces directly with a set of service providers that interface directly with the physical devices.
`Thus, the service providers are shown as implementing the service provider, service, and device driver functions,
`although these are more likely to be two or more separate layers. Many other configurations are possible.
`
`WorkStation 1
`
`WorkStation 2
`
`WorkStation 3
`
`Application
`
`Application
`
`Application
`
`WOSA/XFS API
`
`Configuration
`Information
`
`WOSA/XFS API
`
`Configuration
`Information
`
`WOSA/XFS API
`
`Configuration
`Information
`
`WOSA/XFS
`Manager
`
`WOSA/XFS
`Manager
`
`WOSA/XFS
`Manager
`
`WOSA/XFS SPI
`
`WOSA/XFS SPI
`
`WOSA/XFS SPI
`
`Passbook
`Printer
`Service
`Provider
`
`Vendor X
`
`Passbook
`Printer
`Service
`Provider
`
`Vendor Y
`
`Passbook
`Printer
`Service
`Provider
`
`Vendor Y
`
`Magnetic
`Card Reader
`Service Provider
`
`Vendor Y
`
`Passbook
`Printer
`Vendor X
`
`Passbook
`Printer
`Vendor Y
`
`Magnetic
`Card Reader
`Vendor Y
`
`Passbook
`Printer
`Service
`Provider
`
`Vendor X
`
`Passbook
`Printer
`Vendor X
`
`Figure 2.2 — A WOSA/XFS architecture example for a branch office banking system
`
`It should also be noted that one vendor's service providers are not necessarily compatible with another vendor's, as
`shown in Figure 2.2. If one application has to access the same service class as implemented by different vendors, a
`service provider is installed for each vendor.
`
`
`
`Page 15 of 228
`
`
`
`
`
` AMS
` Exhibit 2005
` RA v AMS
` IPR2017-00049
`
`

`

`WOSA Extensions for Financial Services, Revision 1.1
`
`
`2.2
`
`API and SPI Summary
`
`April 14, 1994
`
`8
`
`Sections 5 through 7 of this document present the interfaces that allow a financial application to communicate in a
`standard fashion with financial services and devices. The functions are at a sufficiently high level to allow for
`seamless redirection to other parts of the underlying operating system. A printer, for example, might rely on a set of
`services provided by the operating system, but in order to handle the unique characteristics of a financial printer and
`application, the service provider would preprocess the command, then redirect the derived commands to the
`operating system's printing services. In other implementations, the printer might be supported entirely by
`WOSA/XFS service mechanisms, and not use the operating system printing services in any way.
`
`The API is structured as sets of:
`• Basic functions, such as StartUp/CleanUp, Open/Close, Lock/Unlock, and Execute, that are common to
`all the WOSA Extensions for Financial Services device/service classes,
`• Administration functions, such as device initialization, reset, suspend or resume, used for managing
`devices and services, and
`• Specific commands, used to request device/service-specific functions, and sent to devices and services as a
`parameter of the Execute basic function.
`
`
`To the maximum extent possible, the syntax of specific commands that are used with multiple device/service classes
`is kept consistent across all devices. A primary objective is to standardize function codes and structures for the
`widest possible variety of devices.
`
`The SPI is kept as similar as possible to the API. Some commands are processed exclusively by the XFS Manager,
`and so are not in the SPI, and there are minor differences in the specific parameters passed at the two interface levels.
`
` A
`
` typical scenario showing the usage of the APIs is shown below. This example illustrates the functions used to
`print a form.
`•• StartUp (connects the application to the XFS Manager, including version negotiation)
`• Open (establishes a session between the application and the service provider)
`• Register (specifies the messages that the application should receive from the service provider)
`•• Lock (obtains exclusive access to the service by the application)
`• multiple Execute functions, passing one or more specific commands:
`àààà Print_Form
`àààà etc.
`• Unlock (releases exclusive access to the service by the application)
`• Deregister (specifies that the application should no longer receive messages from the service provider)
`•• Close (ends the session between the application and the service provider)
`•• CleanUp (disconnects the application from the XFS Manager)
`
`Note that within a session (defined by Open and Close), an application may at any time change the classes of
`messages it wishes to receive from the service provider (using Register), and ma