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 .
Note to Applicant
In response to Applicant's remarks submitted on 08/03/26, the Examiner has vacated the previous Non Final Action dated 05/01/26, in favor of a new Non-Final Action. Please see the rejection below.
Status of Claims
Applicant’s submission filed 08/03/26 has been entered. Claims 2 and 12 are cancelled. Claims 1, 3-11, 13-20 are presented for examination.
Information Disclosure Statement
The information disclosure statement filed 5/26/26 fails to comply with 37 CFR 1.97(c) because it lacks the timing fee set forth in 37 CFR 1.17(p). It has been placed in the application file, but the information referred to therein has not been considered.
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, 6-7, 10, 11, 13, 16-17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Phillips et al. (US 20160155112 A1).
Re-claim 1, Phillips 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; obtaining related information of the payee based on the code value in response to the wake- up instruction;
(see e.g. [0114] The shopper uses his/her mobile device (e.g., mobile device 1002 in FIG. 10) to scan the QR code. The scanning of the QR code launches a mobile payment application in the mobile device used by the shopper (the first mobile device).
[0131] At block 1110 in FIG. 11, a first mobile device scans, via its camera, a barcode such as a QR code. As noted above, this may cause a payment application to be launched on the first mobile device.
[0069] By capturing or reading the QR code 334 or other identifier, the mobile application is able to obtain merchant and transaction information in a transaction payload from the merchant website. For example, the transaction payload may include a merchant ID, a merchant name, a payment gateway ID, and a basket ID used to identify the user's item(s) to be purchased.
[0105] The QR code contains information that supports a payment transaction via the cardholder's mobile device. The cardholder uses the camera of the mobile device to scan the QR code on the bill. The scanning of the QR code launches a mobile payment application on the mobile device.
[0180] For example, the transaction payload may be encoded in an NFC tag or otherwise transmitted to the mobile device as an NFC message.
[0092] The mobile device 200 further includes a contactless interface 824 with an antenna 826, here labeled the proximity payment controller, which can function to read a tag device associated with a POS 104 to receive transaction and other information from the tag device in wireless transactions.)
[0105] The QR code contains information that supports a payment transaction via the cardholder's mobile device. The cardholder uses the camera of the mobile device to scan the QR code on the bill. The scanning of the QR code launches a mobile payment application on the mobile device.)
--wherein the short-range wireless communication tag comprises: a dynamic code of the payee generated or applied for by the payee and dynamically updated and written into the short-range wireless communication tag;
(see e.g. [0024] During the browsing on the device, the consumer may be prompted (or choose) to conduct the transaction using their mobile device and may initiate the transaction by either scanning a dynamic QR code from the merchant site (e.g., by capturing the QR code from a display screen associated with the personal computer, tablet, television or the like)
[0034] The transaction payload information may be provided in a number of different ways (including, for example, via a QR code,)
[0180] For example, the transaction payload may be encoded in an NFC tag or otherwise transmitted to the mobile device as an NFC message.
[0055] Pursuant to some embodiments, the merchant device 206 may also have a QR code interface that allows the merchant to provide a QR code based on the transaction payload generated for a specific transaction (such QR codes may, for example, only be generated for m-commerce transactions).
[0034] The transaction payload may also include other optional data elements including, for example, a timestamp, one or more extensions or the like.)
***The Examiner notes the dynamic code is generated for a specific transaction and is encoded into the NFC tag.
-- 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]] the dynamic code of the payee and perform corresponding large payment processing based on the dynamic code of the payee; and receiving a payment result returned by the server.
[0055] Pursuant to some embodiments, the merchant device 206 may also have a QR code interface that allows the merchant to provide a QR code based on the transaction payload generated for a specific transaction (such QR codes may, for example, only be generated for m-commerce transactions).
[0022] providing a reduced fraud risk, --- As a result, the transaction process of the present application is suitable for use in a number of types of transactions, including high value transactions.)
***The Examiner notes Phillips teach” the transaction process of the present application is suitable for use in a number of types of transactions, including high value transactions” and the dynamic code is generated for a specific transaction.
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 Phillips et al., and include the large payment trigger, in order to reduce fraud and risk (see Phillips et al. [0007]).
Re-claim 3, Phillips 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. [0024] During the browsing on the device, the consumer may be prompted (or choose) to conduct the transaction using their mobile device and may initiate the transaction by either scanning a dynamic QR code from the merchant site (e.g., by capturing the QR code from a display screen associated with the personal computer, tablet, television or the like) or by other methods .
-- 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. [0048] The user may be prompted to verify the merchant name.
[0077] Processing continues at 508 where the mobile application receives instructions and/or confirmation from the user to finalize the transaction).
claim 16 -- receive, from said payment gateway, item data associated with said transaction, said item data obtained by said payment gateway from a merchant involved in the transaction; and receive, from a user operating said mobile device having said storage device, a confirmation to complete said transaction using a payment account associated with said user and transmitting said confirmation to said payment gateway with payment account credentials associated with said payment account.).
Re-claim 6, Phillips 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. [0134] The payment transaction process may utilize data obtained by the first mobile device from scanning the QR code, and transmitted from the first mobile device to the second mobile device. The data may, for example, identify the merchant/payee as well as the payment gateway or other device/entity to be contacted by the second mobile device to execute the transaction. The data may also include the amount of the payment to be made.)
Phillips et al. anticipate-- 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:
(see e.g. [0022] - the transaction process of the present application is suitable for use in a number of types of transactions, including high value transactions.
[0055] Pursuant to some embodiments, the merchant device 206 may also have a QR code interface that allows the merchant to provide a QR code based on the transaction payload generated for a specific transaction)
---obtaining the amount to be paid determined by the mobile device by reading;
(see e.g. [0035] the mobile device 202 initiates a connection to that gateway 210, and transmits the transaction payload data plus additional data to create a unique identifier for the transaction.
[0134] At block 1140 in FIG. 11, the requested payment transaction process may be performed. This may occur, for example, via interaction by the second mobile device with one or more of a payment gateway, a paycode server, the merchant/payee and/or the acquirer for the merchant. The payment transaction process may utilize data obtained by the first mobile device from scanning the QR code, and transmitted from the first mobile device to the second mobile device. The data may, for example, identify the merchant/payee as well as the payment gateway or other device/entity to be contacted by the second mobile device to execute the transaction. The data may also include the amount of the payment to be made.)
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.
[0044] A third step (labeled as message or interaction “3”) involves the payment gateway 210 performing a validation of the transaction payload by interacting with the merchant 206.
0050] Processing at step “4” may include the merchant performing the following actions: validating the transaction payload seal, validating the basket ID ({ID3}), delivering information (such as the basket content, amount, currency or the like) to the payment gateway 210, and defining and establishing a session for {ID1}-{ID4}.
037] A fourth interaction (labeled as item “4”) occurs between the merchant 206 and the payment gateway 210, where the merchant 206 validates the basket ID received in message or interaction “3”, and uses the basket ID to lookup details of the transaction. The transaction details are then returned to the payment gateway 210 and may include, for example, the basket ID, a transaction amount, the relevant currency, etc. At this point in the transaction flow, the payment gateway 210 has information associated with the pending transaction, including the basket ID, the transaction details (including, for example, the transaction amount) and the transaction payload. The payment gateway 210 also has information about the mobile device 202 including a unique session identifier allowing communication between the payment gateway 210 and the mobile device 202/secure element 204.)
Re-claim 7, Phillips 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. [0024] A transaction pursuant to the present invention may be initiated based on a direct trigger from the mobile browser (or by a merchant mobile application) or by a scan of a static Quick Response (“QR”) code from printed media (such as a billboard, a newspaper or magazine advertisement, etc.).
[0034] In some embodiments, a static flag may also be used. The static flag may be a merchant's unique static product(s)/service(s) identifier for use in static QR codes such as, for example, posters, flyers or other materials.)
[0007] allowing proximity payment transactions at point of sale locations ).
[0047] In a third embodiment, a mobile device 202 may use a QR scan (to scan a QR code displayed at the merchant 206, or on some other printed or other material) to access the merchant. In such an embodiment, the mobile application is launched by the consumer and is used to scan the QR code. The transaction payload is received when scanning the QR code.)
Re-claim 10, Phillips et al. teach --The method according to claim 1, wherein the short-range wireless communication tag is an NFC tag.
(see e.g. [0180] For example, the transaction payload may be encoded in an NFC tag or otherwise transmitted to the mobile device as an NFC message.
Claim 11 recites similar limitations as claim 1 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 16 recites similar limitations as claim 6 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, 14 are rejected under 35 U.S.C. 103 as being unpatentable over Phillips et al. (US 20160155112 A1), in view of AONUMA et al. (JP 2012194848 A).
Re-claim 4, Phillips 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 Phillips 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).
Claim 14 recites similar limitations as claim 4 and is therefore rejected under the same arts and rationale.
Claims 5, 15 are rejected under 35 U.S.C. 103 as being unpatentable over Phillips et al. (US 20160155112 A1), in view of over DING et al. (US 20200134601 A1).
Re-claim 5, Phillips et al. do not teach the limitations as claimed.
However, 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.)
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 Phillips et al., and include the steps cited above, as taught by Ding et al., in order determine a payment risk (see e.g. [0183]).
Claim 15 recites similar limitations as claim 5 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 Phillips et al. (US 20160155112 A1), in view of Doyle et al. (US 20220076235).
Re-claim 8, 9, 18, 19 Phillips 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 Phillips 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.
Response to Arguments
Applicant’s arguments with respect to the Non Final dated 5/26/26 have been considered but are moot in view of the new rejection.
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
October 9, 2026
