A filter module for a WOSA/XFS transaction processing system is disclosed. The system includes a WOSA transaction manager which is responsive to transaction requests from at least one application. A service provider layer is adapted to relay transaction requests passed from the transaction manager to associated hardware for execution. The filter module is adapted to intercept transaction requests from the transaction manager to the service provider layer and to process the requests. The filter module is further adapted to intercept transaction responses form the service provider layer to the transaction manager and the at least one application and to process these responses.
Legal claims defining the scope of protection, as filed with the USPTO.
1. A transaction processing system including: a transaction manager running in a first process and responsive to transaction requests from at least one application; a service provider layer including a set of service provider modules, each service provider module being adapted to relay transaction requests passed from said transaction manager to an associated hardware module and to relay transaction responses from said hardware module to said transaction manager or the at least one application; and at least one filter module adapted to intercept transaction requests from said transaction manager to said service provider layer and to process said requests, the at least one filter module being further adapted to intercept transaction responses from said service provider layer to said transaction manager and the at least one application and to process said responses; wherein the at least one filter module, said transaction manager and the at least one application has an associated identifier and wherein the at least one application is adapted to include the identifier of the application or the transaction manager to which transaction responses are to be relayed by the service provider layer in a transaction request, the at least one filter module being adapted to replace said identifier in at least some transaction requests with the identifier of the filter module so that responses to said requests from said service provider layer are relayed to said filter module.
2. A transaction processing system according to claim 1 in which the at least one filter module is adapted to process said requests and said responses by recording at least some of said requests and responses in a log.
3. A transaction processing system according to claim 1 including: a set of stub modules adapted to run in the same process as the transaction manager, each stub module being adapted to relay transaction request data passed from said transaction manager across a process boundary; a server adapted to run in a second process, said server being adapted to receive requests from said set of stub modules across the process boundary and to queue said requests for execution by said set of service provider modules; each service provider module corresponding to a stub module and being responsive to said queued requests to convert said queued requests to respective hardware specific calls for a device associated with each service provider module.
4. A transaction processing system as claimed in claim 3 wherein said transaction processing system is implemented on a Windows NT operating system, said operating system including a Windows registry, wherein said stub modules are implemented as stub dynamic link libraries which are adapted to be registered in the registry and wherein said transaction manager is adapted to call said stub DLLs by using information obtained by a lookup process performed on the Windows registry.
5. A transaction processing system as claimed in claim 4 in which the at least one filter module is adapted to intercept transaction requests to a stub module by replacing the stub module entry in the registry with an entry corresponding to the filter module, the at least one filter module being adapted to store the registration of the stub module so that once the filter has processed the request, the request is relayed to the stub module.
6. A transaction processing system as claimed in claim 4 wherein said transaction manager is a Windows Open System Architecture (WOSA) manager, said transaction requests are WOSA calls and said manager is adapted to relay said WOSA calls to said server via said stub modules, said server being adapted to convert said WOSA calls into constituent components, each component corresponding to a low level generic hardware function call.
7. A transaction processing system including: a transaction manager running in a first process and responsive to transaction requests from at least one application; a service provider layer including a set of service provider modules, each service provider module being adapted to relay transaction requests passed from said transaction manager to an associated hardware module and to relay transaction responses from said hardware module to said transaction manager or the at least one application; at least one filter module adapted to intercept transaction requests from said transaction manager to said service provider layer and to process said requests, the at least one filter module being further adapted to intercept transaction responses from said service provider layer to said transaction manager and the at least one application and to process said responses; wherein one of said applications is a web browser adapted to run a web application, the web application including at least one web page.
8. A transaction processing system including: a transaction manager running in a first process and responsive to transaction requests from at least one application; a service provider layer including a set of service provider modules, each service provider module being adapted to relay transaction requests passed from said transaction manager to an associated hardware module and to relay transaction responses from said hardware module to said transaction manager or the at least one application; at least one filter module adapted to intercept transaction requests from said transaction manager to said service provider layer and to process said requests, the at least one filter module being further adapted to intercept transaction responses from said service provider layer to said transaction manager and the at least one application and to process said responses; wherein said transaction processing system cooperates with a registry, wherein said service provider modules are adapted to be registered in the registry and wherein said transaction manager is adapted to call said service provider modules by using information obtained by a lookup process performed on the registry.
9. A transaction processing system as claimed in claim 8 in which the at least one filter module is adapted to intercept transaction requests to a service provider module by replacing the service provider module entry in the registry with an entry corresponding to the filter module, the at least one filter module being adapted to store the registration of the service provider module so that once the filter has processed the request, the request is relayed to the service provider module.
10. An Automatic Teller Machine including a. a processor connected to b. a memory, c. a screen display, d. a user input means, e. a card reader, and f. a storage medium, said storage medium being adapted to store operating system software and a transaction processing system including: a transaction manager running in a first process and responsive to transaction requests from at least one application; a service provider layer including a set of service provider modules, each service provider module being adapted to relay transaction requests passed from said transaction manager to an associated hardware module and to relay transaction responses from said hardware module to said transaction manager or the at least one application; and at least one filter module adapted to intercept transaction requests from said transaction manager to said service provider layer and to process said requests, the at least one filter module being further adapted to intercept transaction responses from said service provider layer to said transaction manager and the at least one application and to process said responses.
11. An ATM as claimed in claim 10 wherein one of said applications is operable to request user input from said user input means and to request data to be read from a card inserted in said card reader and one of the at least one filter modules is adapted to process said requests.
Cooperative Patent Classification codes for this invention. Click any code to explore related patents in that topic.
December 10, 1998
February 17, 2009
Browse 5M+ US patents with plain-English claim translations and AI-generated analysis.