Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
2. The Amendment filed January 12, 2026 has been entered. Claims 1-5, 9, 12-14, 17-19, and 22 are pending and are rejected for the reasons set forth below.
Claim Rejections - 35 USC § 103
3. 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 (i.e., changing from AIA to pre-AIA ) 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.
4. Claims 1-5, 9, 12-14, 17-19, and 22 is rejected under 35 U.S.C. 103 as being unpatentable over Smets(A) (U.S. Patent No. 10840975) in view of Smets(B) (U.S. Pre-Grant Publication No. 20210127436).
Claim 1
Regarding claim 1, Smets(A) teaches:
A method, comprising: determining, by a data originating device based at least in part on an indication received on a first communication channel, that a data receiving device supports a communication handover on a second communication channel for a data transfer (See at least Col. 10, Line 58 – Col. 11, Line 26: Describes a process for communicating between a merchant device [i.e., a data receiving device] and a consumer device [i.e., a data originating device]. For example, a second communication channel is established as part of a “tap” process. In this case, NFC [i.e., a first communication channel] is used to establish a Bluetooth connection [i.e., a second communication channel]. The second, Bluetooth, communication channel establishes interaction between the mPOS application on the merchant device and a merchant application on the consumer device);
providing on the first communication channel, by the data originating device to the data receiving device, an indication that the data originating device supports the communication handover on the second communication channel (See at least Col. 10, Line 58 – Col. 11, Line 26: The Bluetooth communication channel is established as part of the "tap" process. The NFC communication channel is used to establish the Bluetooth connection [i.e., the NFC connection provides an indication that communication channel should be "handed over" to the Bluetooth connection]); and
establishing, by the data originating device, the second communication channel between the data receiving device and the data originating device (See at least ol. 10, Line 58 – Col. 11, Line 26: The second, Bluetooth, communication channel establishes interaction between the mPOS application on the merchant device and the merchant application on the consumer device),
providing, by the data originating device to the data receiving device, an indication of a value data on the second communication channel (See at least Col. 10, Line 58 – Col. 11, Line 26: The user may elect to use a coupon [i.e., a value data]. This is communicated over the Bluetooth communication channel),
the value data to be utilized for a payment authorization of the operation for completion of the data transfer with a transfer value based at least in part on the value data and the initial value (See at least Col. 10, Line 58 – Col. 11, Line 26: The merchant device indicates that the coupon has been redeemed and that the total for the transaction has been reduced, and the consumer device indicates the new total and asks the user for authentication to complete the modified transaction. The transaction then completes as for a conventional contactless transaction [i.e., the transaction is completed based in part of the coupon value and the initial value of the transaction]).
Regarding claim 1, Smets(A) does not explicitly teach, but Smets(B), however, does teach:
performing, concurrently with establishment of the second communication channel or operations performed via the second communication channel, a payment loop of an operation for the data transfer, the payment loop performed with an initial value of the data transfer (See at least Paragraphs 83 and 84: Describes a system for initiating contactless communication sessions between computing devices using a variety of modalities. The system may determine whether there is a reason for "handover" from one communication modality to another to occur. If handover has occurred, the previous transaction data is discarded, or the authorization of the previous transaction data is reversed. In other words, a "payment loop" using the first communication modality is performed concurrently with the establishment of a second communication channel).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Smets(A) and Smets(B) in order to facilitate the use of multiple communication technologies together in an efficient manner (Smets(B): Paragraphs 2-5). Allowing the payment loop to occur concurrently with the establishment of the second communication channel provides the user greater control over the payment process.
Claim 2
Regarding claim 2, Smets(A) teaches:
wherein the communication handover on the second communication channel provides support for available services (See at least Col. 7, Lines 34-40: The second channel is used to perform an additional interaction using the communication technology. This approach allows the capabilities of the user smartphone to be utilized effectively to achieve a number of additional results, such as coupon redemption, user-initiated or controlled payment, and charity donation).
Claim 3
Regarding claim 3, Smets(A) teaches:
wherein the first communication channel supports communication within a first proximity, wherein the second communication channel supports communication within a second proximity, and wherein the first proximity is different from the second proximity (See at least Col. 10, Line 58 – Col. 11, Line 26: The system may utilize NFC for the first communication channel and Bluetooth for the second communication channel. Therefore, the proximity supported for each of the communication channels is different based on the communication means being implemented).
Claim 4
Regarding claim 4, Smets(A) teaches:
wherein the first communication channel implements first security, wherein the second communication channel implements second security, and wherein the first security is different from the second security (See at least Col. 10, Line 58 – Col. 11, Line 26: The system may utilize NFC for the first communication channel and Bluetooth for the second communication channel. Therefore, the security parameters for each of the communication channels is different based on the communication means being implemented).
Claim 5
Regarding claim 5, Smets(A) teaches:
wherein the first communication channel implements near field communication (NFC), and wherein the second communication channel implements a communication protocol different than the NFC (See at least Col. 10, Line 58 – Col. 11, Line 26: The first communication channel may be an NFC communication channel. The Bluetooth communication channel is established as part of the "tap" process. In other words, the NFC communication channel is used to establish the Bluetooth connection).
Claim 9
Regarding claim 9, Smets(A) teaches:
wherein the data originating device is functioning as a near field communication (NFC) payment device, and wherein the data receiving device is functioning as a point of sale (POS) device (See at least Col. 10, Line 58 – Col. 11, Line 26: The consumer device may be a smartphone with NFC capabilities. The merchant device may be a mobile POS terminal).
Claim 12
Regarding claim 12, Smets(A) teaches:
One or more non-transitory, computer-readable media having instructions stored thereon, wherein the instructions, when executed by one or more processors, cause a data originating device to: (See at least Col. 6, Lines 29-46: The user computing device possesses at least one processor and at least one memory, between them defining a computing environment for performance of applications)
determine, based at least in part on an indication received on a first communication channel, that a data receiving device supports a communication handover on a second communication channel for a data transfer (See at least Col. 10, Line 58 – Col. 11, Line 26: Describes a process for communicating between a merchant device [i.e., a data receiving device] and a consumer device [i.e., a data originating device]. For example, a second communication channel is established as part of a “tap” process. In this case, NFC [i.e., a first communication channel] is used to establish a Bluetooth connection [i.e., a second communication channel]. The second, Bluetooth, communication channel establishes interaction between the mPOS application on the merchant device and a merchant application on the consumer device);
provide, on the first communication channel to the data receiving device, an indication that the data originating device supports the communication handover on the second communication channel (See at least Col. 10, Line 58 – Col. 11, Line 26: The Bluetooth communication channel is established as part of the "tap" process. The NFC communication channel is used to establish the Bluetooth connection [i.e., the NFC connection provides an indication that communication channel should be "handed over" to the Bluetooth connection]);
establish the second communication channel between the data receiving device and the data originating device (See at least Col. 10, Line 58 – Col. 11, Line 26: The second, Bluetooth, communication channel establishes interaction between the mPOS application on the merchant device and the merchant application on the consumer device);
provide, to the data receiving device, an indication of a value data on the second communication channel (See at least Col. 10, Line 58 – Col. 11, Line 26: The user may elect to use a coupon [i.e., a value data]. This is communicated over the Bluetooth communication channel),
the value data to be utilized for a payment authorization for operation for completion of the data transfer with a transfer value based at least in part on the value data and the initial value (See at least Col. 10, Line 58 – Col. 11, Line 26: The merchant device indicates that the coupon has been redeemed and that the total for the transaction has been reduced, and the consumer device indicates the new total and asks the user for authentication to complete the modified transaction. The transaction then completes as for a conventional contactless transaction [i.e., the transaction is completed based in part of the coupon value and the initial value of the transaction]).
Regarding claim 12, Smets(A) does not explicitly teach, but Smets(B), however, does teach:
perform, concurrently with establishment of the second communication channel or operations performed via the second communication channel, a payment loop of an operation for the data transfer, the payment loop performed with an initial value of the data transfer (See at least Paragraphs 83 and 84: Describes a system for initiating contactless communication sessions between computing devices using a variety of modalities. The system may determine whether there is a reason for "handover" from one communication modality to another to occur. If handover has occurred, the previous transaction data is discarded, or the authorization of the previous transaction data is reversed. In other words, a "payment loop" using the first communication modality is performed concurrently with the establishment of a second communication channel).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Smets(A) and Smets(B) in order to facilitate the use of multiple communication technologies together in an efficient manner (Smets(B): Paragraphs 2-5). Allowing the payment loop to occur concurrently with the establishment of the second communication channel provides the user greater control over the payment process.
Claim 13
Regarding claim 13, Smets(A) teaches:
wherein the communication handover on the second communication channel provides support for available services (See at least Col. 7, Lines 34-40: The second channel is used to perform an additional interaction using the communication technology. This approach allows the capabilities of the user smartphone to be utilized effectively to achieve a number of additional results, such as coupon redemption, user-initiated or controlled payment, and charity donation).
Claim 14
Regarding claim 14, Smets(A) teaches:
wherein the first communication channel supports communication within a first proximity, wherein the second communication channel supports communication within a second proximity, and wherein the first proximity is different from the second proximity (See at least Col. 10, Line 58 – Col. 11, Line 26: The system may utilize NFC for the first communication channel and Bluetooth for the second communication channel. Therefore, the proximity supported for each of the communication channels is different based on the communication means being implemented).
Claim 17
Regarding claim 17, Smets(A) teaches:
A data originating device, comprising: memory to store value data; and one or more processors coupled to the memory, the processors to: (See at least Col. 6, Lines 29-46: The user computing device possesses at least one processor and at least one memory, between them defining a computing environment for performance of applications)
determine, based at least in part on an indication received on a first communication channel, that a data receiving device supports a communication handover on a second communication channel for a data transfer (See at least Col. 10, Line 58 – Col. 11, Line 26: Describes a process for communicating between a merchant device [i.e., a data receiving device] and a consumer device [i.e., a data originating device]. For example, a second communication channel is established as part of a “tap” process. In this case, NFC [i.e., a first communication channel] is used to establish a Bluetooth connection [i.e., a second communication channel]. The second, Bluetooth, communication channel establishes interaction between the mPOS application on the merchant device and a merchant application on the consumer device);
provide, on the first communication channel to the data receiving device, an indication that the data originating device supports the communication handover on the second communication channel (See at least Col. 10, Line 58 – Col. 11, Line 26: The Bluetooth communication channel is established as part of the "tap" process. The NFC communication channel is used to establish the Bluetooth connection [i.e., the NFC connection provides an indication that communication channel should be "handed over" to the Bluetooth connection]);
establish the second communication channel between the data receiving device and the data originating device (See at least Col. 10, Line 58 – Col. 11, Line 26: The second, Bluetooth, communication channel establishes interaction between the mPOS application on the merchant device and the merchant application on the consumer device);
provide, to the data receiving device, an indication of the value data on the second communication channel (See at least Col. 10, Line 58 – Col. 11, Line 26: The user may elect to use a coupon [i.e., a value data]. This is communicated over the Bluetooth communication channel),
the value data to be utilized for a payment authorization of the operation for completion of the data transfer with a transfer value based at least in part on the value data and the initial value (See at least Col. 10, Line 58 – Col. 11, Line 26: The merchant device indicates that the coupon has been redeemed and that the total for the transaction has been reduced, and the consumer device indicates the new total and asks the user for authentication to complete the modified transaction. The transaction then completes as for a conventional contactless transaction [i.e., the transaction is completed based in part of the coupon value]).
Regarding claim 17, Smets(A) does not explicitly teach, but Smets(B), however, does teach:
perform, concurrently with establishment of the second communication channel or operations performed via the second communication channel, a payment loop of an operation for the data transfer, the payment loop performed with an initial value of the data transfer (See at least Paragraphs 83 and 84: Describes a system for initiating contactless communication sessions between computing devices using a variety of modalities. The system may determine whether there is a reason for "handover" from one communication modality to another to occur. If handover has occurred, the previous transaction data is discarded, or the authorization of the previous transaction data is reversed. In other words, a "payment loop" using the first communication modality is performed concurrently with the establishment of a second communication channel).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Smets(A) and Smets(B) in order to facilitate the use of multiple communication technologies together in an efficient manner (Smets(B): Paragraphs 2-5). Allowing the payment loop to occur concurrently with the establishment of the second communication channel provides the user greater control over the payment process.
Claim 18
Regarding claim 18, Smets(A) teaches:
wherein the first communication channel implements first security, wherein the second communication channel implements second security, and wherein the first security is different from the second security (See at least Col. 10, Line 58 – Col. 11, Line 26: The system may utilize NFC for the first communication channel and Bluetooth for the second communication channel. Therefore, the security parameters for each of the communication channels is different based on the communication means being implemented).
Claim 19
Regarding claim 19, Smets(A) teaches:
wherein the one or more processors are further to: cause the data originating device to display a user input field for input of the value data for the data transfer; and identify the value data of the user input field received at the data originating device (See at least Col. 13, Lines 17-26: The consumer device may display an interface allowing the user to enter an amount for a charitable donation through the application. The amount to donate is identified by the application and sent to the merchant device for acceptance).
5. Claims 7 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Smets(A) (U.S. Patent No. 10840975) in view of Smets(B) (U.S. Pre-Grant Publication No. 20210127436), and in further view of Takayama (U.S. Pre-Grant Publication No. 20190109616) and Makhotin (U.S. Pre-Grant Publication No. 20150073996).
Claim 7
Regarding claim 7, the combination of Smets(A) and Smets(B) does not explicitly teach, but Takayama, however, does teach:
identifying, by the data originating device, a first key included in a selection handover message received from the data receiving device, [[the first key being a first elliptic curve cryptography (ECC) key]]; and providing, by the data originating device to the data receiving device, a handover response message that includes a second key, [[the second key being a second ECC key]], wherein the first ECC key and the second ECC key are utilized to establish the second communication channel (See at least Paragraphs 121-123: The initiator receives/identifies the NFC ID from the target to initiate the handover process. In response to receiving the NFC ID, the initiator exchanges the transaction ID and the transaction key with the target via a response message. These keys are used in the process of handing over the communication from an NFC communication channel to a different desired communication channel. Examiner's Note: Takayama does not explicitly teach that the "keys" are ECC keys. However, this limitation is disclosed by Makhotin as described below.).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Smets(A), Abrons, and Takayama in order to facilitate the handover of communication protocols during a transaction to take advantage of the benefits associated with different communication protocols, such as data transmission speed (Takayama: Paragraph 10). Utilizing keys to facilitate the communication handover process allows the system to authenticate the parties involved to endure that the data is transferred securely.
Regarding claim 7, the combination of Smets(A), Smets(B), and Takayama does not explicitly teach, but Makhotin, however, does teach:
identifying, by the data originating device, a first key included in a selection handover message received from the data receiving device, the first key being a first elliptic curve cryptography (ECC) key; and providing, by the data originating device to the data receiving device, a handover response message that includes a second key, the second key being a second ECC key, wherein the first ECC key and the second ECC key are utilized to establish the second communication channel (See at least Paragraph 34: Describes a system for providing a secure communication channel for completing payment transactions. The system may utilize a secure element key in order to form a secure communication channel. The keys may be generated with Elliptic Curve Cryptography).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Smets(A), Smets(B), Takayama, and Makhotin in order to facilitate the encryption/decryption of data transmitted between devices (Makhotin: Paragraph 34). Elliptic Curve Cryptography is simply one possible method of providing such cryptographic operations, as described by Makhotin.
Claim 21
Regarding claim 21, Smets(A) teaches:
wherein providing the indication that the data originating device supports the communication handover includes providing the indication that the data originating device supports the communication handover to one or more processors of the data receiving device, (See at least Col. 10, Line 58 – Col. 11, Line 26: The Bluetooth communication channel is established as part of the "tap" process. The NFC communication channel is used to establish the Bluetooth connection [i.e., the NFC connection provides an indication that communication channel should be "handed over" to the Bluetooth connection]), and
wherein the method further comprises: performing, by the data originating device, a data transfer operation with a [[secure element]] of the data receiving device to complete the data transfer (See at least Col. 10, Line 58 – Col. 11, Line 26: The user elects to use the coupon, and this is communicated over Bluetooth, with both terminals showing modified parameters for the transaction. The merchant device indicates that the coupon has been redeemed and that the total for the transaction has been reduced, and the consumer device indicates the new total and asks the user for authentication to complete the modified transaction [i.e., data regarding the transaction is communicated between the devices]. Examiner's Note: Smets(A) does not explicitly teach the use of a "secure element" to perform the data transfer operation. However, this limitation is disclosed by Makhotin as described below).
Regarding claim 21, the combination of Smets(A), Smets(B), and Takayama does not explicitly teach, but Makhotin, however, does teach:
wherein the method further comprises: performing, by the data originating device, a data transfer operation with a secure element of the data receiving device to complete the data transfer (See at least Paragraphs 33-35: Describes a system that utilizes a "secure element" to store and distribute payment information of a user. The secure element is highly secure such that only entities that have the permission of the secure element owner or secure element trusted service manager may communicate or access data on the secure element).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Smets(A), Smets(B), Takayama, and Makhotin in order to improve the security of data communication between devices by ensuring that only authorized entities have access to the data stored on the secure element (Makhotin: Paragraph 35).
6. Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Smets(A) (U.S. Patent No. 10840975) in view of Smets(B) (U.S. Pre-Grant Publication No. 20210127436), and in further view of Jones (U.S. Pre-Grant Publication No. 20070299914).
Claim 8
Regarding claim 8, the combination of Smets(A) and Smets(B) does not explicitly teach, but Jones, however, does teach:
wherein establishing the second communication channel is based at least in part on a session name and a password for the second communication channel (See at least Paragraph 27: Describes a system for facilitating collaborative sessions between computing devices. The user may enter a session name and password to be connected to the session [i.e., a communication channel is established between devices in response to receiving the session name and password]).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Smets(A), Smets(B), and Jones in order to provide a simple and intuitive mechanism for creating or joining a networked collaboration session (Jones: Paragraph 4).
7. Claims 11, 15, 16, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Smets(A) (U.S. Patent No. 10840975) in view of Smets(B) (U.S. Pre-Grant Publication No. 20210127436), and in further view of Lee (U.S. Patent No. 9799021).
Claim 11
Regarding claim 11, Smets(A) teaches:
wherein providing the indication that the data originating device supports the communication handover on the second communication channel includes providing, by the data originating device, an indication that the data originating device supports input of a [[tip amount]] for the data transfer at the data originating device (See at least Col. 13, Lines 17-26: The consumer device may display an interface allowing the user to enter an amount for a charitable donation through the application. The amount to donate is identified by the application and sent to the merchant device for acceptance Examiner’s Note: Smets(A) teaches a process for providing an indication that the data originating device supports an input of the value data, as described above. However, Smets(A) does not explicitly teach that the input comprises a tip amount. However, this limitation is taught by Lee, as described below)
Regarding claim 11, the combination of Smets(A) and Smets(B) does not explicitly teach, but Lee, however, does teach:
wherein providing the indication that the data originating device supports the communication handover on the second communication channel includes providing, by the data originating device, an indication that the data originating device supports input of a tip amount for the data transfer at the data originating device (See at least Col. 11, Lines 35-55: The user may be prompted to input a tip amount into their mobile device. The tip amount may be sent to the merchant POS system via a payment service system).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Smets(A), Smets(B), and Lee in order to reduce the time and effort required to provide tips when paying by credit card in a restaurant or other full-service retail establishment (Lee: Col. 1, Lines 12-38).
Claim 15
Regarding claim 15, Smets(A) teaches:
wherein to determine that the data receiving device supports the communication handover on the second communication channel includes to determine that the data receiving device supports input of a [[tip amount]] for the data transfer at the data originating device (See at least Col. 13, Lines 17-26: The consumer device may display an interface allowing the user to enter an amount for a charitable donation through the application. The amount to donate is identified by the application and sent to the merchant device for acceptance Examiner’s Note: Smets(A) teaches a process for providing an indication that the data originating device supports an input of the value data, as described above. However, Smets(A) does not explicitly teach that the input comprises a tip amount. However, this limitation is taught by Lee, as described below)
Regarding claim 15, the combination of Smets(A) and Smets(B) does not explicitly teach, but Lee, however, does teach:
wherein to determine that the data receiving device supports the communication handover on the second communication channel includes to determine that the data receiving device supports input of a tip amount for the data transfer at the data originating device (See at least Col. 11, Lines 35-55: The user may be prompted to input a tip amount into their mobile device. The tip amount may be sent to the merchant POS system via a payment service system).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Smets(A), Smets(B), and Lee in order to reduce the time and effort required to provide tips when paying by credit card in a restaurant or other full-service retail establishment (Lee: Col. 1, Lines 12-38).
Claim 16
Regarding claim 16, the combination of Smets(A) and Smets(B) does not explicitly teach, but Lee, however, does teach:
wherein the value data comprises a tip amount (See at least Col. 11, Lines 35-55: The user may be prompted to input a tip amount into their mobile device. The tip amount may be sent to the merchant POS system via a payment service system).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Smets(A), Smets(B), and Lee in order to reduce the time and effort required to provide tips when paying by credit card in a restaurant or other full-service retail establishment (Lee: Col. 1, Lines 12-38).
Claim 20
Regarding claim 20, the combination of Smets(A) and Smets(B) does not explicitly teach, but Lee, however, does teach:
wherein the one or more processors are further to: identify preliminary receipt data received from the data receiving device (See at least Col. 11, Lines 35-55: A virtual receipt is displayed to the customer by the customer’s mobile device); and
cause the data originating device to display the preliminary receipt data with the user input field (See at least Col. 11, Lines 35-55: The virtual receipt is displayed to the customer with a prompt to input a tip amount).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Smets(A), Smets(B), and Lee in order to reduce the time and effort required to provide tips when paying by credit card in a restaurant or other full-service retail establishment (Lee: Col. 1, Lines 12-38).
8. Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over Smets(A) (U.S. Patent No. 10840975) in view of Smets(B) (U.S. Pre-Grant Publication No. 20210127436), and in further view of Abrons (U.S. Patent No. 10636019).
Claim 22
Regarding claim 22, the combination of Smets(A) and Smets B does not explicitly teach, but Abrons, however, does teach:
wherein the payment loop is performed via the first communication channel, and wherein the payment authorization is performed after operations performed via the second communication channel (See at least Col. 13, Lines 1-25: Describes a system for tipping at a restaurant. The user may initially tender his/her credit card to complete payment for goods/services with a merchant [i.e., a payment loop with an initial value of the data transfer]. The payment object used to complete the transaction may include the mobile device comprising an NFC tag [i.e., a first communication channel associated with the data originating device, See Paragraph 29]. The user may then, after leaving the restaurant, use their mobile device to provide a tip [e.g., via a second communication channel]. The initial payment for goods/services [i.e., the payment loop] is performed before the user initiates the tipping process. The tip [e.g., credit card authorization of the tip] is directly sent to the payment system to be added together with the already authorized payment amount. In other words, authorization of the tipping transaction is performed after communication of the tipping amount to the payment system via the mobile device).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Smets(A), Smets(B), and Abrons in order to enable any tip selected or added by the customer to be directly transmitted to the payment system, without any human interference (Abrons: Col. 13, Lines 1-25). This allows tips to be provided without the merchant having to physically enter and submit the tip authorization, saving the merchant time. While Abrons does not explicitly recite the performance of a “payment loop” in the context of adding a coupon to a purchase, as described by Smets(A), it would have been obvious to one of ordinary skill in the art that the concepts described by Abrons (e.g., performing an initial transaction for an initial value before completing a second transaction via a different payment channel) could be applied to the processes described by Smets(A).
Response to Arguments
9. Applicant’s arguments filed January 12, 2026 have been fully considered.
Arguments Regarding 35 U.S.C. 102/103
10. Applicant’s arguments regarding the prior art rejections are moot in view of the new grounds of rejection necessitated by applicant’s claim amendments.
Citation of Pertinent Prior Art
11. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Tavakoli (U.S. Pre-Grant Publication No. 20190122201): Describes systems and methods for enabling payers to provide gratuities (or tips) to merchants. In some cases, prior to completing the transaction between the merchant and the payer, the system provides the payer the opportunity to elect to tip the merchant. The tip may be provided via a user interface on the user’s mobile device.
Kumar (U.S. Pre-Grant Publication No. 20160335630): Describes techniques for managing, supporting and empowering merchants in fighting frauds that are due to Card Not Present (CNP) situations. A Two-Way Handover occurs during the transmission of information from a desktop/server communicating to/with a smartphone/mobile device and then the smartphone/mobile device, automatically or as a result of action, transferring back information from the smartphone/mobile device and back to the desktop/server.
Conclusion
THIS ACTION IS MADE FINAL. 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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WILLIAM D NEWLON whose telephone number is (571)272-4407. The examiner can normally be reached Mon - Fri 8:30 - 4:30.
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, Matthew Gart can be reached at (571) 272-3955. 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.
/WILLIAM D NEWLON/Examiner, Art Unit 3696
/MATTHEW S GART/Supervisory Patent Examiner, Art Unit 3696
Prosecution Insights