DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Applicant filed a response dated October 28, 2025 in which claims 1-20 have been amended. Therefore, claims 1-20 are currently pending in the application.
Priority
Application 18/657,645 filed on 05/07/2024 is a CON of 15/581,972 04/28/2017.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 U.S.C. § 112(a) or § 112 1st paragraph issues that can arise when claims are amended without support in the specification. The Examiner thanks the Applicant in advance.
Double Patenting
The non-statutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. See In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) may be used to overcome an actual or provisional rejection based on a non-statutory double patenting ground provided the conflicting application or patent is shown to be commonly owned with this application. See 37 CFR 1.131(c). A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a non-statutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional, the reply must be complete. MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to MPEP 1490(V)(A).
Claims 1 and 10 are rejected on the ground of non-statutory double patenting as being unpatentable over claim 1 of US Patent No. 12,020,235 and claim 1 of US Patent No. 11,861,589.
Claims 1 and 10 of the instant application 18,657,645 are broader and fully encompasses the method steps of patent claim 1 of US Patent No. 12,020,235 and claim 1 of US Patent No. 11,861,589, except:
performing, by the first device, a rule-based exchange with the second device, wherein the exchange includes two concurrent exchanges including a first exchange of transaction information associated with the transaction with the transaction application of the second device over the second wireless communication channel, and a second exchange of background information with the background application of the second device over the first wireless communication channel;
determining, by the first device, one or more modifications to the transaction information based on the background information;
sending to the second device, by the first device, an offer to modify the transaction information based on the one or more modifications;
receiving, by the first device, a response indicating an acceptance of the offer from the second device;
As supported by the disclosure of Fernandes US20130015241 at paras. 170-172, 208-209, it was known in the art of multi-source payment transaction processing to provide for recommending an offer to modify transaction information and receiving a response to the offer from a user.
As supported by the disclosure of Landrok US20150142667 at paras. 34-36, it was known in the art of multi-source payment transaction processing to provide for exchanging transaction information concurrently and utilizing first and second wireless communication channels.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine the method steps of the 12,020,235 and 11,861,589 Patents with a step to modify the transaction information as known substitutions of one known element for another, and the resulting payment transaction means would have been predictable.
Additionally, Claim 19 is rejected on the ground of non-statutory double patenting as being unpatentable over claim 1 of US Patent No. 11,861,589.
Claim 19 of the instant application 18,657,645 is broader and fully encompasses the method steps of patent claim 1 of US Patent No. 11,861,589, except:
receiving, by the payment reader and concurrently with the transaction information, background information from a background application of the payment device,
sending to the payment device, by the payment reader, an offer to provide payment with a non-standard payment card based on the evaluating;
receiving, by the payment reader, an acceptance of the offer to provide the payment with the non-standard payment card from the payment device; and
processing, by the payment reader, a first portion of the payment transaction based on the transaction information and a second portion of the payment transaction based on the non-standard payment card.
As supported by the disclosure of Fernandes US20130015241 at paras. 3, 40, 151-160, 204-208, it was known in the art of multi-source payment transaction processing to provide for recommending an offer to modify transaction information and receiving a response to the offer from a user.
As supported by the disclosure of Landrok US20150142667 at paras. 34-36, it was known in the art of multi-source payment transaction processing to provide for exchanging transaction information concurrently.
As supported by the disclosure of Wall US20130046643 at paras. 46-50, it was known in the art of multi-source payment transaction processing to provide for processing a first portion and second portion of a payment transaction.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine the method steps of the 11,861,589 Patent with a step to modify the transaction information as known substitutions of one known element for another, and the resulting apportioned payment transaction means would have been predictable.
As to claims 1 and 10
Application 18/657,645
US Patent No. 11,861,589
US Patent No. 12,020,235
1. A method for a first device to process a transaction, the method comprising:
1. A method for a payment reader to process payment transactions, the method comprising:
1. A method for a payment reader to process a single payment transaction informed by communications between the payment reader and a payment device, the method comprising:
establishing, by the first device, a first wireless communication channel with a background application of a second device and a second wireless communication channel with a transaction application of the second device;
establishing, by the payment reader, between a near field communication (NFC) interface of the payment reader and an NFC interface of the payment device, first wireless communications with the payment device via the communication protocol that does not comply with a standard payment protocol;
performing, by the first device, a rule-based exchange with the second device, wherein the exchange includes two concurrent exchanges including a first exchange of transaction information associated with the transaction with the transaction application of the second device over the second wireless communication channel, and a second exchange of background information with the background application of the second device over the first wireless communication channel;
providing, by the payment reader via the first wireless communications, one or more request messages to the payment device;
receiving, with the NFC interface of the payment reader from the first application of the payment device via the first wireless communications, one or more information messages including the identifying information for the first account, wherein communication of the one or more information messages by the payment device is transparent to a user of the payment device;
determining, by the first device, one or more modifications to the transaction information based on the background information;
sending to the second device, by the first device, an offer to modify the transaction information based on the one or more modifications;
receiving, by the first device, a response indicating an acceptance of the offer from the second device;
determining, by the first device, at least one server to receive the transaction information based on the response from the second device; providing, from the first device, the transaction information to the at least one server for processing the transaction; and
providing, from the payment reader to a second remote server via one or more protocol communications that do not comply with the payment information standard, information for authorizing payment of a second portion of the payment transaction based on the identified payment card account;
receiving, at the first device, a response indicative of the processing of the transaction.
receiving, by the payment reader from the first remote server, approval of payment of the first portion of the payment transaction based on the standard payment card account; and
receiving, by the payment reader from the second remote server, approval of payment of the second portion of the payment transaction based on the identified payment card account.
As to claim 19
Application 18/657,645
US Patent No. 11,861,589
US Patent No. 12,020,235
19. A method for a payment reader to process a payment transaction, the method comprising:
1. A method for a payment reader to process payment transactions, the method comprising:
1. A method for a payment reader to process a single payment transaction informed by communications between the payment reader and a payment device, the method comprising:
receiving, by the payment reader, transaction information from a transaction application of a payment device, the transaction information complying with a standard payment protocol and includes a request to process the payment transaction with a standard payment card;
receiving, by the payment reader from a payment device via NFC, a first message complying with a standard payment protocol via a wireless communication connection established by inductive coupling when the payment device is placed within range of the payment reader, the first message being communicated via a first communication thread and including a request to process a payment transaction, the request being associated with a standard payment card account, wherein the payment device is one of a payment card or a mobile device;
receiving, by the payment reader and concurrently with the transaction information, background information from a background application of the payment device, the background information does not comply with the standard payment protocol and includes merchant information, payment information or item-specific loyalty information;
receiving, by the payment reader from the payment device via NFC via the wireless communication connection, a second message that does not comply with a standard payment protocol, the second message being communicated via a second communication thread separate from the first communication thread and including a list of one or more payment card types that do not comply with the standard payment protocol;
evaluating, by the payment reader, the background information from the background application of the payment device;
identifying, by the payment reader, from the list of one or more payment card types, a payment card account that does not comply with the standard payment protocol;
sending to the payment device, by the payment reader, an offer to provide payment with a non-standard payment card based on the evaluating;
receiving, by the payment reader, an acceptance of the offer to provide the payment with the non-standard payment card from the payment device; and
processing, by the payment reader, a first portion of the payment transaction based on the transaction information and a second portion of the payment transaction based on the non-standard payment card.
Claim Rejections - 35 USC § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. (MPEP 2106). The claims are directed to a method, system, and apparatus which is one of the statutory categories of invention (Step 1: YES). The recitation of the claimed invention is analyzed as follows, in which the abstract elements are boldfaced.
Claim 1 recites the limitations of:
A method for a first device to process a transaction, the method comprising: establishing, by the first device, a first wireless communication channel with a background application of a second device and a second wireless communication channel with a transaction application of the second device;
performing, by the first device, a rule-based exchange with the second device,
wherein the exchange includes two concurrent exchanges including a first exchange of transaction information associated with the transaction with the transaction application of the second device over the second wireless communication channel, and
a second exchange of background information with the background application of the second device over the first wireless communication channel;
determining, by the first device, one or more modifications to the transaction information based on the background information;
sending to the second device, by the first device, an offer to modify the transaction information based on the one or more modifications;
receiving, by the first device, a response indicating an acceptance of the offer from the second device;
determining, by the first device, at least one server to receive the transaction information based on the response from the second device;
providing, from the first device, the transaction information to the at least one server for processing the transaction; and
receiving, at the first device, a response indicative of the processing of the transaction.
Claim 19 recites the limitations of:
A method for a payment reader to process a payment transaction, the method comprising: receiving, by the payment reader, transaction information from a transaction application of a payment device, the transaction information complying with a standard payment protocol and includes a request to process the payment transaction with a standard payment card;
receiving, by the payment reader and concurrently with the transaction information, background information from a background application of the payment device,
the background information does not comply with the standard payment protocol and includes merchant information, payment information or item-specific loyalty information;
evaluating, by the payment reader, the background information from the background application of the payment device;
sending to the payment device, by the payment reader, an offer to provide payment with a non-standard payment card based on the evaluating;
receiving, by the payment reader, an acceptance of the offer to provide the payment with the non-standard payment card from the payment device; and
processing, by the payment reader, a first portion of the payment transaction based on the transaction information and a second portion of the payment transaction based on the non-standard payment card.
The claim as a whole recites a method that, under its broadest reasonable interpretation, covers collecting, analyzing, and transmitting data to facilitate the completion of a financial transaction. This is a fundamental economic practice of a financial transaction; a commercial interaction, such as for business relations; and managing personal behavior or relationships or interactions between people, which are certain methods of organizing human activity.
Thus, the claims recite an abstract idea. (Step 2A, prong 1: YES).
Moreover, the judicial exception is not integrated into a practical application. Other than reciting a “A method for a first device to process a transaction, the method comprising: establishing, by the first device, a first wireless communication channel with a background application of a second device and a second wireless communication channel with a transaction application of the second device", “at least one server”, “payment reader”, “transaction application”, “background application”, and “payment device”, to perform the steps of “performing”, “exchanging”, “determining”, “providing”, “processing”, and “evaluating”, nothing in the claim elements preclude the steps from practically being a certain method for organizing human activity. The claim as a whole does not integrate the judicial exception into a practical application. The claim merely describes how to generally “apply” the concept of collecting, analyzing, and transmitting data to facilitate the completion of a financial transaction in a computer environment. The additional computer elements recited in the claim limitations are recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception utilizing generic computer components.
For example, the Specification discloses “[0098] FIG. 5 depicts an exemplary merchant device 29 in accordance with some embodiments of the present disclosure. Although merchant device 29 may be implemented in a variety of device types, in one embodiment the merchant device 29 may be an interactive electronic device that provides a user interface and communicates with one or more other devices. Examples of interactive electronic devices include tablets, smart phones, smart watches, desktop computers, laptop computers, custom electronic devices, and other suitable electronic devices having the necessary user interface and communication capabilities to perform the functions described herein” and “[0100] In one embodiment, the merchant device 29 includes a processing unit 202 and memory 204 that are configured to control and perform the necessary operations of the merchant device 29. In one embodiment, the processing unit 202 of may be a general-purpose processor running instructions for a mobile operating system, programs, and applications based on instructions that may be stored in memory 204. The memory 204 may include any suitable memory types or combination thereof as described herein, such as flash memory and RAM memory, for storing instructions and other data and providing a working memory for the execution of the operating system, programs, and applications of the merchant device 29. In one embodiment, the memory 204 may include a plurality of sets of instructions, such as operating instructions 220, point-of-sale application instructions 222, and reader management instructions 224.”
Thus, the specification supports that general purpose computers or computer components are utilized to implement the steps of the abstract idea.
Merely implementing the abstract idea on a generic computer is not a practical application of the abstract idea. The claim as a whole, in viewing the additional elements both individually and in combination, does not integrate the judicial exception into a practical application. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea. (Step 2A prong two: No)
The claim does not include additional elements, when considered both individually and as an ordered combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using “A method for a first device to process a transaction, the method comprising: establishing, by the first device, a first wireless communication channel with a background application of a second device and a second wireless communication channel with a transaction application of the second device", “at least one server”, “payment reader”, “transaction application”, “background application”, and “payment device”, to perform the steps of “performing”, “exchanging”, “determining”, “providing”, “processing”, and “evaluating”, amounts to no more than mere instructions to apply the exception using generic computer component. The claim merely describes how to generally “apply” the concept of collecting, analyzing, and transmitting data to facilitate the completion of a financial transaction in a computer environment. Thus, even when viewed as a whole, nothing in the claim adds significantly more (i.e. an inventive concept) to the abstract idea. Such additional elements are determined to not contain an inventive concept according to MPEP 2106.05(f). It should be noted that (1) the “recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not provide significantly more because this type of recitation is equivalent to the words “apply it”, and (2) “Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice, commercial interaction, or managing personal behavior or relationships or interactions between people, mental process, or mathematical calculation) does not integrate a judicial exception into a practical application or provide significantly more”.
Claim 10 is substantially similar to claim 1, thus, it is rejected on similar grounds.
Claim 10 recites the additional elements of “A device for processing a payment transaction, the device comprising: a memory having instructions stored thereon; a processor coupled to the memory, wherein the processor is configured to execute the instructions to:”.
For similar reasons as explained above with regard to claim 1, under Step 2A, prong two, these additional elements are merely applying generic computer components to implement the abstract idea. Under Step 2B, when viewing the additional elements individually and in combination, the additional elements do not amount to an inventive concept amounting to significantly more than the judicial exception itself as the claimed computer-related technologies are mere tools for implementing the abstract idea as explained with regard to claim 1.
Dependent claims 2-9, 11-18, and 20 merely limit the abstract idea and do not recite any further additional elements beyond the cited abstract idea and the elements addressed above, thus, they do not amount to significantly more. The dependent claims are abstract for the reasons presented above because there are no additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination. Thus, the dependent claims are directed to an abstract idea. (Step 2B: No)
Therefore, claims 1-20 are not patent-eligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. §§ 102 and 103 (or as subject to pre-AIA 35 U.S.C. §§ 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. § 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-18 are rejected under 35 U.S.C. 103 as being unpatentable over Laracey, U.S. Patent Application Publication Number 2019/0347646; in view of Fernandes, U.S. Patent Application Publication Number 2013/0015241; in view of Landrok, U.S. Patent Application Publication Number 2015/0142667.
As per claim 1,
Laracey explicitly teaches:
a second wireless communication channel with a transaction application of the second device;
(Laracey US20190347646 at paras. 19-23) ("[0022] The mobile device 102 (under control of the payment application) may prompt the user to tap or present the mobile device 102 at an NFC reader 104 to continue the transaction. The NFC chip on the mobile device 102 causes information to be passed to the NFC reader 104 over NFC communication path 112. Such information includes, for example, the checkout token. In some embodiments, the checkout token is passed to the NFC reader 104 using a standard messaging protocol supported by the NFC reader 104. For example, the checkout token may be transmitted to the NFC reader 104 in a message data field used for the PAN, in a message data field used for track data, or in other data fields supported by the standard messaging protocol. [0023] In some embodiments, the message data captured by the NFC reader 104 is combined with transaction data collected by the merchant 108 and the merchant 108 creates a standard payment authorization (or other standard payment message) request message for transmission to a payment network 116. In some embodiments, the transaction data and the NFC message data are combined together in a single device, such as a desktop payment terminal like a Verifone VX570 or the like, a mobile point of sale device including devices that enable magnetic stripe and EMV transactions to be performed using a mobile device such as the devices from companies like PayPal®, Square®, and others, or a mobile device for person to person transactions, or the like.")
performing, by the first device, a rule-based exchange with the second device,
(Laracey US20190347646 at paras. 19-23, 74-78) ("[0076] The checkout token and other associated information may be presented to the point of sale device 212 using any one of the common NFC payment schemes, including the Visa Paywave scheme, the Mastercard PayPass scheme, the Discover Zip scheme, American Express' ExpressPay scheme, the Google Wallet scheme, or using the so-called “NFC Pass-through mode”, a mode for interacting with an NFC payment terminal where a mobile device can interact with a custom application on the payment terminal supporting Pass-through mode to facilitate data interchange between the mobile device and the payment terminal. Such an approach provides a number of desirable benefits. For example, when the NFC reader is activated it starts to poll for an NFC supported card or emulated card (e.g. mobile device) when the reader detects a card it will request an Application Identifier (AID) from the emulated card. When leveraging pass-through mode, the reader can receive an AID specifically assigned to the issuer of the payment application on the mobile device and the point of sale device 212 (or merchant systems) can drive specific business logic for the purposes of routing the data transmitted from the mobile device to the appropriate system. This approach can be used without impacting current schemes like PayWave, Zip, and PayPass as well. If the initial AID returned is not recognized, the NFC terminal will then fail over to one of the existing NFC schemes used for traditional NFC payments that may not be related to the scheme assigned to the payment application invoked by the user. In some embodiments, existing NFC schemes may be leveraged pursuant to the present invention by properly encoding the checkout token data and to create a mobile application that would pass an AID that is expected per the “common NFC schemes” listed above for the purposes of transmitting the checkout token data. By properly formatting the checkout token in this manner, the data can be made available to the appropriate system (POS, Switch, Payment Processor, etc) via an existing NFC scheme after read record event.")
including a first exchange of transaction information associated with the transaction with the transaction application of the second device over the second wireless communication channel, and
(Laracey US20190347646 at paras. 19-23) ("[0022] The mobile device 102 (under control of the payment application) may prompt the user to tap or present the mobile device 102 at an NFC reader 104 to continue the transaction. The NFC chip on the mobile device 102 causes information to be passed to the NFC reader 104 over NFC communication path 112. Such information includes, for example, the checkout token. In some embodiments, the checkout token is passed to the NFC reader 104 using a standard messaging protocol supported by the NFC reader 104. For example, the checkout token may be transmitted to the NFC reader 104 in a message data field used for the PAN, in a message data field used for track data, or in other data fields supported by the standard messaging protocol. [0023] In some embodiments, the message data captured by the NFC reader 104 is combined with transaction data collected by the merchant 108 and the merchant 108 creates a standard payment authorization (or other standard payment message) request message for transmission to a payment network 116. In some embodiments, the transaction data and the NFC message data are combined together in a single device, such as a desktop payment terminal like a Verifone VX570 or the like, a mobile point of sale device including devices that enable magnetic stripe and EMV transactions to be performed using a mobile device such as the devices from companies like PayPal®, Square®, and others, or a mobile device for person to person transactions, or the like.")
Laracey does not explicitly teach, however, Fernandes teaches:
determining, by the first device, one or more modifications to the transaction information based on the background information;
(Fernandes US20130015241 at paras. 3, 40, 151-160, 204-208) ("[0204] RF proximity chip card 2102 also includes second data type 2106 comprising information for a plurality of accounts other than those listed above. For example, second data type 2106 may include information for a plurality of accounts 2109a-c relating to members of merchant coalition(s). Data type 2106 includes specific codes 2111 flagging the coalition and the member of the coalition. [0205] FIG. 21 also shows a point-of-sale device including a contactless RF proximity chip card reader 2120. In the specific embodiment shown in FIG. 21, card reader 2120 is in electronic communication at the point of sale with a module 2121 including processor 2122. In alternative embodiments, the processor may be housed directly in the reader. Processor 2122 is configured to receive data from card 2102, and to recognize data types 2104 and 2106 present thereon. [0206] Based upon data types received and recognized from the coalition card, the processor is configured to negotiate a particular financial transaction with the card holder according to preferences, as described in detail above. For example, as shown in FIG. 22, when the coalition card 2102 is presented at a point of sale, the reader and the card can collaborate in a series of queries to determine the account to be used for that particular transaction and for that particular location. The processor may recognize and honor both a transaction type of the open-loop variety, and a transaction type of the closed-loop variety. Accordingly, the processor may be configured according to user preferences or merchant preferences, or a combination of both merchant preferences and user preferences, to automatically employ the closed-loop account data over the open-loop account data, querying the cardholder to manually override this default setting. Such a manual query is optional, however, and in accordance with other embodiments the transaction type could be decided by collaboration according to predefined preferences stored in the card and/or reader, without requiring manual action by the cardholder.")
sending to the second device, by the first device, an offer to modify the transaction information based on the one or more modifications;
(Fernandes US20130015241 at paras. 3, 40, 151-160, 204-208) ("[0206] Based upon data types received and recognized from the coalition card, the processor is configured to negotiate a particular financial transaction with the card holder according to preferences, as described in detail above. For example, as shown in FIG. 22, when the coalition card 2102 is presented at a point of sale, the reader and the card can collaborate in a series of queries to determine the account to be used for that particular transaction and for that particular location. The processor may recognize and honor both a transaction type of the open-loop variety, and a transaction type of the closed-loop variety. Accordingly, the processor may be configured according to user preferences or merchant preferences, or a combination of both merchant preferences and user preferences, to automatically employ the closed-loop account data over the open-loop account data, querying the cardholder to manually override this default setting. Such a manual query is optional, however, and in accordance with other embodiments the transaction type could be decided by collaboration according to predefined preferences stored in the card and/or reader, without requiring manual action by the cardholder. [0207] Based upon codes recognized from the card, and cardholder responses to queries posed by the reader, the processor can route the financial transaction information to the appropriate transaction processing system. Thus where data of the second type is not found, or where the cardholder accepts the reader's offer to manually select the conventional credit card account, the processor would be configured to route data from the card to one of the global, “open-loop” transaction processing networks 2165 and 2167 in the conventional manner.")
receiving, by the first device, a response indicating an acceptance of the offer from the second device;
(Fernandes US20130015241 at paras. 3, 40, 151-160, 204-208) ("[0206] Based upon data types received and recognized from the coalition card, the processor is configured to negotiate a particular financial transaction with the card holder according to preferences, as described in detail above. For example, as shown in FIG. 22, when the coalition card 2102 is presented at a point of sale, the reader and the card can collaborate in a series of queries to determine the account to be used for that particular transaction and for that particular location. The processor may recognize and honor both a transaction type of the open-loop variety, and a transaction type of the closed-loop variety. Accordingly, the processor may be configured according to user preferences or merchant preferences, or a combination of both merchant preferences and user preferences, to automatically employ the closed-loop account data over the open-loop account data, querying the cardholder to manually override this default setting. Such a manual query is optional, however, and in accordance with other embodiments the transaction type could be decided by collaboration according to predefined preferences stored in the card and/or reader, without requiring manual action by the cardholder. [0207] Based upon codes recognized from the card, and cardholder responses to queries posed by the reader, the processor can route the financial transaction information to the appropriate transaction processing system. Thus where data of the second type is not found, or where the cardholder accepts the reader's offer to manually select the conventional credit card account, the processor would be configured to route data from the card to one of the global, “open-loop” transaction processing networks 2165 and 2167 in the conventional manner.")
determining, by the first device, at least one server to receive the transaction information based on the response from the second device;
(Fernandes US20130015241 at paras. 170-172, 208-209) ("[0171] The Buyer's FDA application transmits the payment transaction request to the Merchant's adapter. A transaction code is generated by the PTD FDA application and adapter 35 upon confirmation by the transaction authorization center, or clearing house. The product or service is then provided to the Buyer. The transaction is reconciled and settlement actions completed by server 60, with notification to the FDA application, and posted on the User's server-based FDA application. [0172] Alternatively, two distinct FDA applications may be configured in Merchant and Buyer modes. In this instance, the Buyer or Merchant initiates the transaction request. Processes similar to the ones shown in the figures are performed to establish mutual authentication, secure data communications, and transaction event logging. [0173] In the on-line mode, the Merchant's adapter authenticates and authorizes the transaction via server 60. Transaction data is then transmitted to the Merchant and the Buyer. In off-line transactions, tokens issued by server 60 can be used. Reconciliation of the tokens to the Merchant can be effected in near real-time." "[0209] According to an even more useful embodiment, however, central server 2130 can be administered by a third party (such as ViVOtech), engaged by multiple coalitions to assist in implementing their specific closed-loop transaction processing infrastructures 2140 and 2142. Under this alternative embodiment, central server 2130 references codes transmitted from the reader with database 2134 to match up the transmitted data to a particular coalition infrastructure 2140 or 2142. Moreover, as the second data type may include a plurality of numbers designating different members of a coalition participating in the closed-loop transaction processing, processor 2122 and central server 2130 are also able to recognize transactions relating to particular members of a specific coalition for completion of the transaction.")
providing, from the first device, the transaction information to the at least one server for processing the transaction; and
(Fernandes US20130015241 at paras. 170-172) ("[0171] The Buyer's FDA application transmits the payment transaction request to the Merchant's adapter. A transaction code is generated by the PTD FDA application and adapter 35 upon confirmation by the transaction authorization center, or clearing house. The product or service is then provided to the Buyer. The transaction is reconciled and settlement actions completed by server 60, with notification to the FDA application, and posted on the User's server-based FDA application. [0172] Alternatively, two distinct FDA applications may be configured in Merchant and Buyer modes. In this instance, the Buyer or Merchant initiates the transaction request. Processes similar to the ones shown in the figures are performed to establish mutual authentication, secure data communications, and transaction event logging. [0173] In the on-line mode, the Merchant's adapter authenticates and authorizes the transaction via server 60. Transaction data is then transmitted to the Merchant and the Buyer. In off-line transactions, tokens issued by server 60 can be used. Reconciliation of the tokens to the Merchant can be effected in near real-time.")
receiving, at the first device, a response indicative of the processing of the transaction.
(Fernandes US20130015241 at paras. 170-172) ("[0171] The Buyer's FDA application transmits the payment transaction request to the Merchant's adapter. A transaction code is generated by the PTD FDA application and adapter 35 upon confirmation by the transaction authorization center, or clearing house. The product or service is then provided to the Buyer. The transaction is reconciled and settlement actions completed by server 60, with notification to the FDA application, and posted on the User's server-based FDA application. [0172] Alternatively, two distinct FDA applications may be configured in Merchant and Buyer modes. In this instance, the Buyer or Merchant initiates the transaction request. Processes similar to the ones shown in the figures are performed to establish mutual authentication, secure data communications, and transaction event logging. [0173] In the on-line mode, the Merchant's adapter authenticates and authorizes the transaction via server 60. Transaction data is then transmitted to the Merchant and the Buyer. In off-line transactions, tokens issued by server 60 can be used. Reconciliation of the tokens to the Merchant can be effected in near real-time.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Laracey and Fernandes, because it allows for improved techniques for conducting financial transactions that accommodate both the merchant's predefined preferences and the buyer's predefined preferences regarding financial transactions. (Fernandes at Abstract and paras. 2-12).
Laracey and Fernandes do not explicitly teach, however, Landrok teaches:
A method for a first device to process a transaction, the method comprising: establishing, by the first device, a first wireless communication channel with a background application of a second device and
(Landrok US20150142667 at paras. 34-36) (“[0034] A handshake signaling end-to-end between the user and the payment server allows both ends to understand what the other intends to be the main parameters of the transaction, e.g., the transaction value and merchant involved. Embodiments of the present invention therefore deploy a user transaction proxy server on the Internet Cloud that authenticates the users with two-channel handshakes involving passwords, confirmations, and even cryptographic calculations. Crypto-encoded credentials or keys issued by a bank, for example, are stored in the Internet Cloud in the user transaction proxy server and provided privately to the payment processor after user verification. The actual credentials or keys are generally not exposed to the users or the POS terminals they patronize. Some exposure may be required by particular payment schemes in order to compete a transaction. [0035] Each typical user will have several mobile devices they employ in their daily lives. Each of these can be supported by a variety of communications service providers, e.g., high speed Internet service, telephone, wireless mobile, email, and 4G packet networks, or even fax. Each of these are strongly associated with corresponding IP-addresses, email addresses, SIM cards, electronic serial number (ESN), international mobile equipment indicator (IMEI), subscriber phone numbers, etc. And each can support a message delivered to a single destination. [0036] A typical smartphone can log onto a webpage and receive emails simultaneously, e.g., by using two different communications channels and respective application programs. For purposes of the present invention, it is important that any of the communications channels and devices employed be available for contemporaneous, concurrent, or simultaneous use. The users' venues can change transaction-by-transaction, so the current device environment is important to understand so unavailable channels and devices can be predicted and no effort will be wasted on them. For example, at home or in their office, a user's fax machine could be a viable device using a hardwired fax line for the communications channel. But in a merchant's store, that would not be an option. However, the merchant's POS terminal could be employed as a device and channel between the user and the transaction proxy server.”)
wherein the exchange includes two concurrent exchanges
(Landrok US20150142667 at paras. 34-36) (“[0034] A handshake signaling end-to-end between the user and the payment server allows both ends to understand what the other intends to be the main parameters of the transaction, e.g., the transaction value and merchant involved. Embodiments of the present invention therefore deploy a user transaction proxy server on the Internet Cloud that authenticates the users with two-channel handshakes involving passwords, confirmations, and even cryptographic calculations. Crypto-encoded credentials or keys issued by a bank, for example, are stored in the Internet Cloud in the user transaction proxy server and provided privately to the payment processor after user verification. The actual credentials or keys are generally not exposed to the users or the POS terminals they patronize. Some exposure may be required by particular payment schemes in order to compete a transaction. [0035] Each typical user will have several mobile devices they employ in their daily lives. Each of these can be supported by a variety of communications service providers, e.g., high speed Internet service, telephone, wireless mobile, email, and 4G packet networks, or even fax. Each of these are strongly associated with corresponding IP-addresses, email addresses, SIM cards, electronic serial number (ESN), international mobile equipment indicator (IMEI), subscriber phone numbers, etc. And each can support a message delivered to a single destination. [0036] A typical smartphone can log onto a webpage and receive emails simultaneously, e.g., by using two different communications channels and respective application programs. For purposes of the present invention, it is important that any of the communications channels and devices employed be available for contemporaneous, concurrent, or simultaneous use. The users' venues can change transaction-by-transaction, so the current device environment is important to understand so unavailable channels and devices can be predicted and no effort will be wasted on them. For example, at home or in their office, a user's fax machine could be a viable device using a hardwired fax line for the communications channel. But in a merchant's store, that would not be an option. However, the merchant's POS terminal could be employed as a device and channel between the user and the transaction proxy server.”)
a second exchange of background information with the background application of the second device over the first wireless communication channel;
(Landrok US20150142667 at paras. 34-36) (“[0034] A handshake signaling end-to-end between the user and the payment server allows both ends to understand what the other intends to be the main parameters of the transaction, e.g., the transaction value and merchant involved. Embodiments of the present invention therefore deploy a user transaction proxy server on the Internet Cloud that authenticates the users with two-channel handshakes involving passwords, confirmations, and even cryptographic calculations. Crypto-encoded credentials or keys issued by a bank, for example, are stored in the Internet Cloud in the user transaction proxy server and provided privately to the payment processor after user verification. The actual credentials or keys are generally not exposed to the users or the POS terminals they patronize. Some exposure may be required by particular payment schemes in order to compete a transaction. [0035] Each typical user will have several mobile devices they employ in their daily lives. Each of these can be supported by a variety of communications service providers, e.g., high speed Internet service, telephone, wireless mobile, email, and 4G packet networks, or even fax. Each of these are strongly associated with corresponding IP-addresses, email addresses, SIM cards, electronic serial number (ESN), international mobile equipment indicator (IMEI), subscriber phone numbers, etc. And each can support a message delivered to a single destination. [0036] A typical smartphone can log onto a webpage and receive emails simultaneously, e.g., by using two different communications channels and respective application programs. For purposes of the present invention, it is important that any of the communications channels and devices employed be available for contemporaneous, concurrent, or simultaneous use. The users' venues can change transaction-by-transaction, so the current device environment is important to understand so unavailable channels and devices can be predicted and no effort will be wasted on them. For example, at home or in their office, a user's fax machine could be a viable device using a hardwired fax line for the communications channel. But in a merchant's store, that would not be an option. However, the merchant's POS terminal could be employed as a device and channel between the user and the transaction proxy server.”)
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Laracey, Fernandes, and Landrok, because it allows for improved mobile payments system that can bestow the benefits of chip card user authentication on consumers equipped with only common mobile devices that they use routinely in their daily lives and two independent and concurrent user communication channels connected to the network server are configured to receive user transaction requests on one user communication channel, and to enable the network server to make confirmations with said user on the other user communication channel. (Landrok at Abstract and paras. 2-19).
As per claim 2,
Laracey explicitly teaches:
wherein the transaction information includes a payment card type.
(Laracey US20190347646 at paras. 23-25) ("[0024] The payment network 116 (or an acquirer processor or other entity associated with the payment network 116), analyzes the request message and determines that the message should be routed to the transaction management system 130 (the system that issued the checkout token). This routing determination may be made at or by any of a number of different devices or entities, including, for example, at a payment terminal, at a retailer system (such as at the point of transaction, point of sale, or at a retailer payment switch), at a payment gateway, at a merchant processor system, at a payment network, or at a payment card issuer system (or any other system capable of reading information that would normally be passed on by the payment terminal to enable authorization of a payment transaction). In some embodiments, the routing determination may be made by the merchant system 109, e.g., by consulting a BIN table or other routing table and comparing values in a BIN table or other routing table to values in the checkout token or other data that is communicated from the mobile device 102 along with the checkout token to the merchant system 109.")
As per claim 3,
Laracey does not explicitly teach, however, Fernandes teaches:
wherein the offer is a prompt to provide payment with a second payment card type.
(Fernandes US20130015241 at paras. 55, 154-156) ("[0156] As another example, a merchant sets a preference 1507 to use any card for purchases or transactions of any amount. A buyer has set preferences 1508 that define specific dollar amount limits for transactions conducted using each of the buyer's soft cards. The negotiated preference 1509 implements both the buyer and the merchant preferences by automatically selecting a soft card after the user inputs an amount of the transaction. The selected soft card has a user set transaction limit that is greater than or equal to the transaction amount. If none of the user's soft cards have a large enough transaction limit, the user is prompted to select a soft card and to waive its transaction limit. Otherwise, the transaction is terminated.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Laracey, Fernandes, and Landrok, because it allows for improved techniques for conducting financial transactions that accommodate both the merchant's predefined preferences and the buyer's predefined preferences regarding financial transactions. (Fernandes at Abstract and paras. 2-12).
As per claim 4,
Laracey does not explicitly teach, however, Fernandes teaches:
wherein: the response includes receiving acceptance of the offer to provide payment with the second payment card type; and
(Fernandes US20130015241 at paras. 3, 40, 151-160, 204-208) ("[0206] Based upon data types received and recognized from the coalition card, the processor is configured to negotiate a particular financial transaction with the card holder according to preferences, as described in detail above. For example, as shown in FIG. 22, when the coalition card 2102 is presented at a point of sale, the reader and the card can collaborate in a series of queries to determine the account to be used for that particular transaction and for that particular location. The processor may recognize and honor both a transaction type of the open-loop variety, and a transaction type of the closed-loop variety. Accordingly, the processor may be configured according to user preferences or merchant preferences, or a combination of both merchant preferences and user preferences, to automatically employ the closed-loop account data over the open-loop account data, querying the cardholder to manually override this default setting. Such a manual query is optional, however, and in accordance with other embodiments the transaction type could be decided by collaboration according to predefined preferences stored in the card and/or reader, without requiring manual action by the cardholder. [0207] Based upon codes recognized from the card, and cardholder responses to queries posed by the reader, the processor can route the financial transaction information to the appropriate transaction processing system. Thus where data of the second type is not found, or where the cardholder accepts the reader's offer to manually select the conventional credit card account, the processor would be configured to route data from the card to one of the global, “open-loop” transaction processing networks 2165 and 2167 in the conventional manner.")
the transaction information is associated with the second payment card type.
(Fernandes US20130015241 at paras. 170-172, 208-209) ("[0171] The Buyer's FDA application transmits the payment transaction request to the Merchant's adapter. A transaction code is generated by the PTD FDA application and adapter 35 upon confirmation by the transaction authorization center, or clearing house. The product or service is then provided to the Buyer. The transaction is reconciled and settlement actions completed by server 60, with notification to the FDA application, and posted on the User's server-based FDA application. [0172] Alternatively, two distinct FDA applications may be configured in Merchant and Buyer modes. In this instance, the Buyer or Merchant initiates the transaction request. Processes similar to the ones shown in the figures are performed to establish mutual authentication, secure data communications, and transaction event logging. [0173] In the on-line mode, the Merchant's adapter authenticates and authorizes the transaction via server 60. Transaction data is then transmitted to the Merchant and the Buyer. In off-line transactions, tokens issued by server 60 can be used. Reconciliation of the tokens to the Merchant can be effected in near real-time." "[0209] According to an even more useful embodiment, however, central server 2130 can be administered by a third party (such as ViVOtech), engaged by multiple coalitions to assist in implementing their specific closed-loop transaction processing infrastructures 2140 and 2142. Under this alternative embodiment, central server 2130 references codes transmitted from the reader with database 2134 to match up the transmitted data to a particular coalition infrastructure 2140 or 2142. Moreover, as the second data type may include a plurality of numbers designating different members of a coalition participating in the closed-loop transaction processing, processor 2122 and central server 2130 are also able to recognize transactions relating to particular members of a specific coalition for completion of the transaction.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Laracey, Fernandes, and Landrok, because it allows for improved techniques for conducting financial transactions that accommodate both the merchant's predefined preferences and the buyer's predefined preferences regarding financial transactions. (Fernandes at Abstract and paras. 2-12).
As per claim 5,
Laracey does not explicitly teach, however, Fernandes teaches:
wherein the offer is at least one of a promotion, a discount, or a loyalty incentive to be used in association with the processing of the transaction.
(Fernandes US20130015241 at paras. 55, 154-156) ("[0156] As another example, a merchant sets a preference 1507 to use any card for purchases or transactions of any amount. A buyer has set preferences 1508 that define specific dollar amount limits for transactions conducted using each of the buyer's soft cards. The negotiated preference 1509 implements both the buyer and the merchant preferences by automatically selecting a soft card after the user inputs an amount of the transaction. The selected soft card has a user set transaction limit that is greater than or equal to the transaction amount. If none of the user's soft cards have a large enough transaction limit, the user is prompted to select a soft card and to waive its transaction limit. Otherwise, the transaction is terminated.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Laracey, Fernandes, and Landrok, because it allows for improved techniques for conducting financial transactions that accommodate both the merchant's predefined preferences and the buyer's predefined preferences regarding financial transactions. (Fernandes at Abstract and paras. 2-12).
As per claim 6,
Laracey and Fernandes do not explicitly teach, however, Landrok teaches:
wherein establishing the first wireless communication channel with the background application includes receiving, by the first device, a message from the background application of the second device.
(Landrok US20150142667 at paras. 34-36) (“[0034] A handshake signaling end-to-end between the user and the payment server allows both ends to understand what the other intends to be the main parameters of the transaction, e.g., the transaction value and merchant involved. Embodiments of the present invention therefore deploy a user transaction proxy server on the Internet Cloud that authenticates the users with two-channel handshakes involving passwords, confirmations, and even cryptographic calculations. Crypto-encoded credentials or keys issued by a bank, for example, are stored in the Internet Cloud in the user transaction proxy server and provided privately to the payment processor after user verification. The actual credentials or keys are generally not exposed to the users or the POS terminals they patronize. Some exposure may be required by particular payment schemes in order to compete a transaction. [0035] Each typical user will have several mobile devices they employ in their daily lives. Each of these can be supported by a variety of communications service providers, e.g., high speed Internet service, telephone, wireless mobile, email, and 4G packet networks, or even fax. Each of these are strongly associated with corresponding IP-addresses, email addresses, SIM cards, electronic serial number (ESN), international mobile equipment indicator (IMEI), subscriber phone numbers, etc. And each can support a message delivered to a single destination. [0036] A typical smartphone can log onto a webpage and receive emails simultaneously, e.g., by using two different communications channels and respective application programs. For purposes of the present invention, it is important that any of the communications channels and devices employed be available for contemporaneous, concurrent, or simultaneous use. The users' venues can change transaction-by-transaction, so the current device environment is important to understand so unavailable channels and devices can be predicted and no effort will be wasted on them. For example, at home or in their office, a user's fax machine could be a viable device using a hardwired fax line for the communications channel. But in a merchant's store, that would not be an option. However, the merchant's POS terminal could be employed as a device and channel between the user and the transaction proxy server.”)
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Laracey, Fernandes, and Landrok, because it allows for improved mobile payments system that can bestow the benefits of chip card user authentication on consumers equipped with only common mobile devices that they use routinely in their daily lives and two independent and concurrent user communication channels connected to the network server are configured to receive user transaction requests on one user communication channel, and to enable the network server to make confirmations with said user on the other user communication channel. (Landrok at Abstract and paras. 2-19).
As per claim 7,
Laracey and Fernandes do not explicitly teach, however, Landrok teaches:
wherein establishing the first wireless communication channel with the background application further includes providing, by the first device, a response to the message from the background application, wherein the response indicates that the first device is enabled to process the single transaction with the background application.
(Landrok US20150142667 at paras. 34-36) (“[0034] A handshake signaling end-to-end between the user and the payment server allows both ends to understand what the other intends to be the main parameters of the transaction, e.g., the transaction value and merchant involved. Embodiments of the present invention therefore deploy a user transaction proxy server on the Internet Cloud that authenticates the users with two-channel handshakes involving passwords, confirmations, and even cryptographic calculations. Crypto-encoded credentials or keys issued by a bank, for example, are stored in the Internet Cloud in the user transaction proxy server and provided privately to the payment processor after user verification. The actual credentials or keys are generally not exposed to the users or the POS terminals they patronize. Some exposure may be required by particular payment schemes in order to compete a transaction. [0035] Each typical user will have several mobile devices they employ in their daily lives. Each of these can be supported by a variety of communications service providers, e.g., high speed Internet service, telephone, wireless mobile, email, and 4G packet networks, or even fax. Each of these are strongly associated with corresponding IP-addresses, email addresses, SIM cards, electronic serial number (ESN), international mobile equipment indicator (IMEI), subscriber phone numbers, etc. And each can support a message delivered to a single destination. [0036] A typical smartphone can log onto a webpage and receive emails simultaneously, e.g., by using two different communications channels and respective application programs. For purposes of the present invention, it is important that any of the communications channels and devices employed be available for contemporaneous, concurrent, or simultaneous use. The users' venues can change transaction-by-transaction, so the current device environment is important to understand so unavailable channels and devices can be predicted and no effort will be wasted on them. For example, at home or in their office, a user's fax machine could be a viable device using a hardwired fax line for the communications channel. But in a merchant's store, that would not be an option. However, the merchant's POS terminal could be employed as a device and channel between the user and the transaction proxy server.”)
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Laracey, Fernandes, and Landrok, because it allows for improved mobile payments system that can bestow the benefits of chip card user authentication on consumers equipped with only common mobile devices that they use routinely in their daily lives and two independent and concurrent user communication channels connected to the network server are configured to receive user transaction requests on one user communication channel, and to enable the network server to make confirmations with said user on the other user communication channel. (Landrok at Abstract and paras. 2-19).
As per claim 8,
Laracey explicitly teaches:
wherein the background information includes merchant information, payment information, or item-specific loyalty information.
(Laracey US20190347646 at paras. 19-23, 75-77, 106-108) ("[0022] The mobile device 102 (under control of the payment application) may prompt the user to tap or present the mobile device 102 at an NFC reader 104 to continue the transaction. The NFC chip on the mobile device 102 causes information to be passed to the NFC reader 104 over NFC communication path 112. Such information includes, for example, the checkout token. In some embodiments, the checkout token is passed to the NFC reader 104 using a standard messaging protocol supported by the NFC reader 104. For example, the checkout token may be transmitted to the NFC reader 104 in a message data field used for the PAN, in a message data field used for track data, or in other data fields supported by the standard messaging protocol. [0023] In some embodiments, the message data captured by the NFC reader 104 is combined with transaction data collected by the merchant 108 and the merchant 108 creates a standard payment authorization (or other standard payment message) request message for transmission to a payment network 116. In some embodiments, the transaction data and the NFC message data are combined together in a single device, such as a desktop payment terminal like a Verifone VX570 or the like, a mobile point of sale device including devices that enable magnetic stripe and EMV transactions to be performed using a mobile device such as the devices from companies like PayPal®, Square®, and others, or a mobile device for person to person transactions, or the like." "[0076] The checkout token and other associated information may be presented to the point of sale device 212 using any one of the common NFC payment schemes, including the Visa Paywave scheme, the Mastercard PayPass scheme, the Discover Zip scheme, American Express' ExpressPay scheme, the Google Wallet scheme, or using the so-called “NFC Pass-through mode”, a mode for interacting with an NFC payment terminal where a mobile device can interact with a custom application on the payment terminal supporting Pass-through mode to facilitate data interchange between the mobile device and the payment terminal. Such an approach provides a number of desirable benefits. For example, when the NFC reader is activated it starts to poll for an NFC supported card or emulated card (e.g. mobile device) when the reader detects a card it will request an Application Identifier (AID) from the emulated card. When leveraging pass-through mode, the reader can receive an AID specifically assigned to the issuer of the payment application on the mobile device and the point of sale device 212 (or merchant systems) can drive specific business logic for the purposes of routing the data transmitted from the mobile device to the appropriate system. This approach can be used without impacting current schemes like PayWave, Zip, and PayPass as well. If the initial AID returned is not recognized, the NFC terminal will then fail over to one of the existing NFC schemes used for traditional NFC payments that may not be related to the scheme assigned to the payment application invoked by the user. In some embodiments, existing NFC schemes may be leveraged pursuant to the present invention by properly encoding the checkout token data and to create a mobile application that would pass an AID that is expected per the “common NFC schemes” listed above for the purposes of transmitting the checkout token data. By properly formatting the checkout token in this manner, the data can be made available to the appropriate system (POS, Switch, Payment Processor, etc) via an existing NFC scheme after read record event.")
As per claim 9,
Laracey does not explicitly teach, however, Fernandes teaches:
wherein the at least one server is a first server and the method further comprises: determining, by the first device, a second server to receive the background information based on the response from the second device;
(Fernandes US20130015241 at paras. 170-172, 208-209) ("[0171] The Buyer's FDA application transmits the payment transaction request to the Merchant's adapter. A transaction code is generated by the PTD FDA application and adapter 35 upon confirmation by the transaction authorization center, or clearing house. The product or service is then provided to the Buyer. The transaction is reconciled and settlement actions completed by server 60, with notification to the FDA application, and posted on the User's server-based FDA application. [0172] Alternatively, two distinct FDA applications may be configured in Merchant and Buyer modes. In this instance, the Buyer or Merchant initiates the transaction request. Processes similar to the ones shown in the figures are performed to establish mutual authentication, secure data communications, and transaction event logging. [0173] In the on-line mode, the Merchant's adapter authenticates and authorizes the transaction via server 60. Transaction data is then transmitted to the Merchant and the Buyer. In off-line transactions, tokens issued by server 60 can be used. Reconciliation of the tokens to the Merchant can be effected in near real-time." "[0209] According to an even more useful embodiment, however, central server 2130 can be administered by a third party (such as ViVOtech), engaged by multiple coalitions to assist in implementing their specific closed-loop transaction processing infrastructures 2140 and 2142. Under this alternative embodiment, central server 2130 references codes transmitted from the reader with database 2134 to match up the transmitted data to a particular coalition infrastructure 2140 or 2142. Moreover, as the second data type may include a plurality of numbers designating different members of a coalition participating in the closed-loop transaction processing, processor 2122 and central server 2130 are also able to recognize transactions relating to particular members of a specific coalition for completion of the transaction.")
providing, from the first device, the background information to the second server; and
(Fernandes US20130015241 at paras. 170-172) ("[0171] The Buyer's FDA application transmits the payment transaction request to the Merchant's adapter. A transaction code is generated by the PTD FDA application and adapter 35 upon confirmation by the transaction authorization center, or clearing house. The product or service is then provided to the Buyer. The transaction is reconciled and settlement actions completed by server 60, with notification to the FDA application, and posted on the User's server-based FDA application. [0172] Alternatively, two distinct FDA applications may be configured in Merchant and Buyer modes. In this instance, the Buyer or Merchant initiates the transaction request. Processes similar to the ones shown in the figures are performed to establish mutual authentication, secure data communications, and transaction event logging. [0173] In the on-line mode, the Merchant's adapter authenticates and authorizes the transaction via server 60. Transaction data is then transmitted to the Merchant and the Buyer. In off-line transactions, tokens issued by server 60 can be used. Reconciliation of the tokens to the Merchant can be effected in near real-time.")
receiving, at the first device, a response from the second server related to the background information.
(Fernandes US20130015241 at paras. 170-172) ("[0171] The Buyer's FDA application transmits the payment transaction request to the Merchant's adapter. A transaction code is generated by the PTD FDA application and adapter 35 upon confirmation by the transaction authorization center, or clearing house. The product or service is then provided to the Buyer. The transaction is reconciled and settlement actions completed by server 60, with notification to the FDA application, and posted on the User's server-based FDA application. [0172] Alternatively, two distinct FDA applications may be configured in Merchant and Buyer modes. In this instance, the Buyer or Merchant initiates the transaction request. Processes similar to the ones shown in the figures are performed to establish mutual authentication, secure data communications, and transaction event logging. [0173] In the on-line mode, the Merchant's adapter authenticates and authorizes the transaction via server 60. Transaction data is then transmitted to the Merchant and the Buyer. In off-line transactions, tokens issued by server 60 can be used. Reconciliation of the tokens to the Merchant can be effected in near real-time.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Laracey, Fernandes, and Landrok, because it allows for improved techniques for conducting financial transactions that accommodate both the merchant's predefined preferences and the buyer's predefined preferences regarding financial transactions. (Fernandes at Abstract and paras. 2-12).
Claims 10-18 are substantially similar to claims 1-9, thus, they are rejected on similar grounds.
Claims 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Laracey, U.S. Patent Application Publication Number 2019/0347646; in view of Landrok, U.S. Patent Application Publication Number 2015/0142667; in view of Fernandes, U.S. Patent Application Publication Number 2013/0015241, in view of Wall, U.S. Patent Application Publication Number 2013/0046643.
As per claim 19,
Laracey explicitly teaches:
A method for a payment reader to process a payment transaction, the method comprising: receiving, by the payment reader, transaction information from a transaction application of a payment device, the transaction information complying with a standard payment protocol and includes a request to process the payment transaction with a standard payment card;
(Laracey US20190347646 at paras. 19-23) ("[0022] The mobile device 102 (under control of the payment application) may prompt the user to tap or present the mobile device 102 at an NFC reader 104 to continue the transaction. The NFC chip on the mobile device 102 causes information to be passed to the NFC reader 104 over NFC communication path 112. Such information includes, for example, the checkout token. In some embodiments, the checkout token is passed to the NFC reader 104 using a standard messaging protocol supported by the NFC reader 104. For example, the checkout token may be transmitted to the NFC reader 104 in a message data field used for the PAN, in a message data field used for track data, or in other data fields supported by the standard messaging protocol. [0023] In some embodiments, the message data captured by the NFC reader 104 is combined with transaction data collected by the merchant 108 and the merchant 108 creates a standard payment authorization (or other standard payment message) request message for transmission to a payment network 116. In some embodiments, the transaction data and the NFC message data are combined together in a single device, such as a desktop payment terminal like a Verifone VX570 or the like, a mobile point of sale device including devices that enable magnetic stripe and EMV transactions to be performed using a mobile device such as the devices from companies like PayPal®, Square®, and others, or a mobile device for person to person transactions, or the like.")
the background information does not comply with the standard payment protocol and includes merchant information, payment information or item-specific loyalty information;
(Laracey US20190347646 at paras. 19-23, 74-78) ("[0076] The checkout token and other associated information may be presented to the point of sale device 212 using any one of the common NFC payment schemes, including the Visa Paywave scheme, the Mastercard PayPass scheme, the Discover Zip scheme, American Express' ExpressPay scheme, the Google Wallet scheme, or using the so-called “NFC Pass-through mode”, a mode for interacting with an NFC payment terminal where a mobile device can interact with a custom application on the payment terminal supporting Pass-through mode to facilitate data interchange between the mobile device and the payment terminal. Such an approach provides a number of desirable benefits. For example, when the NFC reader is activated it starts to poll for an NFC supported card or emulated card (e.g. mobile device) when the reader detects a card it will request an Application Identifier (AID) from the emulated card. When leveraging pass-through mode, the reader can receive an AID specifically assigned to the issuer of the payment application on the mobile device and the point of sale device 212 (or merchant systems) can drive specific business logic for the purposes of routing the data transmitted from the mobile device to the appropriate system. This approach can be used without impacting current schemes like PayWave, Zip, and PayPass as well. If the initial AID returned is not recognized, the NFC terminal will then fail over to one of the existing NFC schemes used for traditional NFC payments that may not be related to the scheme assigned to the payment application invoked by the user. In some embodiments, existing NFC schemes may be leveraged pursuant to the present invention by properly encoding the checkout token data and to create a mobile application that would pass an AID that is expected per the “common NFC schemes” listed above for the purposes of transmitting the checkout token data. By properly formatting the checkout token in this manner, the data can be made available to the appropriate system (POS, Switch, Payment Processor, etc) via an existing NFC scheme after read record event.")
Laracey does not explicitly teach, however, Fernandes teaches:
evaluating, by the payment reader, the background information from the background application of the payment device;
(Fernandes US20130015241 at paras. 3, 40, 151-160, 204-208) ("[0204] RF proximity chip card 2102 also includes second data type 2106 comprising information for a plurality of accounts other than those listed above. For example, second data type 2106 may include information for a plurality of accounts 2109a-c relating to members of merchant coalition(s). Data type 2106 includes specific codes 2111 flagging the coalition and the member of the coalition. [0205] FIG. 21 also shows a point-of-sale device including a contactless RF proximity chip card reader 2120. In the specific embodiment shown in FIG. 21, card reader 2120 is in electronic communication at the point of sale with a module 2121 including processor 2122. In alternative embodiments, the processor may be housed directly in the reader. Processor 2122 is configured to receive data from card 2102, and to recognize data types 2104 and 2106 present thereon. [0206] Based upon data types received and recognized from the coalition card, the processor is configured to negotiate a particular financial transaction with the card holder according to preferences, as described in detail above. For example, as shown in FIG. 22, when the coalition card 2102 is presented at a point of sale, the reader and the card can collaborate in a series of queries to determine the account to be used for that particular transaction and for that particular location. The processor may recognize and honor both a transaction type of the open-loop variety, and a transaction type of the closed-loop variety. Accordingly, the processor may be configured according to user preferences or merchant preferences, or a combination of both merchant preferences and user preferences, to automatically employ the closed-loop account data over the open-loop account data, querying the cardholder to manually override this default setting. Such a manual query is optional, however, and in accordance with other embodiments the transaction type could be decided by collaboration according to predefined preferences stored in the card and/or reader, without requiring manual action by the cardholder.")
sending to the payment device, by the payment reader, an offer to provide payment with a non-standard payment card based on the evaluating;
(Fernandes US20130015241 at paras. 3, 40, 151-160, 204-208) ("[0206] Based upon data types received and recognized from the coalition card, the processor is configured to negotiate a particular financial transaction with the card holder according to preferences, as described in detail above. For example, as shown in FIG. 22, when the coalition card 2102 is presented at a point of sale, the reader and the card can collaborate in a series of queries to determine the account to be used for that particular transaction and for that particular location. The processor may recognize and honor both a transaction type of the open-loop variety, and a transaction type of the closed-loop variety. Accordingly, the processor may be configured according to user preferences or merchant preferences, or a combination of both merchant preferences and user preferences, to automatically employ the closed-loop account data over the open-loop account data, querying the cardholder to manually override this default setting. Such a manual query is optional, however, and in accordance with other embodiments the transaction type could be decided by collaboration according to predefined preferences stored in the card and/or reader, without requiring manual action by the cardholder. [0207] Based upon codes recognized from the card, and cardholder responses to queries posed by the reader, the processor can route the financial transaction information to the appropriate transaction processing system. Thus where data of the second type is not found, or where the cardholder accepts the reader's offer to manually select the conventional credit card account, the processor would be configured to route data from the card to one of the global, “open-loop” transaction processing networks 2165 and 2167 in the conventional manner.")
receiving, by the payment reader, an acceptance of the offer to provide the payment with the non-standard payment card from the payment device; and
(Fernandes US20130015241 at paras. 3, 40, 151-160, 204-208) ("[0206] Based upon data types received and recognized from the coalition card, the processor is configured to negotiate a particular financial transaction with the card holder according to preferences, as described in detail above. For example, as shown in FIG. 22, when the coalition card 2102 is presented at a point of sale, the reader and the card can collaborate in a series of queries to determine the account to be used for that particular transaction and for that particular location. The processor may recognize and honor both a transaction type of the open-loop variety, and a transaction type of the closed-loop variety. Accordingly, the processor may be configured according to user preferences or merchant preferences, or a combination of both merchant preferences and user preferences, to automatically employ the closed-loop account data over the open-loop account data, querying the cardholder to manually override this default setting. Such a manual query is optional, however, and in accordance with other embodiments the transaction type could be decided by collaboration according to predefined preferences stored in the card and/or reader, without requiring manual action by the cardholder. [0207] Based upon codes recognized from the card, and cardholder responses to queries posed by the reader, the processor can route the financial transaction information to the appropriate transaction processing system. Thus where data of the second type is not found, or where the cardholder accepts the reader's offer to manually select the conventional credit card account, the processor would be configured to route data from the card to one of the global, “open-loop” transaction processing networks 2165 and 2167 in the conventional manner.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Laracey and Fernandes, because it allows for improved techniques for conducting financial transactions that accommodate both the merchant's predefined preferences and the buyer's predefined preferences regarding financial transactions. (Fernandes at Abstract and paras. 2-12).
Laracey and Fernandes do not explicitly teach, however, Landrok teaches:
receiving, by the payment reader and concurrently with the transaction information, background information from a background application of the payment device,
(Landrok US20150142667 at paras. 34-36) (“[0034] A handshake signaling end-to-end between the user and the payment server allows both ends to understand what the other intends to be the main parameters of the transaction, e.g., the transaction value and merchant involved. Embodiments of the present invention therefore deploy a user transaction proxy server on the Internet Cloud that authenticates the users with two-channel handshakes involving passwords, confirmations, and even cryptographic calculations. Crypto-encoded credentials or keys issued by a bank, for example, are stored in the Internet Cloud in the user transaction proxy server and provided privately to the payment processor after user verification. The actual credentials or keys are generally not exposed to the users or the POS terminals they patronize. Some exposure may be required by particular payment schemes in order to compete a transaction. [0035] Each typical user will have several mobile devices they employ in their daily lives. Each of these can be supported by a variety of communications service providers, e.g., high speed Internet service, telephone, wireless mobile, email, and 4G packet networks, or even fax. Each of these are strongly associated with corresponding IP-addresses, email addresses, SIM cards, electronic serial number (ESN), international mobile equipment indicator (IMEI), subscriber phone numbers, etc. And each can support a message delivered to a single destination. [0036] A typical smartphone can log onto a webpage and receive emails simultaneously, e.g., by using two different communications channels and respective application programs. For purposes of the present invention, it is important that any of the communications channels and devices employed be available for contemporaneous, concurrent, or simultaneous use. The users' venues can change transaction-by-transaction, so the current device environment is important to understand so unavailable channels and devices can be predicted and no effort will be wasted on them. For example, at home or in their office, a user's fax machine could be a viable device using a hardwired fax line for the communications channel. But in a merchant's store, that would not be an option. However, the merchant's POS terminal could be employed as a device and channel between the user and the transaction proxy server.”)
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Laracey, Fernandes, and Landrok, because it allows for improved mobile payments system that can bestow the benefits of chip card user authentication on consumers equipped with only common mobile devices that they use routinely in their daily lives and two independent and concurrent user communication channels connected to the network server are configured to receive user transaction requests on one user communication channel, and to enable the network server to make confirmations with said user on the other user communication channel. (Landrok at Abstract and paras. 2-19).
Laracey, Fernandes, and Landrok do not explicitly teach, however, Wall teaches:
processing, by the payment reader, a first portion of the payment transaction based on the transaction information and a second portion of the payment transaction based on the non-standard payment card.
(Wall US20130046643 at paras. 46-50) ("[0047] The device reader 115 processes the selected value-added service options, calculates the total of the purchase transaction, and communicates the total to the contactless device 120 in block 450. In an exemplary embodiment, the device reader 115 applies any coupons, loyalty rewards, membership card information, other discounts, or other transaction actions and adjusts the purchase price accordingly. Although described throughout this specification as the reader 110 performing specific functions, such functions may be performed by the application 118 and/or the POS terminal 110 and communicated to the device 120 via the reader 115.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Laracey, Fernandes, Landrok, and Wall, because it allows for an improved method of allowing point of sale processing and communication of multiple user options with a single initiation of a contactless transaction comprises a device reader that facilitates a secure and convenient connection with a contactless device. (Wall at Abstract and paras. 2-6).
As per claim 20,
Laracey explicitly teaches:
further comprising: providing, by the payment reader, a response to the background application, wherein the response indicates that the payment reader is enabled to process the payment transaction with the background application.
(Laracey US20190347646 at paras. 19-23, 75-77, 106-108) ("[0022] The mobile device 102 (under control of the payment application) may prompt the user to tap or present the mobile device 102 at an NFC reader 104 to continue the transaction. The NFC chip on the mobile device 102 causes information to be passed to the NFC reader 104 over NFC communication path 112. Such information includes, for example, the checkout token. In some embodiments, the checkout token is passed to the NFC reader 104 using a standard messaging protocol supported by the NFC reader 104. For example, the checkout token may be transmitted to the NFC reader 104 in a message data field used for the PAN, in a message data field used for track data, or in other data fields supported by the standard messaging protocol. [0023] In some embodiments, the message data captured by the NFC reader 104 is combined with transaction data collected by the merchant 108 and the merchant 108 creates a standard payment authorization (or other standard payment message) request message for transmission to a payment network 116. In some embodiments, the transaction data and the NFC message data are combined together in a single device, such as a desktop payment terminal like a Verifone VX570 or the like, a mobile point of sale device including devices that enable magnetic stripe and EMV transactions to be performed using a mobile device such as the devices from companies like PayPal®, Square®, and others, or a mobile device for person to person transactions, or the like." "[0076] The checkout token and other associated information may be presented to the point of sale device 212 using any one of the common NFC payment schemes, including the Visa Paywave scheme, the Mastercard PayPass scheme, the Discover Zip scheme, American Express' ExpressPay scheme, the Google Wallet scheme, or using the so-called “NFC Pass-through mode”, a mode for interacting with an NFC payment terminal where a mobile device can interact with a custom application on the payment terminal supporting Pass-through mode to facilitate data interchange between the mobile device and the payment terminal. Such an approach provides a number of desirable benefits. For example, when the NFC reader is activated it starts to poll for an NFC supported card or emulated card (e.g. mobile device) when the reader detects a card it will request an Application Identifier (AID) from the emulated card. When leveraging pass-through mode, the reader can receive an AID specifically assigned to the issuer of the payment application on the mobile device and the point of sale device 212 (or merchant systems) can drive specific business logic for the purposes of routing the data transmitted from the mobile device to the appropriate system. This approach can be used without impacting current schemes like PayWave, Zip, and PayPass as well. If the initial AID returned is not recognized, the NFC terminal will then fail over to one of the existing NFC schemes used for traditional NFC payments that may not be related to the scheme assigned to the payment application invoked by the user. In some embodiments, existing NFC schemes may be leveraged pursuant to the present invention by properly encoding the checkout token data and to create a mobile application that would pass an AID that is expected per the “common NFC schemes” listed above for the purposes of transmitting the checkout token data. By properly formatting the checkout token in this manner, the data can be made available to the appropriate system (POS, Switch, Payment Processor, etc) via an existing NFC scheme after read record event.")
Response to Arguments
Applicant’s arguments filed on October 28, 2025 have been fully considered but are not persuasive for the following reasons:
With respect to Applicant’s arguments as to the § 101 rejections for now pending claims 1-20, Examiner notes the following:
Applicant argues that the claims are not directed to an abstract idea.
Examiner disagrees, however, and notes that the claim as a whole recites a method that, under its broadest reasonable interpretation, covers collecting, analyzing, and transmitting data to facilitate the completion of a financial transaction. This is a fundamental economic practice of a financial transaction; a commercial interaction, such as for business relations; and managing personal behavior or relationships or interactions between people, which are certain methods of organizing human activity.
Thus, the claims recite an abstract idea.
Applicant argues that the claims integrate the abstract idea into a practical application, the examiner respectfully disagrees. In particular, the applicant argues that “This dual-channel, rule-based coordination improves how electronic devices communicate during contactless or near-field transactions. The improvement addresses technical latency, concurrency, and synchronization issues in mobile payment systems-not a business rule or human activity.”
Examiner notes that, the stated problems of inefficiencies and inadequate synchronization is not a technical problem, and the claimed solution is not a technical solution. In the claim, the solution of rule-based exchange of transaction information is part of the abstract idea, as it is merely involves data collecting, analysis, and transmission to facilitate the completion of a financial transaction. Furthermore, the data manipulation and analysis could be completed mentally or manually by paper or pen.
With respect to Applicant’s arguments as to the Double Patenting rejections for now pending claims 1-20, Examiner notes that the arguments are moot in light of the new grounds for rejection.
With respect to Applicant’s arguments as to the § 103 rejections for now pending claims 1-20, Examiner notes that the arguments are moot in light of the new grounds for rejection.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is available for review on Form PTO-892 Notice of References Cited.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MERRITT J HASBROUCK whose telephone number is (571)272-3109. The examiner can normally be reached M-F 9:00-5:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christine Tran can be reached on 571-272-8103. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MERRITT J HASBROUCK/Examiner, Art Unit 3695
/CHRISTINE M Tran/Supervisory Patent Examiner, Art Unit 3695