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 .
Status of Claims
This action is in reply to the application filed on 06/28/2024.
Claims 1-20 are currently pending and have been examined.
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.
In the instant case, claims 1, 19 and 20 are directed to a method, system, and non-transitory computer-readable recording medium. For the purposes of this analysis, representative claim 1is addressed.
Claim 1 recites “pay request processing” which is a grouped under “Certain methods of organizing human activity — fundamental economic practices” in prong one of step 2A (MPEP 2106.04(a)). Claim 1 recites
A computer-implemented method for payment, comprising:
receiving a first instruction for selecting a first payment method for a first order on a first selection page by a target user;
displaying, in an interface of a merchant client device, an account confirmation page of a first wallet corresponding to the first payment method;
receiving a confirmation instruction sent by the target user based on the account confirmation page;
displaying a checkout page of the first wallet in the interface of the merchant client device;
receiving identity verification information entered by the target user based on the checkout page; and
displaying a first payment result page, wherein the first payment result page comprises at least a payment result corresponding to the first order.
The additional elements of claim 1 such as the various “page[s]” and “in an interface of a merchant client device”, represent the use of a computer as a tool to perform an abstract idea and/or does no more than generally link the abstract idea to a particular field of use (e.g. a web environment, with webpages and websites). Claims 19 and 20 recite additional elements CRM, computers, and computer memory devices, which are also considered a part of the web environment above.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration into a practical application, the additional elements amount to no more than mere instructions to apply the abstract idea of using generic computer components. The claim elements when considered separately and in an ordered combination, do not add significantly more than implementing the abstract idea of pay request processing.
Hence, claims 1, 19 and 20 are not patent eligible.
Dependent claims 2-18 recite additional details which only further narrow the abstract idea and do not add any additional features, alone or in combination, that would provide a practical application or provide significantly more.
Claim 2 recites the additional elements of “wherein the merchant client device is installed in a target device, and an application client device of the first wallet is not installed in the target device does no more than use a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. Therefore, as it is no more than apply it does not improve the functioning of a computer, or improve other technology or technical field.
The claims as a whole do not amount to significantly more than the abstract idea itself. This is because the claims do not affect an improvement to another technology or technical field, the claims do not amount to an improvement to the functioning of a computer system itself, and the claims do not move beyond a general link of the use of an abstract idea to a particular technological environment.
Accordingly, there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself.
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 (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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 2, 5-6, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over (Spector et al. (US 9195984 B1) in view of Chandrasekaran et al (US 2017/0171173 A1)
Regarding claims 1, 19 and 20
A computer-implemented method for payment, comprising: receiving a first instruction for selecting a first payment method for a first order on a first selection page by a target user; (See at least Spector (Col 24 lines 7-12) As shown in FIG. 6, the process starts in step 600 and passes to step 602. In step 602, the merchant system 210 displays their checkout page (which is integrated with the wallet 200) and the customer selects to pay with her wallet, which is displayed as an option on the merchant's checkout page.)
displaying a checkout page of the first wallet in the interface of the merchant client device; (See at least Spector (Col 24 lines 47-59) FIG. 9 is a diagram showing a smartphone with GUI 606′ illustrating the processing of step 606 including aspects of transaction confirmation, in accordance with one embodiment of the invention. As shown in FIG. 9, the GUI 606′ includes a “submit” button 902, as well as an option for the customer to “review purchase”, as illustrated by a hot link 904. Upon the customer reviewing the information presented by the GUI 606′, the customer taps the submit button 902 or in some other manner interfaces with the GUI 606′ to indicate that such information is correct and acceptable. It is appreciated that other functionality may be provided to the customer, i.e., in addition to the “submit” and “review purchase” options.)
receiving identity verification information entered by the target user based on the checkout page; and (See at least Spector (col 24 lines 22-33) FIG. 8 is a diagram showing a smartphone with GUI 604′ illustrating the processing of step 604. In step 604, the merchant interfaces with the wallet 200 using a suitable API. In conjunction with such interfacing, the wallet 200 is provided access so as to generate a dialog box 802 (shown in FIG. 8) on the user device (or on some interface that is presented to the customer). Specifically, the dialog box 802 interfaces with the customer to input a credential from the customer, such as a password. Accordingly, in this processing, control is transferred from the merchant over to the wallet 200, such that the wallet 200 may interface with the customer to secure some predetermined credential from the customer.)
displaying a first payment result page, wherein the first payment result page comprises at least a payment result corresponding to the first order. (See at least Spector (col 25 lines 2-8) Such further message may set forth various details of the transaction including the amount of the transaction, particulars of the account used to fund the transaction, as well as a suitable “thank you,” for example FIG. 10 is a diagram showing a smartphone with GUI 608′ illustrating the processing of step 608 including aspects of further transaction processing, in accordance with one embodiment of the invention.)
Spector does not specifically teach: displaying, in an interface of a merchant client device, an account confirmation page of a first wallet corresponding to the first payment message; receiving a confirmation instruction sent by the target user based on the account confirmation page;
However Chandrasekaran teaches: [0105] In block 650, the merchant point of sale device 130 operator selects an option on the merchant point of sale device 130 to initiate a transaction using the digital wallet application 113. In an example embodiment, the merchant POS device 130 displays a confirmation screen after the merchant POS device 130 operator selects an option to initiate a transaction using the digital wallet application 113. An example confirmation screen may further display options to confirm the transaction or cancel the transaction. In an example embodiment, the user 101 reviews the confirmation screen, determines that the information displayed on the confirmation screen is correct, determines to continue with the transaction, and directs the merchant POS device 130 operator to select the option to confirm the transaction via the user interface 135.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for processing transactions using a wallet of Spector with network security based on proximity as taught by Chandrasekara in order to complete a transaction at a merchant point of sale device using a heightened security.
Regarding claim 2
Spector does not specifically teach wherein the merchant client device is installed in a target device, and an application client device of the first wallet is not installed in the target device.
However, Chandrasekaran teaches: [0022] The user registers with the payment processing system and downloads a digital wallet application onto the user computing device [0046] An example merchant beacon device 120 comprises an antenna 122 and a Wi-Fi controller 125. In an example embodiment, a merchant system location comprises one or more merchant beacon devices 120 installed at the merchant system location. In an example embodiment, each installed merchant beacon device 120 is associated by a payment processing system 150 with a particular merchant point of sale device 130 installed at the merchant system location.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for processing transactions using a wallet of Spector view of with network security based on proximity as taught by Chandrasekara in order to complete a transaction at a merchant point of sale device using a user’s electronic wallet. (Chandrasekarat [0100])
Regarding claim 5
Spector does not specifically teach: wherein, using a first account, the merchant client device is logged into by the target user, and wherein the first account is not a login account of the first wallet.
However, Chandrasekaran teaches: [0105] In block 650, the merchant point of sale device 130 operator selects an option on the merchant point of sale device 130 to initiate a transaction using the digital wallet application 113. In an example embodiment, the merchant POS device 130 displays a confirmation screen after the merchant POS device 130 operator selects an option to initiate a transaction using the digital wallet application 113.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for processing transactions using a wallet of Spector view of with network security based on proximity as taught by Chandrasekara in order to complete a transaction at a merchant point of sale device using a user’s electronic wallet. (Chandrasekarat [0100])
Regarding claim 6
Spector does not specifically teach: wherein displaying, in an interface of a merchant client device, an account confirmation page of a first wallet corresponding to the first payment method, comprises: displaying a pre-collected payment account of the first wallet on the account confirmation page; or displaying an account input box for the first wallet on the account confirmation page, to receive a payment account entered by the target user based on the account input box.
However, Chandrasekaran teaches: [0106] In another example embodiment, the user 101 decides to abandon the transaction because the information is incorrect or because the user 101 changed his mind and decided not to purchase the items. In yet another example embodiment, the confirmation screen further comprises an option to edit the transaction details. In this example embodiment, the merchant POS device 130 operator, upon direction of the user 101, may select the option to edit the transaction details and may then edit, add, or delete one or more of the items in the transaction or edit payment details or payment methods for the transaction.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for processing transactions using a wallet of Spector view of with network security based on proximity as taught by Chandrasekara in order to complete a transaction at a merchant point of sale device using a user’s electronic wallet. (Chandrasekarat [0100])
Claims 3 and 4 are rejected under 35 U.S.C. 103 as being unpatentable over (Spector et al. (US 9195984 B1) in view of Chandrasekaran et al (US 2017/0171173 A1) and further in view of Wu (US 2022/0327536 A1)
Regarding claim 3
Spector does not specifically teach: The computer-implemented method of claim 1, wherein the account confirmation page and the checkout page are displayed in the interface of the merchant client device in a half page form by using a pop-up window or a floating layer.
However Wu teaches: [0061] For example, the application scenario for card account binding of the resource card is used as an example. As shown in FIG. 4, the user selects an adding mode of account addition without entering a card number in FIG. 4(a), a terminal page jumps to FIG. 4(b), the GS bank is selected in FIG. 4(b) as a bank of a to-be-bound account, and then the confirmation window pops up, as shown in FIG. 4(c). The user may select the OK button on the confirmation window to enter the gateway page, as shown in FIG. 4(d).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for processing transactions using a wallet of Spector view of the account binding method as taught by Wu in order to display information to the user.
Regarding claim 4
Spector does not specifically teach: wherein the account confirmation page and the checkout page each comprise a name and a design logo of the first wallet.
However, Wu teaches: [0061] For example, the application scenario for card account binding of the resource card is used as an example. As shown in FIG. 4, the user selects an adding mode of account addition without entering a card number in FIG. 4(a), a terminal page jumps to FIG. 4(b), the GS bank is selected in FIG. 4(b) as a bank of a to-be-bound account, and then the confirmation window pops up, as shown in FIG. 4(c). The user may select the OK button on the confirmation window to enter the gateway page, as shown in FIG. 4(d).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for processing transactions using a wallet of Spector view of the account binding method as taught by Wu in order to display information to the user.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over (Spector et al. (US 9195984 B1) in view of Chandrasekaran et al (US 2017/0171173 A1) and further in view of Thakkar et al. (US 2019/0386984 A1)
Regarding claim 7
Spector does not specifically teach: after receiving identity verification information entered by the target user based on the checkout page and before displaying a first payment result page: displaying a secondary confirmation interface of the first wallet in the interface of the merchant client device; and receiving identity verification information entered by the target user based on the secondary confirmation interface, wherein an identity verification manner corresponding to the secondary confirmation interface is different from an identity verification manner corresponding to the checkout page.
However Thakker teaches: [0030] System 100 includes a first user device 110, a second user device 130, and a transaction processor server 150, in communication over a network 170. A user (not shown) may utilize first user device 110 to engage in a transaction with an online merchant or other online entity (not shown) through an application executing on first user device 110. The user may select items for purchase and enter a checkout process with the merchant. The checkout process may allow for transaction processing using transaction processor server 150, which may utilize a two-factor authentication process that requires entry of an unknown and/or randomly generated password communicated to a known device of the user, such as second user device 130, in addition to a first authenticator, such as a known password or PIN. For example, the user may select a payment instrument in a digital wallet serviced by transaction processor server 150, where a financial entity associated with the payment instrument may require two-factor authentication through a one-time password. Second user device 130 may receive the one-time password, and may communicate with first user device 110 through audio communications to provide the one-time password to first user device 110. First user device 110 may then process the one-time password with the two-factor authentication process through the application processing the transaction. Transaction processor server 150 may receive the one-time password and/or communicate the one-time password to the financial entity associated with the payment instrument for processing.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for processing transactions using a wallet of Spector view of the two factor authentication as taught by Thakkar in order to receive secondary identity verification.
Claims 8-11 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over (Spector et al. (US 9195984 B1) in view of Chandrasekaran et al (US 2017/0171173 A1) and further in view of Xie (CN 112801660 A1)
Regarding claim 8
Spector does not specifically teach: receiving a second instruction sent by the target user based on the checkout page to instruct whether to subscribe to password-free payment.
However Xie teaches: (page 6 paragraph 15) before receiving the protocol subscription request sent by the application software terminal of the client, the bank client enters the mobile terminal application software clicking client, clicking to trigger the subscription operation of the payment protocol (i.e., without card). the mobile terminal application software the client terminal displays the password-free payment protocol subscription page;
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for processing transactions using a wallet of Spector view of the method for password free signing of payment protocol as taught by Xie in order to use password-free signing effectively reducing the interaction between the bank client and a plurality of system, improving the service transaction efficiency. (Xia (abstract))
Regarding claim 9
Spector does not specifically teach: the second instruction instructs to subscribe to password-free payment; and the first payment result page comprises a subscription result for password-free payment.
However Xie teaches: (page 9 paragraph 4) displays the subscription success page to the bank client through the mobile terminal of the application software client.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for processing transactions using a wallet of Spector view of the method for password free signing of payment protocol as taught by Xie in order to use password-free signing effectively reducing the interaction between the bank client and a plurality of system, improving the service transaction efficiency. (Xia (abstract))
Regarding claim 10
after the displaying a first payment result page: receiving a third instruction for selecting the first payment method for a second order on a second selection page by the target user; and (See at least Spector (Col 24 lines 7-12) As shown in FIG. 6, the process starts in step 600 and passes to step 602. In step 602, the merchant system 210 displays their checkout page (which is integrated with the wallet 200) and the customer selects to pay with her wallet, which is displayed as an option on the merchant's checkout page.))
Spector does not specifically teach: displaying a second payment result page, wherein the second payment result page comprises a payment result for the second order.
However, Chandrasekaran teaches: [0105] In block 650, the merchant point of sale device 130 operator selects an option on the merchant point of sale device 130 to initiate a transaction using the digital wallet application 113. In an example embodiment, the merchant POS device 130 displays a confirmation screen after the merchant POS device 130 operator selects an option to initiate a transaction using the digital wallet application 113.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for processing transactions using a wallet of Spector view of with network security based on proximity as taught by Chandrasekara in order to complete a transaction at a merchant point of sale device using a user’s electronic wallet. (Chandrasekarat [0100])
Chandrasekaran does not specifically teach: the subscription result indicates that subscription succeeds; and
However Xie teaches: (page 9 paragraph 4) displays the subscription success page to the bank client through the mobile terminal of the application software client.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for processing transactions using a wallet of Spector view of the method for password free signing of payment protocol as taught by Xie in order to use password-free signing effectively reducing the interaction between the bank client and a plurality of system, improving the service transaction efficiency. (Xia (abstract))
Regarding claim 11
Spector does not specifically teach: wherein the second payment result page is a next display page of the second selection page.
However Xie teaches: [0105] In block 650, the merchant point of sale device 130 operator selects an option on the merchant point of sale device 130 to initiate a transaction using the digital wallet application 113. In an example embodiment, the merchant POS device 130 displays a confirmation screen after the merchant POS device 130 operator selects an option to initiate a transaction using the digital wallet application 113.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for processing transactions using a wallet of Spector view of the method for password free signing of payment protocol as taught by Xie in order to use password-free signing effectively reducing the interaction between the bank client and a plurality of system, improving the service transaction efficiency. (Xia (abstract))
Regarding claim 13
wherein, after receiving a third instruction and before displaying a second payment result page: displaying a secondary confirmation interface of the first wallet in the interface of the merchant client device, wherein the secondary confirmation interface comprises a to-be-paid amount corresponding to the second order, and the to-be-paid amount is greater than a corresponding threshold; and (See at least Spector (Col 24 lines 42-59) After step 604 of FIG. 6, the process passes to step 606. In step 606, the merchant displays a confirmation screen showing the customer the address information that was received from the wallet, as well as purchase information, such as the amount of the purchase. Various other information may be presented to the customer for review, as desired. FIG. 9 is a diagram showing a smartphone with GUI 606′ illustrating the processing of step 606 including aspects of transaction confirmation, in accordance with one embodiment of the invention. As shown in FIG. 9, the GUI 606′ includes a “submit” button 902, as well as an option for the customer to “review purchase”, as illustrated by a hot link 904. Upon the customer reviewing the information presented by the GUI 606′, the customer taps the submit button 902 or in some other manner interfaces with the GUI 606′ to indicate that such information is correct and acceptable. It is appreciated that other functionality may be provided to the customer, i.e., in addition to the “submit” and “review purchase” options.)
receiving a payment confirmation operation sent by the target user based on the secondary confirmation interface. (See at least Spector (col 25 lines 2-8) Such further message may set forth various details of the transaction including the amount of the transaction, particulars of the account used to fund the transaction, as well as a suitable “thank you,” for example FIG. 10 is a diagram showing a smartphone with GUI 608′ illustrating the processing of step 608 including aspects of further transaction processing, in accordance with one embodiment of the invention.)
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over (Spector et al. (US 9195984 B1) in view of Chandrasekaran et al (US 2017/0171173 A1) and further in view of Xie (CN 112801660 A1) and Wu (US 2022/0327536 A1)
Regarding claim 12
Spector does not specifically teach: The computer-implemented method of claim 1, wherein the second selection page comprises a first selection area, the first payment method and a payment account of the first wallet are indicated in the first selection area, and the third instruction is sent by performing a triggering operation on the first selection area.
However Wu teaches: [0061] For example, the application scenario for card account binding of the resource card is used as an example. As shown in FIG. 4, the user selects an adding mode of account addition without entering a card number in FIG. 4(a), a terminal page jumps to FIG. 4(b), the GS bank is selected in FIG. 4(b) as a bank of a to-be-bound account, and then the confirmation window pops up, as shown in FIG. 4(c). The user may select the OK button on the confirmation window to enter the gateway page, as shown in FIG. 4(d).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for processing transactions using a wallet of Spector view of the account binding method as taught by Wu in order to display information to the user.
Claims 14-18 are rejected under 35 U.S.C. 103 as being unpatentable over (Spector et al. (US 9195984 B1) in view of Chandrasekaran et al (US 2017/0171173 A1) and further in view of Xie (CN 112801660 A1) and Tang et al. (US 2022/0027906 A1)
Regarding claim 14
Spector does not specifically teach: the second instruction instructs not to subscribe to password-free payment; and after the displaying a first payment result page: displaying, in the interface of the merchant client device, a recommendation page of the first wallet for biometric identity verification payment; receiving a subscription instruction initiated by the target user for biometric identity verification payment based on the recommendation page and biometric identity verification information; and displaying a subscription result page for biometric identity verification payment.
However Tang teaches:
the second instruction instructs not to subscribe to password-free payment; and after the displaying a first payment result page: displaying, in the interface of the merchant client device, a recommendation page of the first wallet for biometric identity verification payment; (See at least Tang [0055] Step S1042-6: Display prompt information to prompt the first user to subscribe to a biometric feature recognition payment service for the payment account.)
receiving a subscription instruction initiated by the target user for biometric identity verification payment based on the recommendation page and biometric identity verification information; and (See at least Tang [0058] Step S1042-8: Receive user identification information and biometric feature information of the first user sent by the first service terminal, where the user identification information and the biometric feature information are determined by the first service terminal based on a request sent by the first user for subscribing to a biometric feature recognition payment service.)
displaying a subscription result page for biometric identity verification payment. (See at least Tang [0059] After the subscription processing succeeds, the first service terminal sends subscription success information to the first user, and sends the biometric feature information and the user identification information of the first user to the IoT device.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for processing transactions using a wallet of Spector view of the payment processing method as taught by Tang in order to use biometric verification to verify payments.
Regarding claim 15
Spector does not specifically teach: it is indicated on the subscription result page that a subscription to biometric identity verification payment succeeds.
However, Tang teaches: [0059] After the subscription processing succeeds, the first service terminal sends subscription success information to the first user, and sends the biometric feature information and the user identification information of the first user to the IoT device.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for processing transactions using a wallet of Spector view of the payment processing method as taught by Tang in order to use biometric verification to verify payments.
Regarding claim 16
Spector does not specifically teach: after the displaying a subscription result page for biometric identity verification payment: receiving a fourth instruction for selecting the first payment method for a third order on a third selection page by the target user.
However, Tang teaches: [0037] Step S102: Determine payment information of a payment to be paid in response to a payment operation of a first user, and collect to-be-verified biometric feature information of the first user.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for processing transactions using a wallet of Spector view of the payment processing method as taught by Tang in order to use biometric verification to verify payments.
Regarding claim 17
Spector does not specifically teach: displaying a biometric identity verification page of the first wallet in the interface of the merchant client device, and receiving the biometric identity verification information entered by the target user based on the biometric identity verification page.
However, Tang teaches: [0039] It should be noted that the interaction between the first user and the IoT device is not limited to the previous examples, and can be configured depending on the need in actual practice. For example, the merchant can also operate the IoT device based on the product to be purchased by the first user, to enter product information, and the IoT device displays the product information entered by the merchant. After determining that the product information displayed by the IoT device is correct, the first user operates the payment control of the IoT device to pay the merchant corresponding to the IoT device for the selected product.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for processing transactions using a wallet of Spector view of the payment processing method as taught by Tang in order to use biometric verification to verify payments.
Regarding claim 18
displaying a third payment result page, wherein the third payment result page comprises a payment result for the third order. (See at least Spector (col 25 lines 2-8) Such further message may set forth various details of the transaction including the amount of the transaction, particulars of the account used to fund the transaction, as well as a suitable “thank you,” for example FIG. 10 is a diagram showing a smartphone with GUI 608′ illustrating the processing of step 608 including aspects of further transaction processing, in accordance with one embodiment of the invention.)
Prior Art of Record Not Currently Relied Upon
Lim (US 2016/0192123 A1) Teaches: Location dependent communications between mobile devices and transaction terminals.
Ran (US 2015/0317626 A1) Teaches: Secure proximity exchange of payment information between mobile wallet and point of sale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GREGORY MARK JAMES whose telephone number is (571)272-5155. The examiner can normally be reached M-F 8:30am - 5:00pm EST.
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, Ryan Donlon can be reached at 571-270-3602. 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.
/GREGORY M JAMES/Examiner, Art Unit 3692
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692 May 21, 2026
Prosecution Insights