Point-of-sale electronic credit card transactions are authorized and captured by several different entities that communicate with each other over a network connection. In an authorization stage, a credit card or other payment instrument is read by a point-of-sale device. Based on details regarding the payment instrument and a payment amount provided by the merchant, an authorization request for the payment amount is sent electronically from the point-of-sale device to a credit card processor. The credit card processor routes the payment request to a card network, e.g., Visa or Mastercard, which in turn routes the payment request to the card issuer, e.g., a bank. Assuming the card issuer approves the transaction, an approval is then routed back to the merchant.
In a capture stage, a capture request for the approved payment amount is again routed from the merchant to the credit card processor, card network, and card issuer. The capture stage triggers the transfer of funds between the card issuer and the merchant.
The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different figures indicates similar or identical components or features.
A payment processing system may be implemented as a network-based service that receives information from merchant point-of-sale (POS) devices to conduct purchase transactions based on payment instruments provided by customers. Payment instruments may comprise credit cards, debit cards, gift cards, electronic tokens, and so forth. A POS device may perform a transaction involving a payment instrument such as this by sending one or more authorization requests to the payment processing system, followed by a capture request. Each authorization request specifies a payment amount for approval by the issuer of the payment instrument. The capture request triggers the transfer of funds from the customer to the merchant.
In order to provide services for a large number of merchants, the payment processing system may be implemented by servers at geographically dispersed data centers. When requesting services, a POS device may select from any of the data centers, and may send transaction requests to the data centers.
A POS device might typically conduct a particular transaction with a single data center. However, there may be situations in which a particular data center becomes unavailable or does not respond to a request. Rather than waiting for the data center to become available, the POS device can retry the request with a different data center. After a capture request is sent, the data centers synchronize their information to ensure that duplicate authorizations are not captured and to ensure that duplicate captures are not initiated.
In an embodiment described herein, the POS device designates a single data center as being a primary data center for a transaction. The primary data center is responsible for initiating the capture request of the transaction. The first data center from which the POS device receives a request response is designated as the primary data center for a particular transaction.
For example, the POS device may send an authorization request to a first data center and may fail to receive a response, possibly because the data center is down for maintenance. After failing to receive the response, the POS device may send the authorization request to a second data center and may receive a response. Thereafter, every transaction request, including further authorization requests and capture requests, specify the second data center as the primary data center for the transaction. The data centers use this specification to coordinate authorizations and captures.
When a data center receives an authorization request that specifies a different primary data center, the receiving data center performs the authorization and eventually informs the primary data center of the authorization. When a data center receives a capture request that specifies a different primary data center, the receiving data center acknowledges the capture request but does not initiate the capture. Rather, the receiving data center forwards the capture request to the primary data center, and the primary data center initiates the data capture. This allows the primary data center to check for duplicate authorizations and to avoid double captures for the same transaction.
Additional details and scenarios are described below. This brief introduction is provided for the reader's convenience and is not intended to limit the scope of the claims. Furthermore, the techniques described above and below may be implemented in a number of ways and in a number of contexts. Several example implementations and contexts are provided with reference to the following figures, as described below in more detail. However, the following implementations and contexts are but a few of many.
The payment service 102 may include payment processing software, hardware, and/or services that enable a merchant to receive payments from customers when conducting POS purchase transactions with the customers. For example, the payment service 102 may enable a merchant to receive credit card payments, debit card payments, mobile payments, and/or different types of electronic payments from customers.
The payment service 102 interacts with multiple POS computing devices 104, which are associated respectively with different merchants 106. The POS devices 104 are used by the merchants 106 to process payments for purchase transactions from customers. Generally, the POS devices 104 may comprise any of various types of devices, such as terminals, computers, portable devices (tablet computers, smartphones, etc.) and so forth. In some cases, the POS devices 104 may incorporate or work in conjunction with card readers for reading credit cards and/or other payment instruments. In some cases, the POS devices 104 may enable mobile payments, such by allowing a customer to use a smartphone or other mobile device to pay for a purchase transaction. More generally, a POS device is configured to receive information from a payment instrument, which may comprise a physical card or an electronic token or data object, and to interact with bank-related services to facilitate the transfer of funds from the customer to the merchant based on the information from the payment instrument.
A customer pays for a purchase transaction by providing a payment instrument such as a debit card, a credit card, a stored-value or gift card, a check, an electronic token provided by a device carried by the customer, etc. The merchant can interact with the POS device 104 to process the transaction, such as by inputting (e.g., manually, via a magnetic card reader or an RFID reader, etc.) an identifier associated with the payment instrument. For example, a payment instrument of one of the customers may include one or more magnetic strips for providing card and customer information when swiped in a card reader. In other examples, other types of payment cards may be used, such as smart cards having built-in memory chips that are read by the device 104 when the cards are “dipped” into the reader, radio frequency identification tags, and so forth. The merchant and/or the POS device 104 may also provide other information describing the transaction, such as a payment amount, the item(s) being purchased, a time, place and date of the transaction, a card network associated with the payment instrument, an issuing bank of the payment instrument, and so forth.
Although
The payment service 102 communicates with a payment network 108 to conduct purchase transactions electronically on behalf of the merchants 106. For purposes of discussion, the payment network 108 represents one or more card payment networks (e.g., MasterCard®, VISA®), issuing banks, acquiring banks, and other entities, banks, or institutions that may be involved in processing payment transactions and electronically transferring funds between merchants and customers.
The payment service 102 may comprise a large-scale service that supports many merchants 106, who may be distributed across large geographic areas. In some cases, the payment service 102 may implement POS services through pages of a website that are accessed by the POS devices 104 of the merchants 106. In these cases, the POS devices 104 may comprise devices such as tablet computers or other portable devices that access the pages of the website using an Internet browser. In other cases, tablet computers or other devices may run special-purpose applications that are specifically configured to implement POS services in conjunction with the payment service 102, using network APIs (application program interfaces) that are made available by the payment service 102.
In order to efficiently serve large numbers of geographically dispersed merchants 106, the payment service 102 may be implemented by servers of multiple data centers 110. Each data center 110 is a facility in a different geographic location that houses redundant computing equipment and software to support the operations and services of the payment service 102. An individual POS device 104 may communicate with servers at any one of the data centers 110 to process payment transactions. In the described example, a POS device 104 selects one of the data centers for any given request. Upon receiving a request, the data center routes the request to one of numerous available servers of the data center, each of which is configured similarly to respond to the request.
The POS devices 104 may communicate with the data centers 110 of the payment service 102 through a network infrastructure such as the Internet. More generally, communications may utilize local area networks, wide area networks, wired networks, Wi-Fi and other wireless networks, cellular data networks, close-range wireless communications such as Bluetooth®, near field communications (NFC), etc. Protocols for communicating over such networks are well known and will not be discussed herein in detail. The same or similar communication technologies may also facilitate communication between the payment service 102 and the payment network 108. Various types of encryption and security techniques may be employed to protect communications from eavesdroppers.
A purchase transaction begins when a merchant specifies a preliminary payment amount for the purchase transaction. The preliminary payment amount may be entered manually by the merchant using the POS device 104 or may be generated automatically by a POS system of the merchant based on prices of purchased or ordered items. Upon being presented with the preliminary payment amount, the customer presents a payment instrument. The payment instrument may comprise a credit card, a debit card, or a similar instrument. In some cases, the payment instrument may comprise an electronic token provided wirelessly by a mobile device, such as when using mobile or cardless payments.
Based on the presented payment amount and payment instrument, the POS device 104 sends an authorization request 202 to the payment service 102. The authorization request 202 specifies various information that may be used by the payment service 102 and in turn by the payment network 108 to obtain authorization for the payment amount. The information may include the payment amount as well as payment instrument details such as credit card information. Credit card information may include things such as the credit card number, a security code, expiration date, and so forth. In addition, the authorization request 202 specifies a transaction identifier (ID) that is unique to the purchase transaction of which the specified payment amount is a part. In addition to uniquely identifying the purchase transaction, the transaction ID may also uniquely identify the POS device 104 and/or the merchant 106 who is submitting the authorization request 202.
The authorization request 202 may be sent to and received by any one of the multiple data centers 110 of the payment service 102. For purposes of discussion,
In response to receiving the authorization request 202, the receiving first data center 110(a) interacts with the payment network 108 to obtain an authorization of the payment amount. For example, the payment service 102 may provide credit card information and transaction information to a credit card processing network to obtain an approval for the authorization request 202. The payment service 102 may also perform its own risk analysis to determine whether to approve the authorization request 202.
Assuming that the authorization request 202 is approved by both the payment network 108 and the payment service 102, the first data center 110(a) sends an authorization 204 of the payment amount to the POS device 104. The authorization 204 specifies a data center ID, referred to herein as a DCID, corresponding to the receiving first data center 110(a). The DCID uniquely identifies the first data center 110(a) and distinguishes it from the other data centers 110. The authorization 204 may also include other information that is not shown in
Upon receiving the authorization 204 and the accompanying DCID of the receiving first data center 110(a), the POS device 104 designates the data first data center 110(a) as the primary data center for the purchase transaction, and associates the DCID of the first data center 110(a) with the transaction ID of the purchase transaction. Subsequently, the POS device 104 will include the DCID of the primary data center, referred to herein as the primary DCID, in each request sent to any one of the data centers 110 regarding the purchase transaction. This allows the data centers 110 to coordinate their handling of the requests among themselves, as will be discussed in detail below.
Some purchase transactions may include multiple authorizations. This may be the case, for example, when a customer presents more than one credit card for payment of a purchase or when multiple customers split the payment for a purchase transaction. As another example, this may occur when a customer orders additional items after an initial authorization. Purchase transactions that include multiple authorizations may be referred to as split tender or multiple tender transactions, and each authorization may be referred to as a tender.
The second authorization request 206 may be sent to and received by any one of the data centers 110. In this example, the second authorization request 206 is shown as being sent to and received by a second data center 110(b), which is different than the first data center 110(a).
Assuming that the second authorization request 206 is approved in a manner similar to the first authorization request 202, the second data center 110(b) sends a second authorization 208 to the POS device 104. The second authorization 208 may indicate the DCID of the responding data center 110(b), which in this example will be different than the primary DCID. The second authorization 208 may also indicate additional information that is not shown in
After all payment amounts for a particular purchase transaction have been approved and the merchant is ready to finalize the transaction, the POS device 104 sends a capture request 210 to the payment service 102. As with any others of the requests, the capture request 210 may be sent to and received by any one of the data centers 110. In this example, the capture request 210 is shown as being sent to and received by a third data center 110(c), which is different than the first data center 110(a) and different than the second data center 110(b).
The capture request 210 specifies the transaction ID of the transaction, which is identical to the transaction ID specified by the first authorization request 202 and by the second authorization request 206. The capture request 210 also specifies previous authorizations and payment amounts that are to be captured. In addition, the second authorization request 206 specifies the primary DCID, corresponding to the first data center 110(a), which was the data center that responded to the first authorization request 202.
In response to receiving the capture request 210, the payment service 102 sends a capture request acknowledgement 212 to the POS device 104. The capture request acknowledgement 212 may specify the DCID of the receiving and responding third data center 110(c), which in this case is not the same as the primary DCID. The capture request acknowledgment 212 may also specify other information as may be appropriate, including the transaction ID, the primary DCID, a listing of captured payment amounts or authorizations, and other information relating to the capture of the purchase transaction.
In the more general case, the requests 202, 206, and 210 shown in
As mentioned above, a merchant may use multiple POS devices and elements of a transaction may be synchronized between the multiple POS devices so that a single transaction may be conducted using two or more POS devices of a merchant. For example, a first POS device may be used for an authorization request and a second POS device may be used for a corresponding capture request. After each request, the response from the payment service 102 may be provided by the payment service 102 to both the requesting POS device and to the other POS devices of the merchant, so that each POS device has information relating to each pending transaction, and so that future requests regarding a transaction may be initiated by any one of the multiple merchant POS devices.
The method 300 implements a sequence of transaction requests for a single purchase transaction. In the described environment, a transaction request may comprise an authorization request or a capture request. All transaction requests corresponding to the purchase transaction are identified by a single transaction ID. In multi tender or split tender transactions, details of which will be described with reference to
An action 302, which is performed by the POS device when the merchant is ready to send an initial transaction request, comprises selecting one of multiple data centers of a payment service to which the transaction request will be submitted. In some embodiments, a merchant POS device may be configured by default to use a particular one of the data centers, such as the data center that is closest geographically to the merchant. In other embodiments, the merchant POS system may select one of the data centers based on its geographic proximity, the speed of communications with the data center, the communication latency with the data center, whether the data center is currently online, and so forth. In some cases, the merchant device may randomly select one of the data centers. In some cases, an initially selected data center may turn out to be unavailable or may fail to respond to a request. This may be because the data center has been disabled for maintenance or because the data center is experiencing problems of some sort. It may also be because of communication problems between the merchant POS device and the data center.
An action 304 comprises sending a first transaction request to the selected data center. In the examples discussed herein, the first transaction request may comprise an authorization request for a payment amount. Alternatively, the first transaction request may comprise a bill creation request.
The first transaction request specifies a transaction ID that uniquely identifies the particular transaction of which the first transaction request is a part. In the case of an authorization request, the authorization request may also include the information discussed above with reference to the authorization request 204.
An action 306 comprises determining whether a response is received from the selected data center. The POS device may fail to receive a response in situations where the selected data center is unavailable due to data center maintenance or operational problems, for example. Other problems may also prevent the POS system from receiving a response from the selected data center, such as communication issues between the POS device and the selected data center.
If a response is not received from the selected data center, the actions 302 and 304 are repeated, where the action 302 selects a different data center and the action 304 comprises resubmitting the first transaction request to the different data center. The different data center may be selected based on its proximity to the merchant and/or other factors, similar to the initial data center selection.
The actions 302, 304, and 306 may be repeated until the merchant POS device receives a response from the selected data center to the submitted first transaction request.
After the merchant POS device receives a response to the action 304 of sending the first transaction request, the merchant POS device performs an action 308 of associating the DCID of the responding data center with the transaction ID of the purchase transaction. This effectively designates the first successfully responding data center as being the primary data center for the purchase transaction, and as being the data center that will have primary responsibility for eventually capturing the authorized payment amounts of the purchase transaction. All subsequent transaction requests sent by the POS device for the purchase transaction will carry the DCID of this first-responding data center, which as mentioned above is referred to herein as the primary DCID of the transaction.
The remaining actions illustrated by
The action 310 comprises selecting a data center. The data center selected in this action may be the same data center selected in the action 302 or may comprise a different data center. The selection may be made based on the factors described above with reference to the action 302.
An action 312 comprises submitting a subsequent transaction request. This transaction request may comprise an authorization request or a capture request. When the subsequent transaction request is an authorization request, the authorization request may specify the information mentioned above with regard to the authorization request 206, including the transaction ID and the primary DCID. When the subsequent transaction request is a capture request, the capture request may specify the information mentioned above with regard to the capture request 210, including the transaction ID and the primary DCID.
An action 314 comprises determining whether a response is received from the selected data center. The POS device may fail to receive a response in situations where the selected data center is unavailable due to data center maintenance or operational problems, for example. Other problems may also prevent the POS system from receiving a response from the selected data center, such as communication issues between the POS device and the selected data center.
If a response is not received from the selected data center, the actions 310 and 312 are repeated, where the action 310 selects a different data center and the action 312 comprises resubmitting the subsequent transaction request to the different data center.
An action 316 comprises determining whether the transaction has been captured, which may be the case when the most recent transaction request was a capture request for which a response was successfully received. If the transaction has not been captured, the actions 310, 312, and 314 are repeated for one or more additional transaction requests. Otherwise, if the transaction has been captured by submitting a capture request and receiving an acknowledgement of the capture request, the method 300 is terminated and the purchase transaction is considered to be completed from the standpoint of the POS device. In some cases, the POS device may provide a receipt at this point.
An action 402 comprises receiving an authorization request, such as the first authorization request 202 or a subsequent authorization request 206 of
An action 404 comprises obtaining approval for the payment amount of the authorization request and returning an authorization to the requesting POS device. The data center receiving the authorization request may obtain an approval by communicating with a card payment network or other payment processing network, such as the payment network 108 of
An action 406 comprises determining whether a primary DCID was specified by the received authorization request. As described with reference to
If a primary DCID is not specified by the received authorization request, an action 408 is performed of recording the authorization, to be potentially captured in the future in response to a capture request received from the POS device. If a primary DCID is specified by the authorization request, an action 410 is performed of informing the primary data center, as identified by the specified primary DCID, of the authorization. This allows the primary data center to eventually capture the payment amount of the authorization, in response to a future capture request received from the POS system. The receiving data center may report the payment amount of the authorization, an approval code associated with the authorization, and so forth.
In some cases, the action 410 of informing the primary data center of an authorization may not be immediately possible, because the primary data center may unavailable due to maintenance or communication issues. In these cases, the authorization is queued and provided to the primary data center when the primary data center eventually becomes available.
An action 502 comprises receiving a capture request, such as the capture request 210 of
An action 504 comprises sending a capture request acknowledgement of the received capture request to the requesting POS device. The acknowledgement indicates to the POS device that the capture request has been received and queued for processing, and that further action by the POS device is not necessary for capturing the payment transaction.
An action 506 comprises determining whether the receiving data center is the primary data center, as indicated by the primary DCID of the capture request. If the receiving data center is the primary data center, an action 508 is performed of initiating a capture of the transaction specified by the capture request. This may involve communicating with a card payment network or other payment processing network, such as the payment network 108 of
If the receiving data center is not the primary data center, an action 510 is performed of forwarding the capture request to the primary data center. This may comprise forwarding the information specified by the received capture request, such as the transaction ID, the primary DCID, enumerated authorizations and payment amounts, etc.
In some cases, the action 510 of forwarding the capture request to the primary data center may not be immediately possible, because the primary data center may be unavailable due to maintenance or communication issues. In these cases, the capture request is queued and provided to the primary data center when the primary data center eventually becomes available.
Upon receiving a forwarded capture request, the primary data center for the transaction initiates the requested capture by communicating with the payment network 108 of
The POS device 104 initially sends a first authorization request 602 to the first data center 110(a). As indicated by the dashed block 604, the POS device 104 fails to receive a response from the first data center 110(a), which could be because the first data center 110(a) is inoperative, that there is a communication issue between the POS device 104 and the first data center 110(a), or that a communication error occurred during communications between the POS device 104 and the first data center 110(a). Meanwhile, the status of the first authorization request 602 is unknown to the POS device 104, because the first data center 110(a) may or may not have obtained an authorization 606 in response to the first authorization request 602, despite the POS device 104 not having received a response to the authorization request 602.
In response to failing to receive a response to the first authorization request 602, the POS device 104 sends a second authorization request 608 for the payment amount to the second data center 110(b). The second authorization request 608 may be essentially identical to the prior authorization request 602, and may specify the same information. In this case, the POS device 104 does receive an authorization response 608 from the second data center 110(b), indicating that the data center did obtain an authorization 610 for the requested payment amount. The authorization response 608 specifies the DCID of the second data center 110(b). Henceforth, the DCID of the second data center 110(b) is considered to be the primary DCID, and is specified by the POS device 104 in all future transaction requests, including authorization and capture requests.
The POS device 104 then sends a capture request 612 to the first data center 110(a). The capture request specifies the primary DCID, corresponding to the DCID of the second data center 110(b) from which the authorization response 608 was received. The first data center 110(a) responds with an acknowledgement response 614.
After and/or at any time before receiving the capture request 612, the first and second data centers 110(a) and 110(b) synchronize their information regarding the transaction. In this example, the synchronization comprises forwarding the capture request 612 from the first data center 110(a) to the second data center 110(b), where the second data center 110(b) corresponds to the primary DCID specified by the capture request 612. For example, upon receiving the capture request 612, the first data center 110(a) may immediately, or as soon as the second data center 110(b) is able to receive communications, send the information specified by the capture request 612 to the second data center 110(b), which in this example is considered the primary data center. Upon receiving the forwarded capture request, which indicates the DCID of the second data center 110(b), the second data center initiates a capture of the transaction, where the capture includes the payment amount specified by the authorization request 608.
The synchronization 616 may additionally include exchanging information regarding previous authorizations obtained for the transaction so that duplicated authorizations may be detected and voided. In this example, the first data center 110(a) is shown as performing an action 620 of voiding the authorization 606 (assuming it was actually obtained), since it is a duplicate of the second authorization 610.
The POS device 104 then sends a first capture request 708 to the first data center 110(a). The first capture request (and all subsequent requests) specifies the primary DCID, corresponding to the DCID of the first data center from which the authorization communication 704 was received.
As indicated by the dashed block 710, the POS device 104 fails to receive a response from the first data center 110(a), which could be because the first data center 110(a) is inoperative, because there is a communication issue between the POS device 104 and the first data center 110(a), or because an error occurred during communications between the POS device 104 and the first data center 110(a). Meanwhile, the status of the first capture request 708 is unknown to the POS device 104, because the first data center 110(a) may or may not have initiated an actual capture 712 of the transaction in response to the first capture request 708.
In response to failing to receive a response to the first capture request 708, the POS device 104 sends a second capture request 714 for the payment amount to the second data center 110(b). The second capture request 714 may be essentially identical to the prior capture request 708, and may specify the same information. In this case, the second data center 110(b) sends and the POS device 104 receives a capture acknowledgment response 716. However, the second data center 110(b) does not initiate the actual capture of the transaction. Rather, in a synchronization operation 718, the second data center 110(b) forwards the capture request 714 to the first data center 110(a), based on the primary DCID specified by the capture request 714, which corresponds to the first data center 110(a). In response to receiving the forwarded capture request, the first data center 110(a) may in some cases initiate an actual capture 720 of the transaction. In particular, the second capture 720 is performed if the first capture 712 was not already performed. If the first capture 712 was successfully performed, the second capture 720 is not performed.
In the example of
The POS device 104 then sends a first authorization request 806 to the first data center 110(a). The first authorization request 806 specifies the primary DCID, corresponding to the DCID of the first data center 110(a) from which the acknowledgement 804 was received. As indicated by the dashed block 808, the POS device 104 fails to receive a response from the first data center 110(a) in response to the first authorization request 806, which could be because the first data center 110(a) is inoperative, because there is a communication issue between the POS device 104 and the first data center 110(a), or because an error occurred during communications between the POS device 104 and the first data center 110(a). Meanwhile, the status of the first authorization request 806 is unknown to the POS device 104, because the first data center 110(a) may or may not have obtained a first authorization 810 in response to the first authorization request 806.
In response to failing to receive a response to the first authorization request 806, the POS device 104 sends a second authorization request 812 for the payment amount to the second data center 110(b). The second authorization request 812 may be essentially identical to the prior authorization request 806, and may specify the same information. The second authorization request 812 specifies the primary DCID, corresponding to the DCID of the first data center 110(a) in this example.
In this case, the POS device does receive an authorization response 816 from the second data center 110(b), indicating that the second data center 110(b) did obtain an authorization 814 for the requested payment amount.
In this multiple tender example, the POS device 104 may obtain multiple authorizations, for multiple payment amounts, by sending multiple authorization requests to any one of the data centers, where each authorization request specifies the primary DCID, which is the DCID of the first responding data center. In the case where an authorization is provided from a data center other than the primary data center, the authorization is synchronized in an action 818, which may comprise notifying or informing the primary data center of the authorization. In other words, the details of any authorizations performed by a non-primary data center are eventually communicated to the primary data center of the transaction, so that the primary data center can detect duplicate authorizations.
After obtaining all authorizations, the POS device 104 sends a capture request 820 to any one of the data centers 110. In this example, the capture request 820 is sent to the second data center 110(b). The capture request 820 specifies the primary DCID, corresponding to the DCID of the first data center 110(a), from which the acknowledgement 804 was received. The second data center 110(b) responds to the POS device 104 with an acknowledgement response 822.
After receiving the capture request 820, the first and second data centers 110(a) and 110(b) synchronize their information regarding the transaction. In certain embodiments, this may comprise forwarding the capture request 820 from the second data center 110(b) to the first data center 110(a), where the first data center 110(a) corresponds to the primary DCID specified by the capture request 820. For example, upon receiving the capture request 820, the second data center 110(b) may immediately, or as soon as the first data center 110(a) is able to receive communications, send the information specified by the capture request 820 to the first data center 110(a), which in this example is considered the primary data center. Upon receiving the forwarded capture request, which indicates the DCID of the first data center 110(a), the first data center 110(a) initiates a capture 826 of the transaction, which includes the payment amount of previous authorization requests corresponding to the transaction.
Each of the above scenarios is merely an example and many variations are possible. Moreover, many variations of the techniques discussed above are possible as well without departing from the scope of this disclosure.
In the illustrated example, the POS device 104 includes at least one processor 902, memory 904, a display 906, one or more input/output (I/O) components 908, one or more network interfaces 910, at least one card reader 912, at least one location component 914, and at least one power source 916. Each processor 902 may itself comprise one or more processors or processing cores. For example, the processor 902 can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. In some cases, the processor 902 may be one or more hardware processors and/or logic circuits of any suitable type specifically programmed or configured to execute the algorithms and processes described herein. The processor 902 can be configured to fetch and execute computer-readable processor-executable instructions stored in the memory 904.
Depending on the configuration of the POS device 104, the memory 904 may be an example of tangible non-transitory computer storage media and may include volatile and nonvolatile memory and/or removable and non-removable media implemented in any type of technology for storage of information such as computer-readable processor-executable instructions, data structures, program modules or other data. The memory 904 may include, but is not limited to, RAM, ROM, EEPROM, flash memory, solid-state storage, magnetic disk storage, optical storage, and/or other computer-readable media technology. Further, in some cases, the POS device 104 may access external storage, such as RAID storage systems, storage arrays, network attached storage, storage area networks, cloud storage, or any other medium that can be used to store information and that can be accessed by the processor 902 directly or through another computing device or network. Accordingly, the memory 904 may be computer storage media able to store instructions, modules or components that may be executed by the processor 902. Further, when mentioned, non-transitory computer-readable media exclude media such as energy, carrier signals, electromagnetic waves, and signals per se.
The memory 904 may be used to store and maintain any number of functional components that are executable by the processor 902. In some implementations, these functional components comprise instructions or programs that are executable by the processor 902 and that, when executed, implement operational logic for performing the actions and services attributed above to the POS device 104. Functional components of the POS device 104 stored in the memory 904 may include a merchant application 918, which may present an interface on the POS device 104 to enable the merchant to conduct transactions, receive payments, and so forth, as well as communicating with the payment service 102 for processing payments and sending transaction information. Further, the merchant application 918 may present an interface to enable the merchant to manage the merchant's account, and the like.
Additional functional components may include an operating system 920 for controlling and managing various functions of the POS device 104 and for enabling basic user interactions with the POS device 104. The memory 904 may also store transaction information/data 922 that is received based on the merchant associated with the POS device 104 engaging in various transactions with customers.
In addition, the memory 904 may also store data, data structures and the like, that are used by the functional components. For example, this data may include item information that includes information about the items offered by the merchant, which may include images of the items, descriptions of the items, prices of the items, and so forth. Depending on the type of the POS device 104, the memory 904 may also optionally include other functional components and data, which may include programs, drivers, etc., and the data used or generated by the functional components. Further, the POS device 104 may include many other logical, programmatic and physical components, of which those described are merely examples that are related to the discussion herein.
The network interface(s) 910 may include one or more interfaces and hardware components for enabling communication with various other devices over a network or directly. For example, network interface(s) 910 may enable communication through one or more of the Internet, cable networks, cellular networks, wireless networks (e.g., Wi-Fi) and wired networks, as well as close-range communications such as Bluetooth®, Bluetooth® low energy, and the like, as additionally enumerated elsewhere herein.
The I/O components 908 may include speakers, a microphone, a camera, various user controls (e.g., buttons, a joystick, a keyboard, a keypad, etc.), and/or a haptic output device, and so forth.
In addition, the POS device 104 may include or may be connectable to a payment instrument reader 912. In some examples, the reader 912 may plug in to a port in the POS device 104, such as a microphone/headphone port, a data port, or other suitable port. In other instances, the reader 912 is integral with the POS device 104. The reader 912 may include a read head for reading a magnetic strip of a payment card, and further may include encryption technology for encrypting the information read from the magnetic strip. Alternatively, numerous other types of card readers may be employed with the POS devices 104 herein, depending on the type and configuration of a particular POS device 104.
The location component 914 may include a GPS device able to indicate location information, or the location component 914 may comprise any other location-based sensor. The POS device 104 may also include one or more additional sensors (not shown), such as an accelerometer, gyroscope, compass, proximity sensor, and the like. Additionally, the POS device 104 may include various other components that are not shown, examples of which include removable storage, a power control unit, and so forth.
In the illustrated example, the server 1002 includes at least one processor 1004 and associated memory 1006. Each processor 1004 may itself comprise one or more processors or processing cores. For example, the processor 1004 can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. In some cases, the processor 1004 may be one or more hardware processors and/or logic circuits of any suitable type specifically programmed or configured to execute the algorithms and processes described herein. The processor 1004 can be configured to fetch and execute computer-readable processor-executable instructions stored in the memory 1006.
Depending on the configuration of the server 1002, the memory 1006 may be an example of tangible non-transitory computer storage media and may include volatile and nonvolatile memory and/or removable and non-removable media implemented in any type of technology for storage of information such as computer-readable processor-executable instructions, data structures, program modules or other data. The memory 1006 may include, but is not limited to, RAM, ROM, EEPROM, flash memory, solid-state storage, magnetic disk storage, optical storage, and/or other computer-readable media technology. Further, in some cases, the server 1002 may access external storage, such as RAID storage systems, storage arrays, network attached storage, storage area networks, cloud storage, or any other medium that can be used to store information and that can be accessed by the processor 1004 directly or through another computing device or network. Accordingly, the memory 1006 may be computer storage media able to store instructions, modules or components that may be executed by the processor 1004. Further, when mentioned, non-transitory computer-readable media exclude media such as energy, carrier signals, electromagnetic waves, and signals per se.
The memory 1006 may be used to store and maintain any number of functional components that are executable by the processor 1004. In some implementations, these functional components comprise instructions or programs that are executable by the processor 1004 and that, when executed, implement operational logic for performing the actions and services attributed above to the payment service 102. Functional components stored in the memory 1006 may include a transaction services component 1008 that receives, processes and responds to transaction requests in accordance with the preceding discussion. The transaction services 1008 may also be responsible for synchronizing transactions between data centers as described above.
Additional functional components may include an operating system 1010 and a web services component 1012. The memory 1006 may also store APIs (application programming interfaces) 1014 that are used for communications between the server 1002 and the POS devices 104. The memory 1006 may also store data, data structures and the like, that are used by the functional components.
The server 1002 may have a network communications interface 1016, such as an Ethernet communications interface, which provides communication by the server 1002 with other servers, with the Internet, and ultimately with the POS devices 104.
The server 1002 may of course include many other logical, programmatic, and physical components 1018 that are not specifically described herein.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as illustrative forms of implementing the claims.
This application is a divisional of and claims priority to U.S. patent application Ser. No. 14/711,120 filed on May 13, 2015, now U.S. Pat. No. 9,436,938, which issued on Sep. 6, 2016, and which is incorporated by reference herein.
Number | Name | Date | Kind |
---|---|---|---|
3854036 | Gupta et al. | Dec 1974 | A |
4035614 | Frattarola et al. | Jul 1977 | A |
4254441 | Fisher | Mar 1981 | A |
4591937 | Nakarai et al. | May 1986 | A |
4788420 | Chang et al. | Nov 1988 | A |
4845740 | Tokuyama et al. | Jul 1989 | A |
5173597 | Anglin | Dec 1992 | A |
5266789 | Anglin et al. | Nov 1993 | A |
5434400 | Scherzer | Jul 1995 | A |
5463678 | Kepley, III et al. | Oct 1995 | A |
5589855 | Blumstein et al. | Dec 1996 | A |
5679943 | Schultz et al. | Oct 1997 | A |
5764742 | Howard et al. | Jun 1998 | A |
5850599 | Seiderman | Dec 1998 | A |
5945654 | Huang | Aug 1999 | A |
5983208 | Haller et al. | Nov 1999 | A |
6006109 | Shin | Dec 1999 | A |
6021944 | Arakaki | Feb 2000 | A |
6032859 | Muehlberger et al. | Mar 2000 | A |
6061666 | Do et al. | May 2000 | A |
6129277 | Grant et al. | Oct 2000 | A |
6192408 | Vahalia et al. | Feb 2001 | B1 |
6234389 | Valliani et al. | May 2001 | B1 |
6341353 | Herman et al. | Jan 2002 | B1 |
6363139 | Zurek et al. | Mar 2002 | B1 |
6400517 | Murao | Jun 2002 | B1 |
6431445 | DeLand et al. | Aug 2002 | B1 |
6445717 | Gibson et al. | Sep 2002 | B1 |
6476743 | Brown et al. | Nov 2002 | B1 |
6481623 | Grant et al. | Nov 2002 | B1 |
6536670 | Postman et al. | Mar 2003 | B1 |
6579728 | Grant et al. | Jun 2003 | B2 |
6725200 | Rost | Apr 2004 | B1 |
6850147 | Prokoski et al. | Feb 2005 | B2 |
6896182 | Sakaguchi | May 2005 | B2 |
6898598 | Himmel et al. | May 2005 | B2 |
6944782 | von Mueller et al. | Sep 2005 | B2 |
6999943 | Johnson et al. | Feb 2006 | B1 |
7003316 | Elias et al. | Feb 2006 | B1 |
7062463 | Knapp | Jun 2006 | B2 |
7149296 | Brown et al. | Dec 2006 | B2 |
7203666 | Gravell et al. | Apr 2007 | B1 |
7252232 | Fernandes et al. | Aug 2007 | B2 |
7309012 | von Mueller et al. | Dec 2007 | B2 |
7324836 | Steenstra et al. | Jan 2008 | B2 |
7363054 | Elias et al. | Apr 2008 | B2 |
7409234 | Glezerman | Aug 2008 | B2 |
7433452 | Taylor et al. | Oct 2008 | B2 |
7506812 | von Mueller et al. | Mar 2009 | B2 |
7520430 | Stewart et al. | Apr 2009 | B1 |
7581678 | Narendra et al. | Sep 2009 | B2 |
7600673 | Stoutenburg et al. | Oct 2009 | B2 |
7703676 | Hart et al. | Apr 2010 | B2 |
7708189 | Cipriano | May 2010 | B1 |
7757953 | Hart et al. | Jul 2010 | B2 |
7793834 | Hachey et al. | Sep 2010 | B2 |
7810729 | Morley | Oct 2010 | B2 |
7869591 | Nagel et al. | Jan 2011 | B1 |
7896248 | Morley | Mar 2011 | B2 |
7918394 | Morley, Jr. | Apr 2011 | B1 |
8011587 | Johnson et al. | Sep 2011 | B2 |
8190564 | Pang | May 2012 | B2 |
8231055 | Wen | Jul 2012 | B2 |
8336771 | Tsai et al. | Dec 2012 | B2 |
8376239 | Humphrey | Feb 2013 | B1 |
8413901 | Wen | Apr 2013 | B2 |
8500010 | Marcus et al. | Aug 2013 | B1 |
8560823 | Aytek et al. | Oct 2013 | B1 |
8571989 | Dorsey et al. | Oct 2013 | B2 |
8573487 | McKelvey | Nov 2013 | B2 |
8573489 | Dorsey et al. | Nov 2013 | B2 |
8584946 | Morley | Nov 2013 | B2 |
8602305 | Dorsey et al. | Dec 2013 | B2 |
8612352 | Dorsey et al. | Dec 2013 | B2 |
8615445 | Dorsey et al. | Dec 2013 | B2 |
8640953 | Dorsey et al. | Feb 2014 | B2 |
8678277 | Dorsey et al. | Mar 2014 | B2 |
8701996 | Dorsey et al. | Apr 2014 | B2 |
8701997 | Dorsey et al. | Apr 2014 | B2 |
8763900 | Marcus et al. | Jul 2014 | B2 |
8794517 | Templeton et al. | Aug 2014 | B1 |
8806554 | Stiliadis | Aug 2014 | B2 |
9129321 | Boding et al. | Sep 2015 | B2 |
9412107 | Canis et al. | Aug 2016 | B2 |
9436938 | Botros et al. | Sep 2016 | B1 |
9576287 | Kalinichenko et al. | Feb 2017 | B1 |
9633033 | Vijayan | Apr 2017 | B2 |
20020002507 | Hatakeyama | Jan 2002 | A1 |
20020030871 | Anderson et al. | Mar 2002 | A1 |
20020077974 | Ortiz | Jun 2002 | A1 |
20020095303 | Asayama et al. | Jul 2002 | A1 |
20020116329 | Serbetcioglu et al. | Aug 2002 | A1 |
20020165462 | Westbrook et al. | Nov 2002 | A1 |
20020174063 | Major | Nov 2002 | A1 |
20030080186 | McDonald et al. | May 2003 | A1 |
20030089772 | Chien | May 2003 | A1 |
20030132300 | Dilday et al. | Jul 2003 | A1 |
20030144040 | Liu et al. | Jul 2003 | A1 |
20040012875 | Wood | Jan 2004 | A1 |
20040033726 | Kao | Feb 2004 | A1 |
20040041911 | Odagiri et al. | Mar 2004 | A1 |
20040093496 | Colnot | May 2004 | A1 |
20040104268 | Bailey | Jun 2004 | A1 |
20040127256 | Goldthwaite et al. | Jul 2004 | A1 |
20040128256 | Krouse et al. | Jul 2004 | A1 |
20040151026 | Naso et al. | Aug 2004 | A1 |
20040204074 | Desai | Oct 2004 | A1 |
20040230524 | Meiners | Nov 2004 | A1 |
20050077870 | Ha et al. | Apr 2005 | A1 |
20050119972 | Inglis | Jun 2005 | A1 |
20050138461 | Allen et al. | Jun 2005 | A1 |
20050156037 | Wurzburg | Jul 2005 | A1 |
20050156038 | Wurzburg et al. | Jul 2005 | A1 |
20050194452 | Nordentoft et al. | Sep 2005 | A1 |
20050218206 | Ohno et al. | Oct 2005 | A1 |
20050242173 | Suzuki | Nov 2005 | A1 |
20060000917 | Kim et al. | Jan 2006 | A1 |
20060064380 | Zukerman | Mar 2006 | A1 |
20060094481 | Gullickson | May 2006 | A1 |
20060122902 | Petrov et al. | Jun 2006 | A1 |
20060152276 | Barksdale | Jul 2006 | A1 |
20060159011 | Dalal | Jul 2006 | A1 |
20060208066 | Finn et al. | Sep 2006 | A1 |
20060223580 | Antonio et al. | Oct 2006 | A1 |
20060234771 | Shavrov | Oct 2006 | A1 |
20070063048 | Havens et al. | Mar 2007 | A1 |
20070067833 | Colnot | Mar 2007 | A1 |
20070090183 | Hursta et al. | Apr 2007 | A1 |
20070100651 | Ramer et al. | May 2007 | A1 |
20070155430 | Cheon et al. | Jul 2007 | A1 |
20070213970 | Puthupparambil et al. | Sep 2007 | A1 |
20070221728 | Ferro et al. | Sep 2007 | A1 |
20070233615 | Tumminaro | Oct 2007 | A1 |
20070244811 | Tumminaro | Oct 2007 | A1 |
20070250441 | Paulsen et al. | Oct 2007 | A1 |
20070250623 | Hickey et al. | Oct 2007 | A1 |
20070255653 | Tumminaro et al. | Nov 2007 | A1 |
20080021803 | Ahles et al. | Jan 2008 | A1 |
20080027815 | Johnson et al. | Jan 2008 | A1 |
20080040261 | Nix et al. | Feb 2008 | A1 |
20080040274 | Uzo | Feb 2008 | A1 |
20080059370 | Sada et al. | Mar 2008 | A1 |
20080059375 | Abifaker | Mar 2008 | A1 |
20080098393 | Chai et al. | Apr 2008 | A1 |
20080177662 | Smith et al. | Jul 2008 | A1 |
20080238610 | Rosenberg | Oct 2008 | A1 |
20080313077 | Schropfer | Dec 2008 | A1 |
20090068982 | Chen et al. | Mar 2009 | A1 |
20090098908 | Silverbrook et al. | Apr 2009 | A1 |
20090104920 | Moon et al. | Apr 2009 | A1 |
20090117883 | Coffing et al. | May 2009 | A1 |
20090119190 | Realini | May 2009 | A1 |
20090159681 | Mullen et al. | Jun 2009 | A1 |
20100063893 | Townsend | Mar 2010 | A1 |
20100128598 | Gandhewar et al. | May 2010 | A1 |
20100184479 | Griffin | Jul 2010 | A1 |
20100205078 | Lawrence et al. | Aug 2010 | A1 |
20100243732 | Wallner | Sep 2010 | A1 |
20100332339 | Patel et al. | Dec 2010 | A1 |
20110016052 | Scragg | Jan 2011 | A1 |
20110053560 | Jain et al. | Mar 2011 | A1 |
20110055628 | Dennis et al. | Mar 2011 | A1 |
20110055835 | Dennis et al. | Mar 2011 | A1 |
20110084131 | McKelvey | Apr 2011 | A1 |
20110084139 | McKelvey et al. | Apr 2011 | A1 |
20110084147 | Wilson et al. | Apr 2011 | A1 |
20110137803 | Willins | Jun 2011 | A1 |
20110161235 | Beenau et al. | Jun 2011 | A1 |
20110198395 | Chen | Aug 2011 | A1 |
20110202463 | Powell | Aug 2011 | A1 |
20110258120 | Weiss | Oct 2011 | A1 |
20120005039 | Dorsey et al. | Jan 2012 | A1 |
20120008851 | Pennock et al. | Jan 2012 | A1 |
20120011071 | Pennock et al. | Jan 2012 | A1 |
20120012653 | Johnson et al. | Jan 2012 | A1 |
20120022945 | Falkenborg et al. | Jan 2012 | A1 |
20120052910 | Mu et al. | Mar 2012 | A1 |
20120061467 | Tang et al. | Mar 2012 | A1 |
20120095869 | McKelvey | Apr 2012 | A1 |
20120095871 | Dorsey et al. | Apr 2012 | A1 |
20120095906 | Dorsey et al. | Apr 2012 | A1 |
20120095907 | Dorsey et al. | Apr 2012 | A1 |
20120095916 | Dorsey et al. | Apr 2012 | A1 |
20120097739 | Babu et al. | Apr 2012 | A1 |
20120113796 | Qiu | May 2012 | A1 |
20120118956 | Lamba et al. | May 2012 | A1 |
20120118959 | Sather et al. | May 2012 | A1 |
20120118960 | Sather et al. | May 2012 | A1 |
20120126005 | Dorsey et al. | May 2012 | A1 |
20120126006 | Dorsey et al. | May 2012 | A1 |
20120126007 | Lamba et al. | May 2012 | A1 |
20120126010 | Babu et al. | May 2012 | A1 |
20120126011 | Lamba et al. | May 2012 | A1 |
20120126012 | Lamba et al. | May 2012 | A1 |
20120126013 | Sather et al. | May 2012 | A1 |
20120126014 | Sather et al. | May 2012 | A1 |
20120130903 | Dorsey et al. | May 2012 | A1 |
20120132712 | Babu et al. | May 2012 | A1 |
20120138683 | Sather et al. | Jun 2012 | A1 |
20120168505 | Sather et al. | Jul 2012 | A1 |
20120185392 | Hubbs et al. | Jul 2012 | A1 |
20120191525 | Singh et al. | Jul 2012 | A1 |
20120232980 | Wald et al. | Sep 2012 | A1 |
20120234918 | Lindsay | Sep 2012 | A1 |
20120259651 | Mallon et al. | Oct 2012 | A1 |
20120270528 | Goodman | Oct 2012 | A1 |
20130031003 | Dorsey et al. | Jan 2013 | A1 |
20130031004 | Dorsey et al. | Jan 2013 | A1 |
20130080239 | Okerlund | Mar 2013 | A1 |
20130087614 | Limtao et al. | Apr 2013 | A1 |
20130173464 | Quinlan | Jul 2013 | A1 |
20130200153 | Dorsey et al. | Aug 2013 | A1 |
20130207481 | Gobburu et al. | Aug 2013 | A1 |
20130254117 | von Mueller et al. | Sep 2013 | A1 |
20140001257 | Dorsey et al. | Jan 2014 | A1 |
20140001263 | Babu et al. | Jan 2014 | A1 |
20140006188 | Grigg et al. | Jan 2014 | A1 |
20140012701 | Wall et al. | Jan 2014 | A1 |
20140017955 | Lo et al. | Jan 2014 | A1 |
20140061301 | Cho et al. | Mar 2014 | A1 |
20140076964 | Morley | Mar 2014 | A1 |
20140097242 | McKelvey | Apr 2014 | A1 |
20140124576 | Zhou et al. | May 2014 | A1 |
20140129423 | Murphy et al. | May 2014 | A1 |
20140144983 | Dorsey et al. | May 2014 | A1 |
20140149286 | Forsyth | May 2014 | A1 |
20140156480 | Qaim-Maqami et al. | Jun 2014 | A1 |
20140203082 | Huh | Jul 2014 | A1 |
20140351012 | Jernigan et al. | Nov 2014 | A1 |
20140372234 | Tikku | Dec 2014 | A1 |
20150371212 | Giordano et al. | Dec 2015 | A1 |
20170004487 | Hagen et al. | Jan 2017 | A1 |
Number | Date | Country |
---|---|---|
2001-313714 | Nov 2001 | JP |
2003-108777 | Apr 2003 | JP |
2004-078662 | Mar 2004 | JP |
2005-269172 | Sep 2005 | JP |
2006-139641 | Jun 2006 | JP |
2006-179060 | Jul 2006 | JP |
2006-308438 | Nov 2006 | JP |
10-0452161 | Oct 2004 | KR |
10-2005-0077659 | Aug 2005 | KR |
10-2008-0039330 | May 2008 | KR |
0165827 | Sep 2001 | WO |
02084548 | Oct 2002 | WO |
2010097711 | Sep 2010 | WO |
2010135174 | Nov 2010 | WO |
Entry |
---|
Notice of Allowance dated Aug. 19, 2015, in U.S. Appl. No. 14/711,120, of Botros, P. A., et al., filed May 13, 2015. |
Non-Final Office Action dated Sep. 28, 2015, in U.S. Appl. No. 14/711,120, of Botros, P. A., et al., filed May 13, 2015. |
Final Office Action dated Feb. 18, 2016, in U.S. Appl. No. 14/711,120, of Botros, P. A., et al., filed May 13, 2015. |
Notice of Allowance dated May 4, 2016, in U.S. Appl. No. 14/711,120, of Botros, P. A., et al., filed May 13, 2015. |
“2.5mm Headset Jack,” Retrieved from the Internet URL: http://www.phonescoop.com/glossary/term.php?gid=360, on May 5, 2011, pp. 1-1. |
“A Magnetic Stripe Reader—Read Credit Cards & Driver Licences!,” Articlesbase (articlesbase.com), Sep. 7, 2009, Retrieved from the Internet URL: http://www.articlesbase.com/electronics-articles/a-magnetic-stripe-reader-read-Credit-cards- . . . , on Feb. 8, 2011, pp. 1-3. |
Acidus, “Mag-stripe Interfacing—A Lost Art,” Retrieved from the Internet URL: http://www.scribd.com/doc/18236182/Magstripe-Interfacing#open . . . , on Feb. 7, 2011, pp. 1-4. |
“Announcement: Semtek Introduces Side Swipe II Card Reader for Wireless Devices,” Brighthand, Retrieved from the Internet URL: http://forum.brighthand.com/pdas-handhelds/173285-announcement-semtek-introduces-sid . . . , on Apr. 19, 2011, pp. 1-2. |
“Arduino magnetic stripe decoder,” Instructables, Retrieved from the Internet URL: http://www.instructables.com/id/Arduino-magneticstripe-decorder/, on Feb. 8, 2011, pp. 1-5. |
“Barcode scanner and Magnetic Stripe Reader (MSR) for Pocke . . . ,” Tom's Hardware (tomshardware.com), Retrieved from the Internet URL: http://www.tomshardware.com/forum/24068-36-barcode-scanner-magnetic-stripe-reader-po . . . , on Feb. 8, 2011, pp. 1-2. |
Bauer, G.R. et al., “Comparing Block Cipher Modes of Operation on MICAz Sensor Nodes,” 17th Euromicro International Conference on Parallel, Distributed and Network-based Processing, 2009, Feb. 18-20, 2009, pp. 371-378. |
Bourdeauducq, S., “Reading magnetic cards (almost) for free” (“Lekernel”), Jan. 26, 2009, Retrieved from the Internet URL: http://lekernel.net/blog/?p=12, on May 5, 2011, pp. 1-2. |
Buttell, A.E., “Merchants eye mobile phones to transact card payments,” Feb. 3, 2010, Retrieved from the Internet URL: http://www.merchantaccountguide.com/merchant-account-news/cell-phone-credit-card-mer . . . , on Feb. 8, 2011, pp. 1-3. |
“Credit Card Swiper and Reader for iPhone, iPad, Blackberry, Android and more,” Retrieved from the Internet URL: http://hubpages.com/hub/Credit-Card-Swiper-and-Reader-for-iPhone-iPad-Blackberry-An . . . , on Apr. 20, 2011, pp. 1-2. |
“Get paid on the spot from your mobile phone,” Retrieved from the Internet URL: http://payments.intuit.com/products/basic-payment-solutions/mobile-credit-card-processin . . . , on Feb. 11, 2011, pp. 1-3. |
Grandison, K., “vTerminal Credit Card Processing App for AuthorizeNet and PayPal Payflow Pro for Curve 8350 8500 8900 and Bold 9000,” Retrieved from the Internet URL: http://www.4blackberry.net/tag/business-tools/vterminal-credit-card-processing-app-for-authorizenet-and-paypal-payflow-pro-for-curve-8350-8500-890-download-2075.html, on Mar. 30, 2015, pp. 1-4. |
Harris, A., “Magnetic Stripe Card Spoofer,” Aug. 4, 2008, Retrieved from the Internet URL: http://hackaday.com/2008/08/04/magnetic-stripe-card-spoofer/, on Apr. 25, 2011, pp. 1-11. |
“Headphone Jack (3.5mm),” Retrieved from the Internet URL: http://www.phonescoop.com/glossary/term.php? gid=440, on May 5, 2011, pp. 1-1. |
Jones, R., “U.S. Credit Cards to get a high-tech makeover,” Oct. 22, 2010, Retrieved from the Internet URL: http://lifeine.today.com/_news/2010/10/22/5334208-us-credit-cards-to-get-a-high-tech-mak . . . , on Feb. 8, 2011, pp. 1-8. |
Kuo, Y-S et al., “Hijacking Power and Bandwidth from the Mobile Phone's Audio Interface,” Proceedings of the First ACM Symposium on Computing for Development, (DEV'10), Dec. 17, 2010, pp. 1-10. |
Lucks, S., “Two-Pass Authenticated Encryption Faster than Generic Composition,” H. Gilbert and H. Handschuh (Eds.): FSE 2005, LNCS 3557, © International Association for Cryptologic Research 2005, pp. 284-298. |
“Magnetic Card Reader,” lekernel.net˜scrapbook, Retrieved from the Internet URL: http://lekernel.net/scrapbook/old/cardreader.html, on Apr. 25, 2011, pp. 1-4. |
“Magnetic Stripe Reader (MSR) MSR7000-100R,” Motorola Solutions, Retrieved from the Internet URL: http://www.motorola.com/business/US-EN/MSR7000-100R_US-EN.do?vgnextoid=164fc3 . . . , on Feb. 8, 2011, pp. 1-1. |
“Magnetic stripe reader/writer,” Retrieved from the Internet URL: http://www.gae.ucm.es/-padilla/extrawork/stripe.html, on Dec. 21, 2009, pp. 1-2. |
“Mag-stripe readers The hunt for a homebrew mag-stripe reader that'll work with modern,” Jan. 16, 2009, Retrieved from the Internet URL: http://www.hak5.org/forums/index.php?showtopic=11563&st=20, on Apr. 25, 2011, pp. 1-6. |
“Mophie Marketplace Magnetic Strip Reader/Case for iPhone 3G & 3GS—Grey,” J&R (JR.com), Retrieved from the Internet URL: http://www.jr.com/mophie/pe/MPE_MPIP3GBLK/, on Feb. 8, 2011, pp. 1-1. |
“MSR500EX (Mini123EX) Portable Magnetic Stripe Card Reader,” TYNER, Apr. 27, 2007, Retrieved from the Internet URL: http://www.tyner.com/magnetic/msr500ex.htm, on Apr. 22, 2011, pp. 1-3. |
Padilla, L. “The simplest magnetic stripe reader,” Jan. 27, 2003, Retrieved from the Internet URL: www.gae.ucm.esi˜padilla/extrawork/soundtrack.html, on Dec. 21, 2009, pp. 1-5. |
Padilla, L., “Magnetic stripe reader circuit,” Jan. 28, 1997, Retrieved from the Internet URL: http://www.gae.ucm.es/˜padilla/extraworklmagamp.html, on May 5, 2011, pp. 1-7. |
Padilla, L., “Turning your mobile into a magnetic stripe reader,” Retrieved from the Internet URL: http://www.gae.ucm.es/˜padilla/extrawork/mobilesoundtrack.html, on Feb. 7, 2011, pp. 1-4. |
“Pay@PC,” Retrieved from the Internet URL: http://www.merchantanywhere.com/PAY_AT_PCT@PC.htm, on Feb. 11, 2011, pp. 1-2. |
“Reference Designations for Electrical and Electronics Parts and Equipment, Engineering Drawing and Related Documentation Practices,” ASME Y14.44/2008, The American Society of Mechanical Engineers, Nov. 21, 2008, pp. 1-31. |
“Semtek 3913 Insert Magnetic Card Reader 20 Pin Serial RS232,” Product description, RecycledGoods.com, Retrieved from the Internet URL: http://www.recycledgoods.com/products/Semtek-3913-Insert-Magnetic-Card-Reader-20-Pi . . . , on Apr. 19, 2011, pp. 1-3. |
“Semtek to target healthcare with HandEra PDAs and PDA swipe card reader,” Aug. 29, 2001, Retrieved from the Internet URL: http://www.pdacortex.com/semtek.htm, on Apr. 19, 2011, pp. 1-2. |
Titlow, J.P., “ROAM pay is like Square for Blackberry (Plus Android, iOS and Desktops),” Dec. 1, 2010, Retrieved from the Internet URL: http://www.readwriteweb.com/biz/2010/12/roampay-is-like-square-for-bla.php, on Apr. 20, 2011, pp. 1-12. |
“Touch-Pay Wireless Credit Card Processing,” MerchantSeek, Retrieved from the Internet URL: http://www.merchantseek.com/wireless-credit-card-processing.htm, on Feb. 11, 2011, pp. 1-5. |
“Travel industry targeted for Palm PDA card reader,” Retrieved from the Internet URL: http://www.m-travel.com/news/2001/08/travel_industry.html, on Apr. 19, 2011, pp. 1-2. |
“USB Magnetic Stripe Credit/Card Track-2 Reader and Writer (75/210BPI),” Deal Extreme (dealextreme.com), Nov. 15, 2008, Retrieved from the Internet URL: http://www.dealextreme.com/p/usb-magnetic-stripe-credit-debit-card-track-2-reader-and-wr . . . , on Feb. 8, 2011, pp. 1-3. |
Veneziani, V., “Use a cellphone as a magnetic card reader,” Apr. 15, 2005, Retrieved from the Internet URL: http://hackaday.com/2005/04/15/use a-cellphone-as-a-magnetic-card . . . , on Feb. 7, 2011, pp. 1-10. |
Website: www.alexwinston.com, Aug. 31, 2009, pp. 1-5. |
Non-Final Office Action dated Jul. 30, 2014, for U.S. Appl. No. 14/266,504, of Bhatt, A., et al., filed Apr. 30, 2014. |
Non-Final Office Action dated Sep. 30, 2014, for U.S. Appl. No. 13/802,630, of Kalinichenko, A., et al., filed Mar. 13, 2013. |
Final Office Action dated Dec. 3, 2014, for U.S. Appl. No. 14/266,504, of Bhatt, A., et al., filed Apr. 30, 2014. |
Non-Final Office Action dated Mar. 13, 2015, for U.S. Appl. No. 13/802,630, of Kalinichenko, A., et al., filed Mar. 13, 2013. |
Non-Final Office Action dated Mar. 27, 2015, U.S. Appl. No. 14/177,201, of Templeton, T., et al., filed Feb. 10, 2014. |
Non-Final Office Action dated Jun. 19, 2015, for U.S. Appl. No. 13/802,630, of Kalinichenko, A., et al., filed Mar. 13, 2013. |
Non-Final Office Action dated Nov. 13, 2015, for U.S. Appl. No. 14/177,201, of Templeton, T., et al., filed Feb. 10, 2014. |
Non-Final Office Action dated Jan. 20, 2016, for U.S. Appl. No. 13/802,630, of Kalinichenko, A., et a., filed Mar. 13, 2013. |
Final Office Action dated May 31, 2016, for U.S. Appl. No. 14/177,201, of Templeton, T., et al., filed Feb. 10, 2014. |
Final Office Action dated Jul. 15, 2016, for U.S. Appl. No. 13/802,630, of Kalinichenko, A., et al., filed Mar. 13, 2013. |
Non-Final Office Action dated Sep. 9, 2016, for U.S. Appl. No. 14/461,146, of Kim, M., filed Aug. 15, 2014. |
Non-Final Office Action dated Sep. 22, 2016, for U.S. Appl. No. 14/177,201, of Templeton, T., et al., filed Feb. 10, 2014. |
Notice of Allowance dated Oct. 7, 2016, for U.S. Appl. No. 13/802,630, of Kalinichenko, A., et al., filed Mar. 13, 2013. |
Non-Final Office Action dated Dec. 7, 2016, U.S. Appl. No. 14/184,590, of Dorogusker, J., et al., filed Feb. 19, 2014. |
Final Office Action dated Apr. 18, 2017, for U.S. Appl. No. 14/461,146, of Kim, M., filed Aug. 15, 2014. |
Non-Final Office Action dated Apr. 21, 2017, for U.S. Appl. No. 15/444,898, of Iyer, K, et al., filed Feb. 28, 2017. |
Final Office Action dated Jun. 16, 2017, for U.S. Appl. No. 14/184,590, of Dorogusker, J., et al., filed Feb. 19, 2014. |
Advisory Action dated Aug. 11, 2017, for U.S. Appl. No. 14/184,590, of Dorogusker, J., et al., filed Feb. 19, 2014. |
Final Office Action dated Sep. 7, 2017, for U.S. Appl. No. 14/177,201, of Templeton, T., et al., filed Feb. 10, 2014. |
Non-Final Office Action dated Oct. 5, 2017, for U.S. Appl. No. 14/461,146, of Kim, M., filed Aug. 15, 2014. |
Final Office Action dated Oct. 26, 2017, for U.S. Appl. No. 15/444,898, of Iyer, K., et al., filed Feb. 28, 2017. |
Advisory Action dated Jan. 4, 2018, for U.S. Appl. No. 14/177,201, of Templeton, T., et al., filed Feb. 10, 2014. |
Advisory Action dated Feb. 28, 2018, for U.S. Appl. No. 15/444,898, of Iyer, K., et al., filed Feb. 28, 2017. |
Non-Final Office Action dated Mar. 2, 2018, U.S. Appl. No. 14/184,590, of Dorogusker, J., et al., filed Feb. 19, 2014. |
Non-Final Office Action dated Mar. 20, 2018, for U.S. Appl. No. 15/444,898, of Iyer, K, et al., filed Feb. 28, 2017. |
Final Office Action dated Jun. 15, 2018, for U.S. Appl. No. 14/461,146, of Kim, M., filed Aug. 15, 2014. |
Notice of Allowance dated Sep. 21, 2018, U.S. Appl. No. 14/184,590, of Dorogusker, J., et al., filed Feb. 19, 2014. |
Non-Final Office Action dated Sep. 28, 2018, for U.S. Appl. No. 15/444,898, of Iyer, K., et al., filed Feb. 28, 2017. |
Corrected Notice of Allowance dated Oct. 29, 2018, U.S. Appl. No. 14/184,590, of Dorogusker, J., et al., filed Feb. 19, 2014. |
Notice of Allowance dated Apr. 18, 2019, for U.S. Appl. No. 15/444,898, of Iyer, K., et al., filed Feb. 28, 2017. |
Number | Date | Country | |
---|---|---|---|
Parent | 14711120 | May 2015 | US |
Child | 15166822 | US |