Patent Application
20230385826
One technical field of the present disclosure is computers programmed to execute high-speed, high-volume transaction protocols and messaging. Another technical field is computer-implemented real-time memory cache management. Yet another technical field is parallel processing or concurrent processing.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
Online computer-implemented payment card transaction systems are architected to process thousands to millions of transactions, each involving a request, decision logic, transformation of data, and response, within brief real-time periods while cardholders or other parties are waiting on transactions, and with mandatory fixed maximum times for processing. These systems are termed real-time transaction systems because they are required to generate digital data requests, execute decision logic, transform data, and respond with other digital data within milliseconds to seconds while real-world activities are occurring, such as consumer purchases at a point of sale. Attributes of these systems include processing times and a scale of throughput and transaction volume that far exceed human capacity and require computer implementation.
The implementation of these services requires the use of distributed systems of computers in which end-user computing devices, point-of-sale systems, application servers or other systems of customers, servers of service providers, and servers of payment networks are independent and usually geographically distant from one another. Therefore, high-speed request-response message communication is required among the functional elements of the system. In many cases, a particular transaction can start, undergo processing, receive authorization or approval, and complete only when all such systems are online and responsive.
Thus, the requirement of these systems for real-time response and extremely high transaction throughput makes the systems sensitive to network outages, server outages, or other failures of units of the distributed systems. Unless protective measures are implemented, one computer or process will experience repeated timeouts as requests are sent and responses are not received. Systems operating in this manner consume unnecessary CPU cycles, network bandwidth, memory, and storage usage to create requests, enter wait states, branch to failure code, and log errors. There is a need to reduce these and other technical consequences of failure or unreliability in high-speed, distributed transaction processing systems.
In the drawings:
In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.
The text of this disclosure, in combination with the drawing figures, is intended to state in prose the algorithms that are necessary to program a computer to implement the claimed inventions, at the same level of detail that is used by people of skill in the arts to which this disclosure pertains to communicate with one another concerning functions to be programmed, inputs, transformations, outputs and other aspects of programming. That is, the level of detail set forth in this disclosure is the same level of detail that persons of skill in the art normally use to communicate with one another to express algorithms to be programmed or the structure and function of programs to implement the inventions claimed herein.
Embodiments are described in the sections below according to the following outline:
In one embodiment, card issuer-processors implement certain payment card processing functions using high-speed, cloud-based server computers and computing instances. The payment card may be a card, plastic credit card, charge card, virtual card, tokenized card, or another form of payment card, including chip-based cards, and magstripe contactless cards. These systems support transaction services for end users (e.g., card holders) who buy products or services from business entities.
Requests, data, and responses concerning the movement of money or value among accounts occur using a payment network. Some services also act as an issuer of virtual payment cards to end users on behalf of card program operators, which is an entity that customizes the payment card functionalities. Issuing banks also issue cards and link cards to cardholder accounts. All the aforementioned parties use distributed systems of computers that are linked by open internetworks and private, secure payment networks. While some aspects of this disclosure focus on implementation examples using card transaction protocols, embodiments may be implemented in the context of transaction or messaging protocols that do not involve card payments but involve the same kinds of time limits and/or scale as described herein.
When a cardholder attempts to use a payment card for purchases or other bank-related services, a payment network provides a transaction validation request to a payment processor, otherwise referred to as a transaction processing server. The payment network typically requires the transaction processing server to complete its validation processes and provide a response to the validation request within a specified time, such as seven (7) seconds. Considering the hundreds or thousands of transactions that the transaction processing server may need to process every second, improving and maintaining high efficiency of the validation processes are important to be able to respond to the validation request within time.
Embodiments of this disclosure provide benefits and improvements to the validation process for validating a payment transaction by organizing various components of a card processing protocol into groups, where the components within each group are processed in parallel with respect to each other, and the groups themselves are processed sequentially. These embodiments leverage the idle periods that a transaction processing server experiences when executing certain components of the card processing protocol by executing one or more other components that can be independently executed during such idle periods.
In one aspect, a computer-implemented method for parallel processing of a plurality of components of an e-commerce transaction protocol, executed by one or more computer devices of a transaction processing server, comprises: receiving, from a payment network computer, a validation request message to validate a transaction associated with a digital electronic payment account; identifying a plurality of components of the e-commerce transaction protocol that are associated with the transaction; determining a mapping of dependencies between each of the plurality of components to create and store a digital memory representation of a topological ordering for processing the plurality of components; creating and storing in the digital memory, based on the topological ordering, a plurality of groups for the plurality of components, each group comprising one or more components of the plurality of components that can be processed independently from each other; sequentially processing the plurality of groups by processing the one or more components that are associated with each group of the plurality of groups before processing the one or more components that are associated with a next group of the plurality of groups, the one or more components associated with each group of the plurality of groups being processed in parallel; determining, based on the processing of the plurality of components, whether to validate the transaction; transmitting, to the payment network computer, a response to the validation request indicating whether the transaction is validated.
In one feature, the method further comprises performing sequentially processing the plurality of groups only during an idle period of the e-commerce transaction protocol during which the transaction processing server is waiting for a required response from another computer. In that feature, a sum of the idle period and a time to execute the sequential processing, the determining, and the transmitting is limited in time in the e-commerce transaction protocol to a maximum of seven (7) seconds.
In a further feature, the method further comprises executing a first sequence of operations of the e-commerce transaction protocol, including transmitting a second request to another computer; entering an idle period of the e-commerce transaction protocol during which the transaction processing server is waiting for a required response from another computer; performing the sequentially processing the plurality of groups only during the idle period. In this feature, a sum of the idle period and a time to execute the sequential processing, the determining, and the transmitting may be limited in time in the e-commerce transaction protocol to a maximum of seven (7) seconds.
In an embodiment, a distributed computer system 100 comprises components that are implemented at least partially by hardware at one or more computing devices, such as one or more hardware processors executing stored program instructions stored in one or more memories for performing the functions that are described herein. In other words, all functions described herein are intended to indicate operations that are performed using programming in a special-purpose computer or general-purpose computer, in various embodiments.
In an embodiment, computer system 100 comprises a data network 101 that is communicatively coupled to a supplier computer 102, payment network 104, card program servers 136, end user computer 106, transaction processing server 108, and funding source computer 124. For purposes of illustrating a clear example,
Each of the supplier computer 102, payment network 104, transaction processing server 108, and funding source computer 124 may be implemented using one or more server-class computers, clusters, virtual machines, or other computing devices. For example, transaction processing server 108 may be implemented using a fault-tolerant, scalable set of virtual computing instances in a private datacenter, public datacenter, or cloud computing facility with a number of central processing units sufficient to service thousands to millions of concurrent transaction requests from the payment network 104 and originating from thousands to millions of end-user computers 106, supplier computers 102, or points of sale.
Supplier computer 102 may be owned or operated by, or associated with, a supplier of goods or services, such as a merchant, to an end user who is associated with end-user computer 106 or other entities or institutions. In other cases, supplier computer 102 may represent a point-of-sale terminal at which an individual end user appears in person to conduct a transaction. A supplier may be a retailer, reseller, value-added reseller, distributor, or other entity in a supply chain or manufacturing chain. A supplier may deal in tangible goods and/or intangible goods, using physical retail, resale, or distribution facilities and/or virtual, online stores, shopping carts, catalogs, or other facilities. The supplier or merchant may have a customer relationship with an entity, such as a card issuer-processor, that owns, operates, or is associated with the transaction processing server 108. However, a customer relationship is not required.
In one embodiment, an end user computer 106 is used and represents a mobile computing device, smartphone, laptop computer, desktop computer, or workstation that is associated with an individual end user. In some embodiments, end user computer 106 is programmed with an operating system having an internet software stack that can communicate with data network 101 using protocols such as HTTP over TCP/IP and has an internet browser that can communicate with supplier computer 102 to transfer requests and responses using HTTP, application protocols implemented using apps on the end user computer, or other techniques. The end user computer 106 may be one source of introducing a card number for a transaction into the processes described herein, but other embodiments may receive card numbers or other transaction details through programmatic calls or other systems or computers (e.g., an automated teller machine (ATM)).
Data network 101 broadly represents one or more local area networks, wide area networks, internetworks, or a combination thereof, which are communicatively coupled via any wired or wireless, terrestrial or satellite network links.
Payment network 104 is a secure, private network for communication of payment protocol messages between the computers of authorized parties such as banks, payment clearinghouses, merchants, card issuers, and card processors. Because payment network 104 comprises a plurality of computers, software, and specialized networking gear, the terms “payment network” and “payment network computer” may be used interchangeably for convenience to refer to all functional elements in a payment network.
Funding source computer 124 represents a mobile computing device, smartphone, laptop computer, desktop computer, or workstation that is associated with a funding source such as a bank, savings and loan, credit union, private lender, or other source for funding transactions. In one embodiment, funding source computer 124 and transaction processing server 108 are integrated or associated with the same issuer-processor entity. Funding source computer 124 broadly represents all computer-implemented functional elements of such an institution, including databases or data repositories that hold account data, instrument data and value data for accounts, monetary instruments in accounts, and funds or value in accounts.
Card program server 136 represents an entity such as a card program operator that operates or manages payment card programs. The card program server 136 may be associated with an entity that has a customer relationship with another entity, such as a transaction processing server, or a card issuer-processor, that owns, operates, or is associated with the computers and/or servers used to process payment transactions. However, a customer relationship is not required. The card program server 136, via the transaction processing server or the card issuing bank, is able to customize the rules and conditions in which a card could be used and manage the issuance of the card over the card's lifecycle, such as by ordering, activating, setting expiration, suspending, and terminating cards.
Transaction processing server 108 may be one or more server computers and/or virtual machine instances that are programmed to implement the functions that are further described herein. In one embodiment, transaction processing server 108 is owned or operated by a card issuer-processor, but other entities also may implement functionally equivalent computers or programs. The transaction processing server 108 may be architected with load balancing routers, multiple processors, clusters, or virtual machine instances, work queues, multithreaded programming, and parallel processing to operate with real-time response to requests from payment network 104 as end user computers 106, supplier computers 102, or card program servers 136 are conducting transactions at the scale of thousands to millions of requests per second. A transaction processing server 108 may also be referred to as an access control server.
In one embodiment, transaction processing server 108 comprises a digital storage device or database 114 that is programmed with a database schema or other form of organized, high-speed, digital storage and manages a card program account 110, card account 112, concurrency decision instructions 116, and card state data 118. Database 114 may represent any digital data storage device or repository including combinations of database clusters, relational databases, object storage, or other repositories.
Card program account 110 represents a digitally stored association of data that describes a card program operator, such as one associated with a card program server 136. Card program account 110 enable the system to differentially process stored program rules for different suppliers to implement different policy concerning the approval of transactions, use of cached balances, and/or denial of transactions.
Virtual card account 112 represents a virtual payment card that has been issued to a party such as an end user who is associated with end user computer 106. Each card account 112 is associated with a digitally stored cached balance value 116, which represents an amount of value that is available for payment of purchases for which the card is presented.
Concurrency decision instructions 116 represent operations programmed to be executed by the transaction processing server 108 to determine the dependencies between components of a card processing protocol and, based on the determined dependencies, groupings of the components to allow parallel processing of the components within each group.
Card state data 118 represents a digitally stored set of attributes or values for a state of a card, its balance, and other attributes of a card account. Card state data 118 enables the system to maintain a record of card state when card program server 136 is offline and cannot be messaged or programmatically queried to obtain a funding decision, authorization decision, or approval decision. By digitally storing the card state data 118 at database 114, the transaction processing server 108 may be programmed to transmit the card state data to the card program server 136 when it returns online, enabling synchronization of card account details between the transaction processing server and the card program server 136. In an embodiment, the stored card state data 118 is associated with the particular card program 110 of a card program server 136 that was offline, using a card program operator identifier value, another identifier, or a pointer.
For purposes of clarity,
Computer system 100 is a high-speed, high-throughput, scalable system planned for real-time processing of card payment transactions as they occur. In this context, “real-time” response refers to receiving a request from payment network 104 to approve or decline a transaction, executing decision logic at transaction processing server, transmitting messages to one or more of supplier computer 102, card program server 136, funding source computer 124, and payment network 104 to obtain decisions or data, and transmitting a response to the payment network within an amount of time that end users or suppliers will tolerate as reasonable to conduct a transaction. In some embodiments, the total time for executing the foregoing steps is three (3) seconds to seven (7) seconds.
In an embodiment, the algorithm shown in
At block 202, in an embodiment, a card device 107 is programmed to transmit a transaction request message to the payment network 104 requesting to initiate a transaction with a payment card.
At block 204, upon receiving the transaction request message from the card device 107, the payment network 104 is programmed to transmit a validation request message to the transaction processing server 108 requesting validation of the transaction.
At block 206, upon receiving the validation request message, the transaction processing server 108 is programmed to execute components of a card processing protocol, or otherwise referred herein as an e-commerce transaction protocol, to validate the transaction. An example of a card processing protocol is the jPOS java library, which has been implemented in open-source software that is commercially available at the time of this writing from Alejandro Revilla via the online site jpos.org. While some embodiments herein are described in the context of jPOS, other embodiments may be implemented using other protocols and in contexts not related to payments.
Each component of the jPOS java library with respect to the validation processes described herein represents a unit of work of the jPOS java library referred to as a Participant. That is, each component of the jPOS java library, or each Participant, represents a set of operations that the transaction processing server 108 performs to validate the transaction.
Examples of such components include: retrieving initial configurations to be used by downstream processes; accessing a digital wallet associated with a digital electronic payment account based on a device primary account number (DPAN) associated with the validation request message; validating a cardholder associated with the digital electronic payment account; validating a card verification value of a payment card associated with the transaction; validating a service code from track data associated with the payment card; validating a pin block received in an ISO request; validating of verifying location data associated with the transaction; validating the transaction based on merchant data; validating a chip cryptogram associated with the payment card; applying transaction controls based on a balance associated with the digital electronic payment account; and applying transaction controls based on a type of the transaction.
In an embodiment, the transaction processing server 108 executes each of the components of the card processing protocol by transmitting a request message, or by making an API call, to the funding source computer 124 to obtain information necessary to validate the transaction. In some embodiments, the transaction processing server 108 may transmit, or make an API call, to other entities such as a supplier computer 102, card program server 136, payment network 104, or the end user computer 106 to validate the transaction, using the same or similar techniques described herein in reference to the funding source computer 124. In an embodiment, the transaction processing server 108 comprises a hardware security module (HSM) that executes validation processes for validating PIN , CHIP data, or dynamic CVV.
At block 208, upon receiving a request message or an API call from the transaction processing server 108, the funding source computer 124 is programmed to provide the requested information to the transaction processing server 108.
In an embodiment, based on the type of transaction, different components of the protocol may need to be executed to validate the transaction. Examples of the different types of transactions include online purchases using the various types of payment cards (e.g., a credit card, debit card, or pre-loaded card such as a gift card), in-person retail purchases using the various types of payment cards, and ATM-related transactions. Upon receiving a request to validate a transaction from the payment network 104, the transaction processing server is programmed to identify the various components of the card processing protocol necessary to validate the transaction for that type of transaction.
In some embodiments, the components of the card processing protocol are organized in a particular order so that certain components are executed before others. In some embodiments, the components of the card processing protocol are organized in groups, such that components within one group can be executed in parallel with respect to other components within the group. Additional details of these embodiments and how the various components of the card processing protocol are executed in sequence or in parallel are discussed in more detail below, with references to
As an illustration of the validation process illustrated in blocks 206 and 208, the transaction processing server 108 may, upon receiving a validation request message from the payment network 104, programmatically determine that initial configurations associated with the payment card used for the transaction need to be prepared and/or retrieved from the funding source computer 124. This retrieving/preparing operation is an example of a component of the jPOS java library that the transaction processing server may execute. After retrieving/preparing the initial configurations, the transaction processing server 108 may programmatically determine whether the payment card used for the transaction is a valid payment card that was issued by the funding source computer 124 by making an API call to the funding source computer 124 to verify that information. This operation is another example of a component of the jPOS java library. Despite the illustrations of
In some embodiments, replicas of the databases of funding source computer 124 may be programmatically created and maintained to allow the transaction processing server 108 to retrieve data or information needed to validate the transaction. This allows the validation processes to continue in scenarios where the funding source computer 124 and/or its databases are offline or otherwise not responsive. For example, the replicas of the databases of funding source computer 124 may be created as RAID databases.
At block 210, the transaction processing server 108 is programmed to determine whether the transaction should be validated. In some embodiments, this determination may occur after the transaction processing server 108 has fully executed all of the components of the card processing protocol that it identified as being necessary to validate the transaction. In other embodiments, the transaction processing server 108 may make that determination prior to executing all of the components of the card processing protocol that it identified as being necessary to validate the transaction. For example, if the transaction processing server 108 determines that the payment card used for the transaction does not have a valid payment card account with the funding source computer 124 prior to executing all of the components, the transaction processing server 108 may programmatically stop executing additional components and determine that the transaction cannot be validated.
In an embodiment, the transaction processing server 108 may be required to complete the validation process illustrated in blocks 206, 208, and 210 within a particular time period. For example, the payment network 104 may be programmed to enforce a maximum response time of seven (7) seconds for the validation request provided to the transaction processing server 108. If the transaction processing server 108 does not respond to the validation request within the specified time period, the payment network 104 may be programmed to assume that the transaction cannot be validated. The enforcement of these time limits may be programmed, for example, using a clock thread that executes asynchronously with respect to operations of the transaction processing server 108 and watches or monitors timestamp values that are entered in a log file or in memory of the payment network 104 (or a separate independent system) to determine whether the elapsed time for executing the process exceeds the programmed time limit.
If the clock thread determines that the elapsed time exceeds the programmed limit, then the clock thread may be programmed to interrupt or halt the operations of the transaction processing server 108 or return a failure message to the payment network 104. In some embodiments, the maximum response time may be specified by the payment network 104. In other embodiments, the maximum response time may be specified by the card processing protocol.
The operations depicted in blocks 206, 208, and 210 are described with additional detail below, with references to
At block 212, upon receiving the validation determination from the transaction processing sever 108, the payment network 104 is programmed to provide a determination of whether the transaction should be initiated to the card device 107 based at least on the validation determination.
At block 214, upon receiving the determination from the payment network 104, the card device 107 is programmed to allow or deny the transaction based at least on the payment network 104′s determination.
Some components of the card processing protocol described herein for
Referring now to
At block 263, the transaction processing server 108 is programmed to determine a mapping of the dependencies between each of the identified components. For example, the transaction processing server 108 may determine that before certain components can be executed, other components may need to be executed first. Such dependencies are mapped out by the transaction processing server 108.
At block 265, the transaction processing server 108 is programmed to group components of the card processing protocol (e.g., jPOS or the protocol of
For example,
In an embodiment, the dependencies between the components of the card processing protocol are mapped out and codified to allow the components of the card processing protocol to be grouped together after the transaction processing server 108 receives the validation request message. In such embodiment, the transaction processing server 108 is programmed to receive the validation request, determine the type of the transaction, identify the components of the card processing protocol necessary to validate the transaction, then dynamically create groupings of the identified components based on the codified dependencies.
In an embodiment, the dependencies between the components of the card processing protocol may be codified based on a topological ordering, which may involve generating a directed acyclic graph (DAG) based on the dependencies of the components of the card processing protocol. Topological ordering specifies scheduling a sequence of jobs, or operations, based on their dependencies such that certain operations are completed before another operation. A DAG is a graphical representation that may be generated based on the topological ordering of operations.
Referring again to
At block 269, the funding source computer 124 is programmed to respond to the API calls received from the transaction processing server.
Once all the API responses have been received, timed-out, or otherwise determined as nonresponsive, at block 271, the transaction processing server 108 is programmed to execute the next group of components in the same manner as described with reference to block 267.
At block 273, the funding source computer 124 is programmed to respond to the API calls received from the transaction processing server.
At block 275, the transaction processing server 108 is programmed to determine whether the transaction should be validated. As noted above, the transaction processing server may be limited to a maximum response time of approximately seven (7) seconds to execute the entire process illustrated in
According to one embodiment, the techniques described herein are implemented by at least one computing device. The techniques may be implemented in whole or in part using a combination of at least one server computer and/or other computing devices that are coupled using a network, such as a packet data network. The computing devices may be hard-wired to perform the techniques or may include digital electronic devices such as at least one application-specific integrated circuit (ASIC) or field programmable gate array (FPGA) that is persistently programmed to perform the techniques or may include at least one general purpose hardware processor programmed to perform the techniques pursuant to program instructions in firmware, memory, other storage, or a combination. Such computing devices may also combine custom hard-wired logic, ASICs, or FPGAs with custom programming to accomplish the described techniques.
The computing devices may be server computers, workstations, personal computers, portable computer systems, handheld devices, mobile computing devices, wearable devices, body mounted or implantable devices, smartphones, smart appliances, internetworking devices, autonomous or semi-autonomous devices such as robots or unmanned ground or aerial vehicles, any other electronic device that incorporates hard-wired and/or program logic to implement the described techniques, one or more virtual computing machines or instances in a data center, and/or a network of server computers and/or personal computers.
Computer system 400 includes an input/output (I/O) subsystem 402 which may include a bus and/or other communication mechanism(s) for communicating information and/or instructions between the components of the computer system 400 over electronic signal paths. The I/O subsystem 402 may include an I/O controller, a memory controller and at least one I/O port. The electronic signal paths are represented schematically in the drawings, for example as lines, unidirectional arrows, or bidirectional arrows.
At least one hardware processor 404 is coupled to I/O subsystem 402 for processing information and instructions. Hardware processor 404 may include, for example, a general-purpose microprocessor or microcontroller and/or a special-purpose microprocessor such as an embedded system or a graphics processing unit (GPU) or a digital signal processor or ARM processor. Processor 404 may comprise an integrated arithmetic logic unit (ALU) or may be coupled to a separate ALU.
Computer system 400 includes one or more units of memory 406, such as a main memory, which is coupled to I/O subsystem 402 for electronically digitally storing data and instructions to be executed by processor 404. Memory 406 may include volatile memory such as various forms of random-access memory (RAM) or other dynamic storage device. Memory 406 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 404. Such instructions, when stored in non-transitory computer-readable storage media accessible to processor 404, can render computer system 400 into a special-purpose machine that is customized to perform the operations specified in the instructions.
Computer system 400 further includes non-volatile memory such as read only memory (ROM) 408 or other static storage device coupled to 1/0 subsystem 402 for storing information and instructions for processor 404. The ROM 408 may include various forms of programmable ROM (PROM) such as erasable PROM (EPROM) or electrically erasable PROM (EEPROM). A unit of persistent storage 410 may include various forms of non-volatile RAM (NVRAM), such as FLASH memory, or solid-state storage, magnetic disk or optical disk such as CD-ROM or DVD-ROM and may be coupled to 1/0 subsystem 402 for storing information and instructions. Storage 410 is an example of a non-transitory computer-readable medium that may be used to store instructions and data which when executed by the processor 404 cause performing computer-implemented methods to execute the techniques herein.
The instructions in memory 406, ROM 408 or storage 410 may comprise one or more sets of instructions that are organized as modules, methods, objects, functions, routines, or calls. The instructions may be organized as one or more computer programs, operating system services, or application programs including mobile apps. The instructions may comprise an operating system and/or system software; one or more libraries to support multimedia, programming or other functions; data protocol instructions or stacks to implement TCP/IP, HTTP or other communication protocols; file format processing instructions to parse or render files coded using HTML, XML, JPEG, MPEG or PNG; user interface instructions to render or interpret commands for a graphical user interface (GUI), command-line interface or text user interface; application software such as an office suite, internet access applications, design and manufacturing applications, graphics applications, audio applications, software engineering applications, educational applications, games or miscellaneous applications. The instructions may implement a web server, web application server or web client. The instructions may be organized as a presentation layer, application layer and data storage layer such as a relational database system using structured query language (SQL) or no SQL, an object store, a graph database, a flat file system or other data storage.
Computer system 400 may be coupled via I/O subsystem 402 to at least one output device 412. In one embodiment, output device 412 is a digital computer display. Examples of a display that may be used in various embodiments include a touch screen display or a light-emitting diode (LED) display or a liquid crystal display (LCD) or an e-paper display. Computer system 400 may include other type(s) of output devices 412, alternatively or in addition to a display device. Examples of other output devices 412 include printers, ticket printers, plotters, projectors, sound cards or video cards, speakers, buzzers or piezoelectric devices or other audible devices, lamps or LED or LCD indicators, haptic devices, actuators or servos.
At least one input device 414 is coupled to I/O subsystem 402 for communicating signals, data, command selections or gestures to processor 404. Examples of input devices 414 include touch screens, microphones, still and video digital cameras, alphanumeric and other keys, keypads, keyboards, graphics tablets, image scanners, joysticks, clocks, switches, buttons, dials, slides, and/or various types of sensors such as force sensors, motion sensors, heat sensors, accelerometers, gyroscopes, and inertial measurement unit (IMU) sensors and/or various types of transceivers such as wireless, such as cellular or Wi-Fi, radio frequency (RF) or infrared (IR) transceivers and Global Positioning System (GPS) transceivers.
Another type of input device is a control device 416, which may perform cursor control or other automated control functions such as navigation in a graphical interface on a display screen, alternatively or in addition to input functions. Control device 416 may be a touchpad, a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 404 and for controlling cursor movement on display 412. The input device may have at least two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane. Another type of input device is a wired, wireless, or optical control device such as a joystick, wand, console, steering wheel, pedal, gearshift mechanism or other type of control device. An input device 414 may include a combination of multiple different input devices, such as a video camera and a depth sensor.
In another embodiment, computer system 400 may comprise an internet of things (IoT) device in which one or more of the output device 412, input device 414, and control device 416 are omitted. Or, in such an embodiment, the input device 414 may comprise one or more cameras, motion detectors, thermometers, microphones, seismic detectors, other sensors or detectors, measurement devices or encoders and the output device 412 may comprise a special-purpose display such as a single-line LED or LCD display, one or more indicators, a display panel, a meter, a valve, a solenoid, an actuator or a servo.
When computer system 400 is a mobile computing device, input device 414 may comprise a global positioning system (GPS) receiver coupled to a GPS module that is capable of triangulating to a plurality of GPS satellites, determining and generating geo-location or position data such as latitude-longitude values for a geophysical location of the computer system 400. Output device 412 may include hardware, software, firmware and interfaces for generating position reporting packets, notifications, pulse or heartbeat signals, or other recurring data transmissions that specify a position of the computer system 400, alone or in combination with other application-specific data, directed toward host 424 or server 430.
Computer system 400 may implement the techniques described herein using customized hard-wired logic, at least one ASIC or FPGA, firmware and/or program instructions or logic which when loaded and used or executed in combination with the computer system causes or programs the computer system to operate as a special-purpose machine. According to one embodiment, the techniques herein are performed by computer system 400 in response to processor 404 executing at least one sequence of at least one instruction contained in main memory 406. Such instructions may be read into main memory 406 from another storage medium, such as storage 410. Execution of the sequences of instructions contained in main memory 406 causes processor 404 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions.
The term “storage media” as used herein refers to any non-transitory media that store data and/or instructions that cause a machine to operation in a specific fashion. Such storage media may comprise non-volatile media and/or volatile media. Non-volatile media includes, for example, optical or magnetic disks, such as storage 410. Volatile media includes dynamic memory, such as memory 406. Common forms of storage media include, for example, a hard disk, solid state drive, flash drive, magnetic data storage medium, any optical or physical data storage medium, memory chip, or the like.
Storage media is distinct from but may be used in conjunction with transmission media. Transmission media participates in transferring information between storage media. For example, transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise a bus of I/O subsystem 402. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.
Various forms of media may be involved in carrying at least one sequence of at least one instruction to processor 404 for execution. For example, the instructions may initially be carried on a magnetic disk or solid-state drive of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a communication link such as a fiber optic or coaxial cable or telephone line using a modem. A modem or router local to computer system 400 can receive the data on the communication link and convert the data to a format that can be read by computer system 400. For instance, a receiver such as a radio frequency antenna or an infrared detector can receive the data carried in a wireless or optical signal and appropriate circuitry can provide the data to I/O subsystem 402 such as place the data on a bus. I/O subsystem 402 carries the data to memory 406, from which processor 404 retrieves and executes the instructions. The instructions received by memory 406 may optionally be stored on storage 410 either before or after execution by processor 404.
Computer system 400 also includes a communication interface 418 coupled to bus 402. Communication interface 418 provides a two-way data communication coupling to network link(s) 420 that are directly or indirectly connected to at least one communication networks, such as a network 422 or a public or private cloud on the Internet. For example, communication interface 418 may be an Ethernet networking interface, integrated-services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of communications line, for example an Ethernet cable or a metal cable of any kind or a fiber-optic line or a telephone line. Network 422 broadly represents a local area network (LAN), wide-area network (WAN), campus network, internetwork or any combination thereof. Communication interface 418 may comprise a LAN card to provide a data communication connection to a compatible LAN, or a cellular radiotelephone interface that is wired to send or receive cellular data according to cellular radiotelephone wireless networking standards, or a satellite radio interface that is wired to send or receive digital data according to satellite wireless networking standards. In any such implementation, communication interface 418 sends and receives electrical, electromagnetic or optical signals over signal paths that carry digital data streams representing various types of information.
Network link 420 typically provides electrical, electromagnetic, or optical data communication directly or through at least one network to other data devices, using, for example, satellite, cellular, Wi-Fi, or BLUETOOTH technology. For example, network link 420 may provide a connection through a network 422 to a host computer 424.
Furthermore, network link 420 may provide a connection through network 422 or to other computing devices via internetworking devices and/or computers that are operated by an Internet Service Provider (ISP) 426. ISP 426 provides data communication services through a world-wide packet data communication network represented as internet 428. A server computer 430 may be coupled to internet 428. Server 430 broadly represents any computer, data center, virtual machine or virtual computing instance with or without a hypervisor, or computer executing a containerized program system such as DOCKER or KUBERNETES. Server 430 may represent an electronic digital service that is implemented using more than one computer or instance and that is accessed and used by transmitting web services requests, uniform resource locator (URL) strings with parameters in HTTP payloads, API calls, app services calls, or other service calls. Computer system 400 and server 430 may form elements of a distributed computing system that includes other computers, a processing cluster, server farm or other organization of computers that cooperate to perform tasks or execute applications or services. Server 430 may comprise one or more sets of instructions that are organized as modules, methods, objects, functions, routines, or calls. The instructions may be organized as one or more computer programs, operating system services, or application programs including mobile apps. The instructions may comprise an operating system and/or system software; one or more libraries to support multimedia, programming or other functions; data protocol instructions or stacks to implement TCP/IP, HTTP or other communication protocols; file format processing instructions to parse or render files coded using HTML, XML, JPEG, MPEG or PNG; user interface instructions to render or interpret commands for a graphical user interface (GUI), command-line interface or text user interface; application software such as an office suite, internet access applications, design and manufacturing applications, graphics applications, audio applications, software engineering applications, educational applications, games or miscellaneous applications. Server 430 may comprise a web application server that hosts a presentation layer, application layer and data storage layer such as a relational database system using structured query language (SQL) or no SQL, an object store, a graph database, a flat file system or other data storage.
Computer system 400 can send messages and receive data and instructions, including program code, through the network(s), network link 420 and communication interface 418. In the Internet example, a server 430 might transmit a requested code for an application program through Internet 428, ISP 426, local network 422 and communication interface 418. The received code may be executed by processor 404 as it is received, and/or stored in storage 410, or other non-volatile storage for later execution.
The execution of instructions as described in this section may implement a process in the form of an instance of a computer program that is being executed and consisting of program code and its current activity. Depending on the operating system (OS), a process may be made up of multiple threads of execution that execute instructions concurrently. In this context, a computer program is a passive collection of instructions, while a process may be the actual execution of those instructions. Several processes may be associated with the same program; for example, opening up several instances of the same program often means more than one process is being executed. Multitasking may be implemented to allow multiple processes to share processor 404. While each processor 404 or core of the processor executes a single task at a time, computer system 400 may be programmed to implement multitasking to allow each processor to switch between tasks that are being executed without having to wait for each task to finish. In an embodiment, switches may be performed when tasks perform input/output operations, when a task indicates that it can be switched, or on hardware interrupts. Time-sharing may be implemented to allow fast response for interactive user applications by rapidly performing context switches to provide the appearance of concurrent execution of multiple processes simultaneously. In an embodiment, for security and reliability, an operating system may prevent direct communication between independent processes, providing strictly mediated and controlled inter-process communication functionality.
Embodiments allow a transaction processing server to more efficiently process a validation request from a payment network by executing multiple components of a card processing protocol in parallel during certain idle times, all within a limited time period, e.g., seven (7) seconds, specified by the payment network. The disclosure to this point has explained that various components of the card processing protocol can be grouped together to be executed during specific idle times, to allow parallel processing of such components. In some embodiments, this technique involves mapping out the dependencies between the components and codifying the dependencies based on topological ordering. This allows the various groups of components of the card processing protocol to be executed in parallel during certain idle times, further allowing faster and more efficient processing of the components of the card processing protocol, all within the brief period of time allowed for such processing. Attributes of these systems include processing times and a scale of throughput and transaction volume that far exceed human capacity and require computer implementation.
The technological improvements provided by the embodiments of this disclosure (e.g., increase in speed and efficiency of the validation process) are critical improvements in view of the recent trends of e-commerce, particularly when compared to the traditional methods of processing the card processing protocol (e.g., sequential processing of card processing protocol). As discussed above, validation requests from a payment network are limited to a specific time window, meaning that any validation process that takes longer than the time window may be deemed a failure. If a validation process fails, the payment network may reject the transaction. During the specified time window, transaction processing servers are required to perform a wide range of tasks that involves generating digital data requests, executing decision logic, transforming data, and responding with other digital data, all within milliseconds to seconds while real-world activities are occurring, such as consumer purchases at a point of sale.
Transaction processing servers may also be required to validate hundreds or thousands of transactions per second. This validation process is becoming increasingly more difficult to accomplish within the time limitation specified by the payment network, in part, due to the astronomical increase in the volume of online transactions in recent times. In addition to the increased volume of online transactions, the validation process is also getting more complex and intricate due to, for example, technological innovations that allow consumers to purchase goods and services that they traditionally would have purchased offline (e.g., ride-sharing, food delivery, etc.). Such technological innovations make the decision logic in the validation process more complex because they introduce different types of data that need to be processed (e.g., virtual payment accounts or cards, user rating of drivers or couriers, location data, merchant data etc.). Thus, in light of the increase in volume and complexity of payment transactions, there is a need to make the validation process more efficient and effective. This problem is addressed by the embodiments disclosed herein.
These embodiments provide a solution by providing systems and methods that increase the speed and efficiency of the validation process that was not possible using traditional systems. Traditional systems and methods require each component of the payment processing protocol to be completed before executing the next component, and thus are much more inefficient than the embodiments described herein. Such traditional systems may not be able to keep up with the trends described above.
In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. The sole and exclusive indicator of the scope of the invention, and what is intended by the applicants to be the scope of the invention, is the literal and equivalent scope of the set of claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction.
Any definitions set forth herein for terms contained in the claims may govern the meaning of such terms as used in the claims. No limitation, element, property, feature, advantage or attribute that is not expressly recited in a claim should limit the scope of the claim in any way. The specification and drawings are to be regarded in an illustrative rather than a restrictive sense.
As used in this disclosure the terms “include” and “comprise” (and variations of those terms, such as “including,” “includes,” “comprising,” “comprises,” “comprised” and the like) are intended to be inclusive and are not intended to exclude further features, components, integers or steps. Throughout this disclosure, an element that is identified by a noun followed by the letter s in parentheses, as in (s), indicates that one or more of the element may be used in various embodiments.
References in this document to “an embodiment,” etc., indicate that the embodiment described or illustrated may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described or illustrated in connection with an embodiment, it is believed to be within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly indicated.
Various features of the disclosure have been described using process steps. The functionality/processing of a given process step could potentially be performed in different ways and by different systems or system modules. Furthermore, a given process step could be divided into multiple steps and/or multiple steps could be combined into a single step. Furthermore, the order of the steps can be changed without departing from the scope of the present disclosure.
It will be understood that the embodiments disclosed and defined in this specification extend to alternative combinations of the individual features and components mentioned or evident from the text or drawings. These different combinations constitute various alternative aspects of the embodiments.
In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. The sole and exclusive indicator of the scope of the invention, and what is intended by the applicants to be the scope of the invention, is the literal and equivalent scope of the set of claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction.
This application is a Continuation of U.S. application Ser. No. 17/348,355, filed on Jun. 15, 2021, the entirety of which is incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 17348355 | Jun 2021 | US |
| Child | 18336698 | US |
