Patent ID: 12217087

DETAILED DESCRIPTION

Similar features are shown in the various embodiments of the present disclosure. Similar features have been numbered with a common reference numeral and have been differentiated by an alphabetic suffix. Similar features are structured similarly, operate similarly, and/or have the same function unless otherwise indicated by the drawings or this specification.

A payment processing solution or system, whether acquiring or issuing, must deal with multiple incoming and outgoing connections. Each incoming channel will have differing properties. For example, ATMs are single point connections, while POS transactions may be processed by network concentrators. Also, incoming issuer traffic may share the same access point as the outgoing external authorization message, and Mobile, Digital and eCommerce channels may use various security mechanisms for authentication. These differences and others must be considered when defining the deployment architecture of a payments processing solution.

The aspects mentioned so far concern the system at runtime. Another important aspect are changes to the flow of the process. Here, business requirements must be introduced quickly and in isolation. To do this, it must be possible to develop, test and deploy changed entities in isolation i.e. without impact to other entities in the system.

The present disclosure, as demonstrated by the exemplary embodiment described below, can provide a system that is configured to process financial transactions and can dynamically change its size in response to demand.FIG.1is a schematic functional block diagram of an exemplary system10of components so configured and involved in processing financial transactions and incorporating an exemplary embodiment of the present disclosure. The exemplary system10includes a plurality of devices that are configured to initiate financial transactions such as, by way of example and not limitation, a personal computing device12, a point of sale (POS) device14, and an automated transaction machine (ATM)16. Single examples of devices configured to initiate financial transactions are shown, but the system10can include a plurality of each form of device.

The exemplary personal computing device12is shown as a smartphone, but can take other forms such as, by way of example and not limitation, a tablet, a desktop computer, a laptop computer or a smart television. The exemplary POS device14is shown as a device in which a payment card can be inserted (cards that include a chip) and in which a payment card can be slid across (cards that include a magnetic strip), but can take other forms. The exemplary ATM16is shown as a device in which a check or debit card can be inserted, but can take other forms such as, by way of example and not limitation, a device in which a check or debit card can be slid across, devices that do not require a card, and devices capable of performing transactions more complex than cash withdrawals (referred to as “in-lobby tellers”).

The exemplary system10also includes a first server18. The exemplary first server18has one or more processors and a non-transitory, computer readable media to store data. The first server18can be operated by a financial institution and be configured to operate as a bank core. A bank core is a centralized back-end system designed to process and support transactions across branches of banks and across the devices that are configured to initiate financial transactions such as the personal computing device12, the POS device14, and the ATM16. At the front end, a bank core offers all of the services that customers and banking professionals need to process and execute financial transactions. On the back end, the bank core processes data securely and reduces the risk of fraud. The bank core thus provides essential services to keep data safe and also provides an optimal user experience for customers. Generally, the bank core is a component that participates in the execution of transactions such as assessing deposits and withdrawals for approval, opening new accounts, calculating interest, servicing loans, processing checks, inhibiting fraud and risk, and keeping a ledger of records.

The first server18can communicate with the personal computing device12, the POS device14, and the ATM16, respectively, over a network20. It is noted that only one network20is shown, but the first server18can communicate with other devices over a plurality of different and/or overlapping networks. The first server18can receive requests to assess, for approval or rejection, financial transactions from the personal computing device12, the POS device14, and the ATM16, respectively, over the network20. The present disclosure is well suited to a wide variety of computer network systems over numerous topologies. Within this field, the configuration and management of large networks comprise storage devices and computers that are communicatively coupled to dissimilar computers and storage devices over a network, such as the Internet. The network20can include a local area network (LAN), a wide area network (WAN), e.g., the Internet, a virtual private network (VPN), or a combination thereof.

Transmissions over the network20may be encrypted and may include Message Authentication Codes (MACs) to enhance security. MACs can be appended to messages sent from and received by the personal computing device12, the POS device14, and the ATM16. MACs verify that the messages sent and the messages received are identical and also confirm that messages originate from an approved source. The server18and the personal computing device12, the POS device14, and the ATM16can also apply Transport Layer Security (TLS) or Secure Sockets Layer (SSL) protocols and include respective firewalls to enhance security.

It is noted that in other embodiments of the present disclosure, a first server may not receive requests for financial transactions from all forms of devices12,14, and16. For example, the first server may not be bank core and therefore may not manage bank accounts. In such an example, the first server may be configured to process payments for goods and/or services and may only receive requests for financial transactions from the personal computing device12and the POS device14. Also, in other embodiments of the present disclosure, a first server may be a switch of a financial network and communicate with a bank core.

