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
Applicant’s submission filed 11/22/24 has been entered. Claims 1-20 are presented for examination.
Claim Rejections - 35 USC § 103
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-3, 5,7, 10, 11-13, 15, 17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over DING et al. (US 20200134601 A1).
Re-claim 1, Ding et al. teach --A payment method, applied to a client of a payment application, wherein the method comprises:
--receiving a wake-up instruction, wherein a manner of initiating the wake-up instruction comprises: reading, by a mobile device in which the client is located, a short-range wireless communication tag of a payee to obtain a corresponding code value, sending the wake-up instruction to the client, and providing the code value;
(see e.g. [0246] The first terminal and a second terminal establish an NFC connection and perform a radio frequency discovery process.
[0247] During the radio frequency discovery process in this step, the second terminal may detect whether the first terminal supports an NFC tag protocol. In other words, the second terminal may detect whether the first terminal has an NFC tag. Once an NFC tag is detected, the following step 1003 is performed to continue processing.
[0248] The first terminal receives a request message for NFC tag reading sent by the second terminal.
[0251] The first terminal sends a response message to the second terminal, where the response message carries content encapsulated in the NFC tag.)
--obtaining related information of the payee based on the code value in response to the wake-up instruction;
(see e. g. [0254] Specifically, when information carried in the NFC tag includes the identifier of the target third-party payment application, the second terminal directly determines, based on the identifier, to forward the information to the target third-party payment application corresponding to the identifier for processing; and then starts the target third-party payment application.)
--in a case in which current payment belongs to large payment, triggering, based on the related information, a server of the payment application to obtain a dynamic code of the payee and
(see e.g. [0266] Optionally, when a payment amount is relatively large, the server of the target third-party payment application sends identity authentication information to the first terminal, for example, delivers an authentication code, or enters a payment password or a fingerprint. After the identity authentication succeeds, the server of the target third-party payment application performs fund transfer.
[0130] Optionally, whether the first terminal performs user identity authentication is determined by the first terminal based on an amount of this transaction. When the transaction amount is relatively large and exceeds a given quota, the user is prompted to perform identity authentication.
[0296] An identity authentication manner includes authenticating a fingerprint, entering a specific password, entering a specific authentication code, and the like.
******In another embodiment, Ding et al. teach ----[0180] Alternatively, the first terminal may perform security processing only on some information in the preset-format response message, such as the payment risk authentication information.
(see e.g. [0181] Manner 1: The first terminal calculates a digest (for example, calculates a hash value) for the information carried in the preset-format response information, and encrypts the calculated digest by using a private key of the target third-party payment application, to obtain a signature. Then, the first terminal encapsulates the foregoing information and the signature into the preset-format response message, and may also encapsulate a public key certificate of the target third-party payment application into the preset-format response message. Certainly, the first terminal may alternatively encrypt the foregoing information and the signature by using a public key of the second terminal or a symmetric key negotiated by the two terminals, encapsulate the encrypted foregoing information and signature into the response message, and send the response message to the second terminal.)
--perform corresponding large payment processing based on the dynamic code of the payee; and
(see e.g. [0296] After the first terminal performs user identity authentication, the second terminal performs the following step 1011c to send an identity authentication result to the server of the target third-party payment application.
[0299] 1012c. After the user identity authentication succeeds, the server of the target third-party payment application performs fund transfer.)
--receiving a payment result returned by the server.
(see e.g. [0315] Optionally, the display 1402 is further configured to display second prompt information, where the second prompt information is used to inform the user that the NFC payment has been completed.)
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Ding et al., and include the second embodiment, in order to determine a payment risk (see e.g. [0256]).
Re-claim 2, DIng et al. teach --The method according to claim 1, wherein the short-range wireless communication tag comprises: the dynamic code of the payee generated or applied for by the payee and dynamically updated and written into the short-range wireless communication tag; and --
(see e.g. [0251] The first terminal sends a response message to the second terminal, where the response message carries content encapsulated in the NFC tag.
[0236] 1001. A first terminal generates a preset-format response message based on payment information of the target third-party payment application, and encapsulates the preset-format response message into an NFC tag.)
--triggering, based on the related information, the server of the payment application to obtain a dynamic code of the payee and perform corresponding large payment processing based on the dynamic code of the payee specifically comprises:
--determining the dynamic code of the payee based on a result of reading the short-range wireless communication tag; and
(see e.g. [0250] Because the first terminal encapsulates the payment making information of the first terminal and other possible information into the NFC tag, the second terminal sends the request message to the first terminal, where the request message is used to read the NFC tag generated by the first terminal.
[0251] The first terminal sends a response message to the second terminal, where the response message carries content encapsulated in the NFC tag.)
--interacting with the server of the payment application based on the related information and the dynamic code of the payee, so the server obtains the dynamic code of the payee and performs corresponding large payment processing based on the dynamic code of the payee.
(see e.g. [0254] Specifically, when information carried in the NFC tag includes the identifier of the target third-party payment application, the second terminal directly determines, based on the identifier, to forward the information to the target third-party payment application corresponding to the identifier for processing; and then starts the target third-party payment application.
[0255] It can be understood that the information in the NFC tag is directly forwarded to a corresponding function of the target third-party payment application for processing. )
Re-claim 3, Ding et al. anticipate ---The method according to claim 1, wherein triggering, based on the related information, the server of the payment application to obtain a dynamic code of the payee and perform corresponding large payment processing based on the dynamic code of the payee specifically comprises:
--initiating payment to the server of the payment application based on the related information, so the server generates or applies for a dynamic code from another service provider as the dynamic code of the payee, and gives a prompt to the client; and
(see e.g. [0181] Manner 1: The first terminal calculates a digest (for example, calculates a hash value) for the information carried in the preset-format response information, and encrypts the calculated digest by using a private key of the target third-party payment application, to obtain a signature. Then, the first terminal encapsulates the foregoing information and the signature into the preset-format response message, and may also encapsulate a public key certificate of the target third-party payment application into the preset-format response message. Certainly, the first terminal may alternatively encrypt the foregoing information and the signature by using a public key of the second terminal or a symmetric key negotiated by the two terminals, encapsulate the encrypted foregoing information and signature into the response message, and send the response message to the second terminal.)
***The Examiner notes in order to calculate the digest, either a public key certificate of the target third-party payment application or a public key of the second terminal can be used. Therefore, the digest (encrypted information and a signature ) can be generated from different service providers.
-- receiving corresponding confirmation of a payer on the client, and triggering, based on a result of the corresponding confirmation, the server to continue to perform corresponding large payment processing based on the dynamic code of the payee.
(see e.g. [0186] Certainly, if a user of the second terminal is a payer, a risk prompt message may be directly displayed to the user of the second terminal, and a subsequent process continues to be performed after the user agrees.)
Re-claim 5, Ding et al. teach --The method according to claim 1, wherein before triggering, based on the related information, the server of the payment application to obtain a dynamic code of the payee and perform corresponding large payment processing based on the dynamic code of the payee, the method further comprises:
-- displaying a payment amount input page; and --receiving a large payment amount, not less than a specified amount threshold, inputted by a payer through the payment amount input page to establish that the current payment belongs to large payment.
(see e.g. [0109] The display unit 370 may be configured to display information entered by the user, information provided for the user, and various menus of the mobile phone 300.
[0183] Optionally, in some cases, for example, when an amount of the current transaction is relatively large (for example, is greater than a preset threshold), the second terminal performs the following step 908a to determine a payment risk)
[0186] Certainly, if a user of the second terminal is a payer, a risk prompt message may be directly displayed to the user of the second terminal, and a subsequent process continues to be performed after the user agrees.)
Re-claim 7, Ding et al. teach ---The method according to claim 1, wherein a proximity location of the short-range wireless communication tag further displays a collection code of the payee generated based on the code value.
(see e.g. [0286] The server of the target third-party payment application may further determine the payee's account based on the payment information sent by the first terminal.)
Re-claim 10, Ding et al. teach --The method according to claim 1, wherein the short-range wireless communication tag is an NFC tag.
(see e.g. [0058] In a possible design, the transmitter is further configured to send a request message for NFC tag reading to the first terminal through the NFC connection established between the second terminal and the first terminal.)
Claim 11 recites similar limitations as claim 1 and is therefore rejected under the same arts and rationale.
Claim 12 recites similar limitations as claim 2 and is therefore rejected under the same arts and rationale.
Claim 13 recites similar limitations as claim 3 and is therefore rejected under the same arts and rationale.
Claim 15 recites similar limitations as claim 5 and is therefore rejected under the same arts and rationale.
Claim 17 recites similar limitations as claim 7 and is therefore rejected under the same arts and rationale.
Claim 20 recites similar limitations as claim 1 and is therefore rejected under the same arts and rationale.
Claims 4, 6, 14, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over DING et al. (US 20200134601 A1), in view of AONUMA et al. (JP 2012194848 A).
Re-claim 4, Ding et al. do not teach the following limitations.
However, AONUMA et al. teach -- The method according to claim 3, wherein the prompt contains a product personalized extension field corresponding to current large payment; and
(see e.g. page 9-- In the checkout process for the product, Each time the product information is read by the reading unit, the settlement amount for the settlement process by the settlement unit is added based on the read product information)
--receiving corresponding confirmation of the payer on the client specifically comprises:
--receiving a value assignment operation performed by the payer on the client for the product personalized extension field; and
(see e.g. [ ] When the user inserts the first rental product 9 into the product insertion unit 10 in accordance with the guidance display and performs a touch input to instruct execution of product registration, the control unit 16 proceeds to step S2 and proceeds to the bar code reader. 12, the barcode 11 is read.
--confirming with the server based on the value-assigned product personalized extension field, so the server performs corresponding large payment processing based on the product personalized extension field; wherein the extension relates to product reservation and/or product customization.
(see e.g. page 4- At this time, a display based on the barcode information read on the display 5 or the information acquired from the server 3 can be performed to allow the user to confirm the product name and the rental fee.)
page 5- Subsequently, the control unit 16 proceeds to step S7, displays the settlement amount (total amount of rental fee) and the list of rental products at this time on the display 5, and confirms the display content and proceeds to the payment process.)
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Ding et al., and include the steps cited above, as taught by AONUMA et al., for performing a settlement process for the consideration of the product (see claim 1).
Re-claim 6, Ding et al. teach --The method according to claim 5, wherein reading, by the mobile device in which the client is located, a short-range wireless communication tag of a payee specifically comprises:
--reading, by the mobile device in which the client is located, an amount to be paid written by the payee into the short-range wireless communication tag; and
(see e.g. [0177] Specifically, the payment information may be one-off payment information of the target third-party payment application that is generated by the first terminal based on an account of the target third-party payment application and other information such as a possible amount. --One-off payment information that is generated each time NFC payment is made by using the target third-party payment application may vary with a transaction amount, a location, or a moment of each payment.
[0234] In the method, a first terminal stores payment information of the first terminal into an NFC tag, and a second terminal can read the NFC tag to obtain the payment information of the first terminal. The method may be applied to a scenario in which the first terminal is a payee and the second terminal is a payer.)
Ding et al. do not teach the following limitations.
However, AONUMA et al. teach ---triggering the server of the payment application to obtain a dynamic code of the payee and perform corresponding large payment processing based on the dynamic code of the payee specifically comprises: ---obtaining the amount to be paid determined by the mobile device by reading; determining whether the received payment amount inputted by the payer is not less than the amount to be paid; and if yes, initiating payment, limited by the amount to be paid, to the server of the payment application, so an actual payment amount of the payer for one or more times is equal to the amount to be paid.
(see e.g. page 3 ---when the customer inputs the payment amount and decides to execute the payment, it is determined whether or not the charge balance or the credit balance is equal to or larger than the payment amount.)
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Ding et al., and include the steps cited above, as taught by AONUMA et al., in order to confirm the charge balance (see e.g. page 5).
Claim 14 recites similar limitations as claim 4 and is therefore rejected under the same arts and rationale.
Claim 16 recites similar limitations as claim 6 and is therefore rejected under the same arts and rationale.
Claims 8, 9, 18, 19 are rejected under 35 U.S.C. 103 as being unpatentable over DING et al. (US 20200134601 A1), in view of Doyle et al. (US 20220076235).
Re-claim 8, 9, 18, 19 Ding et al. do not teach the following limitations.
However, Doyle et al. teach ----- The method according to claim 1, wherein the mobile device is a wearable device. The method according to claim 8, wherein the wearable device comprises a smart watch that does not have a camera supporting code scanning.
(see e.g. [0221] In other examples, such as with a smart phone or watch operating as a short-range communication payment instrument, information about the approved transaction may be provided to the short-range communication payment instrument for presentation via a display of the smart phone or watch.
[0254] In at least one example, the user device 1902 can be any suitable type of computing device, e.g., portable, semi-portable, semi-stationary, or stationary. Some examples of the user device 1902 can include, but are not limited to -- a wearable computing device or other body-mounted computing device).
therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Ding et al., and include the steps cited above, as taught by Doyle et al., in order to provide a variety of checkout options for customers (see e.g. [0002]).
Claim 18 recites similar limitations as claim 8 and is therefore rejected under the same arts and rationale.
Claim 19 recites similar limitations as claim 9 and is therefore rejected under the same arts and rationale.
Furthermore , Doyle et al. do not teach a smart watch that does have a camera supporting code scanning.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
OOSTHUIZEN et al. (US 20220012711 A1) --Establishing a shared session between entities.
Brown et al. (US 20080201264 A1)-- Payment card financial transaction authenticator.
Kim et al. (EP 4109370) --Payment information transfer system using mobile terminal and payment information transfer method using same.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LUNA CHAMPAGNE whose telephone number is (571)272-7177. The examiner can normally be reached M-F 8: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, Florian Zeender can be reached at 571 272-6790. 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.
/LUNA CHAMPAGNE/Primary Examiner, Art Unit 3627
April 23, 2026
Prosecution Insights