The exemplary system10also includes a second server22. The exemplary second server22has one or more processors and a non-transitory, computer readable medium to store data. The exemplary second server22is physically remote from the first server18and can communicate with the first server18over the network20. It is noted that in other embodiments of the present disclosure, the second server22can communicate with the first server18over a network different than the network20which can include a LAN, a WAN, a VPN, or a combination thereof.

The second server22can be configured to operate as a remote platform that uses a virtual, multi-tenant infrastructure to provide the first server18with scalable processing sources provisioned dynamically as demanded by the first server18. The provisioning of the resources of the exemplary second server22by the exemplary first server18can be accomplished through a web-based interface. When the exemplary first server18no longer requires the resources of the exemplary second server22, the resources are surrendered and accessible to other servers. The purpose of the second server22within the system10will be described in greater detail below.

The exemplary system10also includes a third server24. The exemplary third server24has one or more processors and a non-transitory, computer readable medium to store data. The exemplary third server24is physically remote from the first server18and can communicate with the first server18over the network20. It is noted that in other embodiments of the present disclosure, the third server24can communicate with the first server18over a network different than the network20which can include a LAN, a WAN, a VPN, or a combination thereof. The purpose of the third server24within the system10will be described in greater detail below.

The first server18can maintain, with one of hardware, software or a combination of hardware and software, a plurality of transaction middleware (TM) sub-modules that are utilized to process financial transactions. TM sub-modules can operate in a group that defines a TM module or bounded context. Similarly, TM modules can operate in a group that defines a TM super-module. TM sub-modules, TM modules, and TM super-modules can be maintained on and executed by the exemplary first server18. The system10applies the various TM sub-modules, modules, and super-modules according to principles of Domain-driven design. Each TM super-module defines a domain.

FIG.2is a schematic functional block diagram of a TM sub-module26of the exemplary embodiment of the present disclosure. Each TM sub-module is configured to execute a discrete secondary sub-task of a financial transaction request. The exemplary TM sub-module26includes a fully functional and stand-alone JAVA application. A Java application is a computer program or application written in the object-oriented programming language called JAVA. The exemplary TM sub-module26also includes build instructions, a default configuration, a Data Definition Language (DDL)/Data Manipulation Language (DML) implementation, a JAVA document, an OCM plugin, and dependency management information.

The exemplary first server18can maintain and execute a plurality of different TM sub-modules, including, by way of example and not limitation, TM modules that perform the following functions: a “BIN” TM Module can classify card products and can manage individual card product authentication as well as financial and security policies; a “Crypt” TM Module can provide key store management and key service, remote key loading, zone key management, and issuer key services; and a “Transaction Log” TM Module can provide secure transaction logging and various post transaction services. In an exemplary system10, there can be about five hundred TM sub-modules.

The first server18can also maintain, with one of hardware, software or a combination of hardware and software, a plurality of TM modules (or bounded contexts) that are utilized to process financial transactions. Each TM module is configured to execute a discrete primary sub-task of a financial transaction, wherein a primary sub-task is completed by the execution of at least two secondary sub-tasks.FIG.3is a schematic functional block diagram of a TM module28of the exemplary embodiment of the present disclosure. The exemplary TM module28includes at least two of the plurality of TM sub-modules.

The exemplary first server18can include a TM module designated “device handler” that manages the channel specific connection capabilities and message formats. Incoming requests can be translated into standardized message formats to be consumed by any following TM modules in the processing chain followed for the execution of a financial transaction. The exemplary first server18can include a TM module designated “Authorization Router” for routing decisions. The exemplary first server18can also include a BIN TM module, a Transaction Log TM Module, and a Crypt TM module. The exemplary first server18can include a TM module designated “Token Vault” that manages tokens. The exemplary first server18can include a TM module designated “Crypt” for key store management and key service, remote key loading, zone key management and issuer key services. The exemplary first server18can include a TM module designated “Account” for financial authorization of on-us transactions in real-time. The exemplary first server18can include a TM module designated “Channel [payment schema]” to manage one or multiple connections and to support incoming (issuing) and outgoing (acquiring) traffic.

The first server18can also maintain, with one of hardware, software or a combination of hardware and software, at least one TM super-module30comprising a plurality of TM modules. Each TM super-module is configured to execute at least part of a financial transaction by the execution of at least two primary sub-tasks.FIG.4is a schematic functional block diagram of the TM super-module30of the exemplary embodiment of the present disclosure. The exemplary TM super-module30includes at least two of the plurality of TM modules. A TM super-module in the exemplary embodiment defines a functional domain.

FIG.5is a schematic functional block diagram of a plurality of TM super-modules30,30a,30bof the exemplary embodiment of the present disclosure. The exemplary TM super-module30has been designated sdp-pymt-switch and includes TM modules Card, Channel, Transaction Log, Bin, Token Vault, Account, and Authorization Router. The TM module Channel is configured to communicate with external networks/schemes that can authorize financial transaction requests. The TM module Account is configured to communicate with internal services. The exemplary TM super-module30ahas been designated sdp-pymt-devhandler and includes TM modules Transaction Log, Client connector, DeviceHandling, and sbSwitching. The TM module Client connector is configured to communicate with external devices such as the personal computing device12, the POS device14, and the ATM16, which transmit financial transaction requests. The exemplary TM super-module30bhas been designated sdp-pymt-crypt and includes TM module Crypt.

FIG.6is a schematic flow diagram of exemplary actions performed by the plurality of TM super-modules of the exemplary embodiment of the present disclosure.FIGS.7-12are enlarged portions ofFIG.6and are respectively referenced inFIG.6.FIGS.6-12detail the process flow when the financial transaction request is an ATM cash withdrawal.

FIG.7shows the initial steps of the process wherein the ATM16transmits a financial transaction request (a request for permission for the ATM16to dispense currency) to the TM super-module30a. This transmission is referenced at32. The financial transaction request32is received by the TM module Client connector and, after initial processing, is transmitted to the TM module DeviceHandling for further processing. The financial transaction request32, as processed by the TM modules Client connector and DeviceHandling, is then transmitted to the TM module sbSwitching. The financial transaction request32is further processed and then transmitted to the TM super-module30, specifically the TM module Authorization Router. This transmission is referenced at34.

FIG.8shows subsequent steps of the process wherein the TM module Authorization Router of the TM super-module30receives the transmission34. The TM module Authorization Router processes the financial transaction request and transmits the financial transaction request for further processing to the TM module BIN of the TM super-module30. The TM module BIN executes processing and returns the financial transaction request to the TM module Authorization Router for further processing.

FIG.9shows further subsequent steps of the process performed by the TM super-module30. The TM module Authorization Router processes the financial transaction request and transmits the financial transaction request for further processing to the TM module Card of the TM super-module30. The TM module Card executes processing and returns the financial transaction request to the TM module Authorization Router for further processing. The TM module Authorization Router processes the financial transaction request and transmits the financial transaction request for further processing to the TM module Crypt of the TM super-module30b. This transmission is referenced at36. The TM module Crypt executes processing and returns the financial transaction request to the TM module Authorization Router for further processing.

FIG.10shows further subsequent steps of the process performed by the TM super-module30. The TM module Authorization Router transmits the financial transaction request for further processing to the TM module Account of the TM super-module30. The TM module Account processes the financial transaction request and transmits the financial transaction request for further processing back to the TM module Authorization Router. The TM module Authorization Router then transmits the financial transaction request for further processing to the TM module Card of the TM super-module30. The TM module Card processes the financial transaction request and transmits the financial transaction request for further processing back to the TM module Authorization Router.

FIG.11shows further subsequent steps of the process performed by the TM super-modules30and30b. The TM module Authorization Router transmits the financial transaction request for further processing to the TM module Channel of the TM super-module30. The TM module Channel processes the financial transaction request and transmits the financial transaction request for further processing to the TM module Crypt of the TM super-module30b. This transmission is referenced at38. The TM module Crypt executes processing and returns the financial transaction request to the TM module Channel for further processing.

FIG.12shows further subsequent steps of the process performed by the TM super-modules30and30a. The TM module Authorization Router transmits the financial transaction request for further processing to the TM module Transaction Log. The TM module performs processing on the financial transaction request and transmits the financial transaction request back to the TM module Authorization Router. The TM module Authorization Router performs processing on the financial transaction request and transmits the financial transaction request to the TM module sbSwitching of the TM super-module30a. The TM module sbSwitching performs processing on the financial transaction request and transmits the financial transaction request to the TM module DeviceHandlingSB. The TM module DeviceHandlingSB transmits approval to dispense currency to the ATM16at40.

FIG.13is a schematic functional block diagram of TM sub-modules and TM modules transferred between the first server18and the second server22. As set forth above, the exemplary first server18can be operated by a financial institution and be configured to operate as a bank core. InFIG.13, the circles represent individual TM sub-modules, such as referenced at26. Upon startup of the system10and throughout operation of the system10, the operator of the first server18can extract TM sub-modules as desired to build TM modules and TM super-modules and to enhance or modify TM modules and TM super-modules. InFIG.13, an exemplary TM module assembled by the first server18is referenced at28aand an exemplary TM super-module assembled by the first server18is referenced at30c. The second server22can thus be a depository of TM modules and TM super-modules.FIG.13shows that the second server22can retain TM modules and TM super-modules that facilitate connections among hardware components and software modules, processing operations, and base components.

FIG.13also shows a TM module28bthat is created by the operator of the first server18and not extracted from the second server22. The system10thus accommodates customization.

The first server18can define a particular operational capacity. By way of example and not limitation, the first server18may be able to process a particular number of financial transaction requests concurrently. During operation, first server18can receive a frequency of financial transaction requests that exceeds its operational capacity. In response to receiving a number of financial transaction requests that exceeds the operational capacity, the first server18can replicate TM-supermodules on the third server24and direct at least portions of financial transaction requests beyond the operation capacity to the third server24. The exemplary first server18can thus annex at least some memory space of the third server24. The portion of the third server24annexed by the first server18thus allows the system to dynamically change its size in response to demand.

FIG.14is a schematic functional block diagram of TM super-modules transferred between the first server18and the third server24. A TM super-module30dstored and operated on the first server18is replicated and then operated on the third server24. Upon the completion of processing of received financial transaction requests, the exemplary third server24can erase the memory sections storing the transferred TM super-modules. The exemplary first server18thus temporarily annexes at least some memory space of the third server24.

A cloud infrastructure monitoring system can monitor the activities of the system10and decide when to replicate or reduce TM super modules. Kubernetes is one example of a cloud infrastructure monitoring system that can be utilized in one or more embodiments of the present disclosure.

It is noted that the system10annexes at least some memory space of the third server24, in response to demand beyond capacity, per domain and not per request. Existing systems can access remote resources, such a memory space of the third server24, in response to demand that exceeds its existing resources. Existing systems access such remote resources “per request” which means that existing systems transfer the request to the remote resource and the remote resource can service the request. The remote resource maintains the coding necessary to service any requests that are received. In contrast, in the present disclosure, the first server18accesses the third server24and annexes memory space per domain which means that the first server18replicates the coding needed for all TM sub-modules and TM modules for a particular TM super-module, in order to service the request on the memory of the third server24and also transfers the financial transaction request (as thus-far processed) to the third server24. The third server24services the financial transaction request and then the memory of the third server24is then released for use by another system.

In an exemplary method executed by the system10, the first server18can maintain, with one of hardware, software and a combination of hardware and software, a plurality of TM sub-modules such as TM sub-module26. Each TM sub-module can be configured to execute a discrete secondary sub-task of a financial transaction request. Each TM sub-module can include a fully functional and stand-alone JAVA application, build instructions, a default configuration, a DDL/DML implementation, a JAVA document, a OCM plugin, and dependency management information. The first server18can also maintain a plurality of TM modules, such as TM module28. Each TM module can include at least two of the plurality of TM sub-modules. Each TM module can be configured to execute a discrete primary sub-task of the financial transaction request. A discrete primary sub-task is completed by the execution of at least two secondary sub-tasks. The first server18can also maintain a plurality of TM super-modules, such as TM super-module30. Each TM super-module can include two or more of the plurality of TM modules and each can be configured to execute at least part of the financial transaction request by the execution of at least two primary sub-tasks.

The first server18can receive a request to execute the financial transaction request. The first server18can then determine all of the TM super-modules that are required to execute the financial transaction. The first server18can also detect respective capacities of all of the TM super-modules that are required to execute the financial transaction.

In response to detecting that any of the TM super-modules are at maximum capacity, the first server18can annex control over at least some memory space of the second server24. The first server18can then replicate any of the TM super-modules that are at maximum capacity on memory space of the second server. Further, the first server18can direct the financial transaction request (to the extent the financial transaction request is already partially processed or is fully unprocessed) to the TM super-module that was replicated on the memory annexed from the second server, for completion of at least some processing of the financial transaction request. The TM super-module replicated on the second server can complete processing of the financial transaction request. This processing may or may not complete all processing required to complete the financial transaction request. The first server18can receive the output and then cede control over the memory back to the second server. In response, the second server24can designate the memory space that previously held the TM super-module as free, usable by another server.

While the present disclosure has been described with reference to an exemplary embodiment, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted for elements thereof without departing from the scope of the present disclosure. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the present disclosure without departing from the essential scope thereof. Therefore, it is intended that the present disclosure not be limited to the particular embodiment disclosed as the best mode contemplated for carrying out this present disclosure, but that the present disclosure will include all embodiments falling within the scope of the appended claims. The right to claim elements and/or sub-combinations that are disclosed herein is hereby unconditionally reserved. The use of the word “can” in this document is not an assertion that the subject preceding the word is unimportant or unnecessary or “not critical” relative to anything else in this document. The word “can” is used herein in a positive and affirming sense and no other motive should be presumed. More than one “invention” may be disclosed in the present disclosure; an “invention” is defined by the content of a patent claim and not by the content of a detailed description of an embodiment of an invention.