Detailed Action
Acknowledgements
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in reply to the Amendment filed on December 23, 2025.
Claims 1-20 are pending.
Claims 1-20 are examined.
This Office Action is given Paper No. 20260209 for references purposes only.
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.
Step 2A Prong 1: The claims recite an abstract idea of providing payment for a transaction with a visual payment code, which is a certain method of organizing human activity (e.g. fundamental economic principles or practices including hedging, insurance, mitigating risk; commercial or legal interactions including agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, business relations; managing personal behavior or relationships or interactions between people including social activities, teaching, and following rules or instructions).
Claim 1, representative of claims 12 and 19, includes the following limitations:
Receiving a request for a payment code;
Identifying a payment method and a payment type;
Obtaining payment details for the payment method;
Generating a payment code as an encoding of a payment token identifier, the payment type, and the payment details;
Providing the payment code for display for a frictionless payment, wherein the payment code is displayed alongside items being purchased, wherein the terminal recognizes the payment code as a payment request and processes payment after a countdown timer expires unless the shopper cancels;
Wherein the mobile device is facing up towards a terminal camera, and wherein a message indicates the payment will proceed in a predefined number of seconds unless the shopper cancels via a touch option.
Step 2A Prong 2: The claim limitations recite the following additional elements that are beyond the judicial exception:
A user mobile device;
A terminal;
One or more cameras;
Terminal display.
These additional elements are not indicative of integration into a practical application because:
They add the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea. See MPEP 2106.05(f).
Step 2B: The claim limitations do not recite additional elements, or an ordered combination of additional elements, that are sufficient to amount to significantly more than the judicial exception.
As discussed with respect to step 2A prong 2 above, the additional elements of “a user mobile device”, “a terminal”, “one or more cameras”, and “terminal display” are mere instructions to apply an exception, and do not integrate a judicial exception into a practical application at step 2A or provide an inventive concept at step 2B.
According to the 2019 PEG, a conclusion that an additional element is mere instructions to apply an exception under step 2A should be re-evaluated at step 2B. Thus, the additional elements of “a user mobile device”, “a terminal”, “one or more cameras”, and “terminal display” are re-evaluated to determine whether they constitute significantly more. Examiner finds that the additional elements of “a user mobile device”, “a terminal”, “one or more cameras”, and “terminal display” are simply the use of a computer in its ordinary capacity and does not provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262 and MPEP 2106.05(f). For example, the additional elements only provide a result-oriented solution and lack details as to how the computer performs the modifications, which is equivalent to “apply it”. See Alice Corp. v. CLS Bank, 134 S. Ct. 2347, 2357 and MPEP 2106.05(f).
Therefore, when considering all the additional claim elements both individually and as an ordered combination, Examiner finds that the claim does not amount to significantly more than the exception.
The dependent claims fail to cure this deficiency and are rejected accordingly.
Claim 2 recites receiving a store identifier, which is insignificant extra-solution activity (e.g. mere data gathering). See CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375, and MPEP 2106.05(g).
Claim 3 recites receiving a current mobile device location and a store identifier, which is insignificant extra-solution activity (e.g. mere data gathering). See CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375, and MPEP 2106.05(g).
Claim 4 recites selecting the payment method based on a store, which is insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated). See Electric Power Group, and MPEP 2106.05(g).
Claim 5 recites identifying the payment method based on a user selection on an interface, which is insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated). See Electric Power Group, and MPEP 2106.05(g).
Claim 6 recites assembling the payment token identifier and payment type as a string of information, which is insignificant extra-solution activity (e.g. mere data gathering). See Ultramercial, Inc. v. Hulu, 772 F.3d 709, 715.
Claim 7 recites encoding a loyalty identifier, which is insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated). See Electric Power Group, and MPEP 2106.05(g).
Claim 8 recites encoding an expiration data and time of day, which is insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated). See Electric Power Group, and MPEP 2106.05(g).
Claim 9 recites encoding a number of total times the payment code is usable, which is insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated). See Electric Power Group, and MPEP 2106.05(g).
Claim 10 recites encoding the payment code as a barcode or QR code, which is insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated). See Electric Power Group, and MPEP 2106.05(g).
Claim 11 recites instructing a wallet application to display the payment code, which generally links the use of the judicial exception to a particular technological environment or field of use (e.g. merely an attempt to limit the use of the abstract idea to a particular technological environment). See Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 716 and MPEP 2106.05(h).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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, 6-8, 10-12, 15, and 17-18 are rejected under 35 U.S.C. 103(a) as being unpatentable over Ortiz et al. (US 2018/0293573) in view of Hashimoto et al. (US 2022/0414644).
Claim 1
Ortiz discloses:
receiving a request for a payment code (“checkout” or “ready to pay”, see [0209]);
identifying a payment method (merchant “checkout” option or wallet “pay with your bank” option, see [0209]) and a payment type (card or account, e.g. VISA, Scotiabank, see [0213], figure 14E) of the payment method;
obtaining payment details (item to be purchased, price, see [0211], figure 14B) for the payment method;
generating the payment code (barcode or QR code, see [0438]) as an encoding (encoding, see [0466]) of a payment token identifier (HCE token, see [0169, 0178]), the payment type (card or account, see [0213]), and the payment details (item to be purchased, price, see [0211]);
wherein the payment code is displayed on the mobile device (displayed on mobile device, see [0022]) alongside items being purchased (one or more goods, see [0205]) for the transaction to one or more cameras (inherent, scanning, see [0022]) of the terminal (POS terminal, see [0022]), and wherein the terminal recognizes the payment code (QR code, see [0438]) as a payment request and processes payment for the transaction after a countdown timer expires unless canceled by the shopper (allow user to revise payment within a specified time limit, see [0119]).
Ortiz does not disclose:
Providing… shopper;
Wherein the shopper… shopper.
Hashimoto teaches:
providing the payment code (key code, see [0069]) to a mobile device (smartphone, see [0073]) of a shopper to display at a terminal (store terminal, see [0069]) for a frictionless payment during a transaction of the shopper;
wherein the shopper places the mobile device (smartphone, see [0073]) with a display (display screen, see [0069]) of the mobile device facing up towards the one or more cameras (camera, see [0069]) of the terminal (store terminal, see [0069]) alongside the items (product to checkout counter, see [0053]), and wherein a transaction manager of the terminal identifies the payment code (key code, see [0069]) and displays, on a terminal display (display screen, see [0049]), a message (e.g. “5 seconds” or display five blocks corresponding to length of payment time, see [0062]) indicating that payment for the transaction will proceed in a predefined number of countdown seconds (Time to Payment, e.g. 5 seconds, see [0062]) unless the shopper cancels the payment via a touch option (e.g. cancellation operation during payment time, e.g. press certain button, see [0065]) presented on the terminal display to the shopper.
Hashimoto teaches displaying on the mobile device display a message with a number of countdown seconds (i.e. time to payment) unless the shopper cancels the payment. It would have been obvious to one of ordinary skill in the art at the time of the invention to display on the terminal display the time to payment message because the use of a known technique (i.e. displaying a number of countdown seconds) can improve a similar device in the same way (KSR Rationale C).
Ortiz discloses receiving a request for a payment code, identifying a payment method, obtaining payment details, generating the payment code, and displaying the code on the device. Ortiz does not disclose providing the code to the mobile device and displaying a message, but Hashimoto does. It would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to combine the method for location-based token transaction processing of Ortiz with the providing the code to the mobile device and displaying a message of Hashimoto because 1) a need exists for improved user control over purchases where a purchaser is authorized to access multiple accounts in order to complete a transaction (see Ortiz [0026]); and 2) a need exists for a cashless payment system that uses a camera (see Hashimoto [0009]). Providing the code to the mobile device and displaying a message allows for status messaging on touchless payment devices.
Claim 6
Furthermore, Ortiz discloses:
assembling the payment token identifier and the payment type as a string of information, wherein generating the payment code (QR code, see [0438]) includes prepending or appending the string of information to the payment details (item to be purchased, price, see [0211]).
Claims 7, 15
Furthermore, Ortiz discloses:
generating the payment code (QR code, see [0438]) further includes encoding, in the payment code, a loyalty identifier for a loyalty account (loyalty account, see [0214], figure 14D) of the shopper with a store (Best Buy, see figure 14D) associated with the terminal.
Claim 8
Furthermore, Ortiz discloses:
generating the payment code further includes encoding, in the payment code, an expiration date (expiry date, see [0475], claim 8) and time of day (time stamp, see [0292]).
Claims 10, 17
Furthermore, Ortiz discloses:
generating the payment code further includes encoding the payment code as a barcode or a quick response (QR) code (QR code, see [0022]).
Claim 11
Furthermore, Ortiz discloses:
providing further includes instructing a wallet application (virtual wallet, see [0022]) of the mobile device to display the payment code (QR code, see [0022]) on a display of the mobile device (displayed on mobile device, see [0022]).
Claim 12
Ortiz discloses:
receiving a request for a payment code (“checkout” or “ready to pay”, see [0209]);
identifying a payment method (merchant “checkout” option or wallet “pay with your bank” option, see [0209]) for the payment code;
obtaining payment details (item to be purchased, price, see [0211], figure 14B) associated with the payment method;
appending a string of information to the payment details, the string of information at least comprises a payment token identifier (HCE token, see [0169, 0178]) for a payment token and a payment type (card or account, e.g. VISA, Scotiabank, see [0213], figure 14E) associated with the payment method;
encoding (encoding, see [0466]) the string of information and the payment details as the payment code (QR code, see [0438]); and
wherein the payment code is displayed on the mobile device (displayed on mobile device, see [0022]) alongside items being purchased (one or more goods, see [0205]) for the transaction to one or more cameras (inherent, scanning, see [0022]) of the terminal (POS terminal, see [0022]), and wherein the terminal recognizes the payment code (QR code, see [0438]) as a payment request and processes payment for the transaction after a countdown timer expires unless canceled by the shopper (allow user to revise payment within a specified time limit, see [0119]).
Ortiz does not disclose:
Rendering… terminal;
Wherein the shopper… shopper.
Hashimoto teaches:
rendering the payment code (key code, see [0069]) on a display of a mobile device (smartphone, see [0073]) for a shopper to present to a terminal (store terminal, see [0069]) for a frictionless payment during a transaction at the terminal;
wherein the shopper places the mobile device (smartphone, see [0073]) with the display facing up towards the one or more cameras (camera, see [0069]) of the terminal (store terminal, see [0069]) alongside the items (product to checkout counter, see [0053]), and wherein a transaction manager of the terminal identifies the payment code (key code, see [0069]) and displays, on a terminal display (display screen, see [0049]), a message (e.g. “5 seconds” or display five blocks corresponding to length of payment time, see [0062]) indicating that payment for the transaction will proceed in a predefined number of countdown seconds (Time to Payment, e.g. 5 seconds, see [0062]) unless the shopper cancels the payment via a touch option (e.g. cancellation operation during payment time, e.g. press certain button, see [0065]) presented on the terminal display to the shopper.
Hashimoto teaches displaying on the mobile device display a message with a number of countdown seconds (i.e. time to payment) unless the shopper cancels the payment. It would have been obvious to one of ordinary skill in the art at the time of the invention to display on the terminal display the time to payment message because the use of a known technique (i.e. displaying a number of countdown seconds) can improve a similar device in the same way (KSR Rationale C).
Ortiz discloses receiving a request for a payment code, identifying a payment method, obtaining payment details, appending a string of information comprising a payment token identifier, encoding the string of information and payment details, and displaying the code on the device. Ortiz does not disclose rendering the code on the mobile device and displaying a message, but Hashimoto does. It would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to combine the method for location-based token transaction processing of Ortiz with the rendering the code on the mobile device and displaying a message of Hashimoto because 1) a need exists for improved user control over purchases where a purchaser is authorized to access multiple accounts in order to complete a transaction (see Ortiz [0026]); and 2) a need exists for a cashless payment system that uses a camera (see Hashimoto [0009]). Rendering the code on the mobile device and displaying a message allows for status messaging on touchless payment devices.
Claim 18
Furthermore, Ortiz discloses:
processing the method as a wallet application (wallet application, see [0078]) on the mobile device.
Claims 2-5, 13-14, and 19 are rejected under 35 U.S.C. 103(a) as being unpatentable over Ortiz et al. (US 2018/0293573), in view of Hashimoto et al. (US 2022/0414644), and further in view of Satyanarayan et al. (US 2017/0161728).
Claim 2
Ortiz in view of Hashimoto discloses the limitations above. Ortiz in view of Hashimoto does not disclose:
Receiving… terminal.
Satyanarayan teaches:
receiving further includes receiving a store identifier (store identifier, see [0058, 0082]) for a store associated with the terminal.
Ortiz in view of Hashimoto teaches receiving a request for a payment code, identifying a payment method, obtaining payment details, generating the payment code, displaying the code on the device, providing the code to the mobile device, and displaying a message. Ortiz in view of Hashimoto does not disclose receiving a store identifier, but Satyanarayan does. It would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to combine the method for location-based token transaction processing of Ortiz, in view of Hashimoto, with the store identifier of Satyanarayan because a need exists for facilitating smooth, efficient, and intuitive in-store and online checkout for customers that reduces the amount of time spent at the checkout (see Satyanarayan [0015]). The store identifier can help reduce time at checkout.
Claim 3
Ortiz in view of Hashimoto discloses the limitations above. Furthermore, Ortiz discloses:
receiving further includes receiving a current location for the mobile device (location of device, see [0437]).
Ortiz in view of Hashimoto does not disclose:
Obtaining… store.
Satyanarayan teaches:
obtaining a store identifier (store identifier, see [0058, 0082]) for a store associated with the terminal based on the current location and a known location associated with the store (specific location within the store, see [0082]).
Ortiz in view of Hashimoto teaches receiving a request for a payment code, identifying a payment method, obtaining payment details, generating the payment code, displaying the code on the device, providing the code to the mobile device, and displaying a message. Ortiz in view of Hashimoto does not disclose obtaining a store identifier, but Satyanarayan does. It would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to combine the method for location-based token transaction processing of Ortiz, in view of Hashimoto, with the store identifier of Satyanarayan because a need exists for facilitating smooth, efficient, and intuitive in-store and online checkout for customers that reduces the amount of time spent at the checkout (see Satyanarayan [0015]). The store identifier can help reduce time at checkout.
Claim 4
Ortiz in view of Hashimoto discloses the limitations above. Ortiz in view of Hashimoto does not disclose:
Identifying… terminal
Satyanarayan teaches:
identifying the payment method includes selecting the payment method (wallet application, see [0082]) based on a store (store identifier, see [0058, 0082]) associated with the terminal.
Ortiz in view of Hashimoto teaches receiving a request for a payment code, identifying a payment method, obtaining payment details, generating the payment code, displaying the code on the device, providing the code to the mobile device, and displaying a message. Ortiz in view of Hashimoto does not disclose selecting a payment method based on a store identifier, but Satyanarayan does. It would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to combine the method for location-based token transaction processing of Ortiz, in view of Hashimoto, with selecting a payment method based on a store identifier of Satyanarayan because a need exists for facilitating smooth, efficient, and intuitive in-store and online checkout for customers that reduces the amount of time spent at the checkout (see Satyanarayan [0015]). Selecting a payment method based on a store identifier can help reduce time at checkout.
Claims 5, 14
Ortiz in view of Hashimoto discloses the limitations above. Ortiz in view of Hashimoto does not disclose:
Identifying… terminal.
Satyanarayan teaches:
identifying the payment method includes identifying the payment method based on a selection made by the shopper through an interface (user interface, see [0043]) that identifies a store (store location, see [0091]) associated with the terminal.
Ortiz in view of Hashimoto teaches receiving a request for a payment code, identifying a payment method, obtaining payment details, generating the payment code, displaying the code on the device, providing the code to the mobile device, and displaying a message. Ortiz in view of Hashimoto does not disclose selecting a payment method based on a store identifier, but Satyanarayan does. It would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to combine the method for location-based token transaction processing of Ortiz, in view of Hashimoto, with selecting a payment method based on a store identifier of Satyanarayan because a need exists for facilitating smooth, efficient, and intuitive in-store and online checkout for customers that reduces the amount of time spent at the checkout (see Satyanarayan [0015]). Selecting a payment method based on a store identifier can help reduce time at checkout.
Claim 13
Ortiz in view of Hashimoto discloses the limitations above. Ortiz in view of Hashimoto does not disclose:
Selecting… terminal.
Satyanarayan teaches:
selecting the payment method from a plurality of payment methods associated with the shopper based on a store (store location, see [0091]) associated with the terminal (store location, see [0091]).
Ortiz in view of Hashimoto teaches receiving a request for a payment code, identifying a payment method, obtaining payment details, generating the payment code, displaying the code on the device, providing the code to the mobile device, and displaying a message. Ortiz in view of Hashimoto does not disclose selecting a payment method based on a store identifier, but Satyanarayan does. It would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to combine the method for location-based token transaction processing of Ortiz, in view of Hashimoto, with selecting a payment method based on a store identifier of Satyanarayan because a need exists for facilitating smooth, efficient, and intuitive in-store and online checkout for customers that reduces the amount of time spent at the checkout (see Satyanarayan [0015]). Selecting a payment method based on a store identifier can help reduce time at checkout.
Claim 19
Ortiz discloses:
a server comprising at least one processor (processor, see [0027]) and a non-transitory computer-readable storage medium (medium, see [0029]);
the non-transitory computer-readable storage medium comprising executable instructions (instructions, see [0029]);
the executable instructions when provided to or obtained by the at least one processor from the non-transitory computer-readable storage medium cause the at least one processor to perform operations, comprising:
receiving a request for a payment code (“checkout” or “ready to pay”, see [0209]) from a wallet application (virtual wallet, see [0022]) of a mobile device (device, see [0209]) operated by a shopper (user, see [0209]);
identifying payment services (e.g. pay with bank, use loyalty points, see figure 14D) supported by the transaction terminal based on the store;
identifying payment types (card or account, e.g. VISA, Scotiabank, see [0213], figure 14E) supported by the payment services;
identifying available payment methods (merchant “checkout” option or wallet “pay with your bank” option, see [0209]) registered to the shopper based on the payment types;
selecting an available payment method (wallet “pay with your bank” option, see [0209]);
obtaining payment details (item to be purchased, price, see [0211], figure 14B) for a selected payment method;
generating a string of information comprising a payment token identifier (HCE token, see [0169, 0178]) for a payment token and a particular payment type (card or account, e.g. VISA, Scotiabank, see [0213], figure 14E) associated with the selected payment method;
appending or prepending the string of information (token, see [0213]) on the payment details (item to be purchased, price, see [0211], figure 14B);
encoding (encoding, see [0466]) the string of information appended on or prepended to the payment details as the payment code.
Ortiz does not disclose:
Instructing… payment;
Wherein the shopper… shopper.
Hashimoto teaches:
instructing the wallet application to render the payment code (key code, see [0069]) on a display of the mobile device (smartphone, see [0073]) for the shopper to present alongside items being purchased for the transaction to one or more cameras of the transaction terminal (store terminal, see [0069]) for a vision-based checkout with the vision-based frictionless payment;
wherein the shopper places the mobile device (smartphone, see [0073]) with the display facing up towards the one or more cameras (camera, see [0069]) of the transaction terminal (store terminal, see [0069]) alongside the items (product to checkout counter, see [0053]), and wherein a transaction manager of the transaction terminal identifies the payment code (key code, see [0069]) and displays, on a terminal display (display screen, see [0049]), a message (e.g. “5 seconds” or display five blocks corresponding to length of payment time, see [0062]) indicating that payment for the transaction will proceed in a predefined number of countdown seconds (Time to Payment, e.g. 5 seconds, see [0062]) unless the shopper cancels the vision-based frictionless payment via a touch option (e.g. cancellation operation during payment time, e.g. press certain button, see [0065]) presented on the terminal display to the shopper.
Hashimoto teaches displaying on the mobile device display a message with a number of countdown seconds (i.e. time to payment) unless the shopper cancels the payment. It would have been obvious to one of ordinary skill in the art at the time of the invention to display on the terminal display the time to payment message because the use of a known technique (i.e. displaying a number of countdown seconds) can improve a similar device in the same way (KSR Rationale C).
Ortiz discloses a server, a medium, instructions that cause a processor to: receiving a request for a payment code, identifying payment services, identifying payment types, identifying available payment methods, selecting an available payment method, obtaining payment details, generating a string of information, appending the string of information on payment details, and encoding the string of information and payment details. Ortiz does not disclose rendering the code on the mobile device and displaying a message, but Hashimoto does. It would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to combine the method for location-based token transaction processing of Ortiz with the rendering the code on the mobile device and displaying a message of Hashimoto because 1) a need exists for improved user control over purchases where a purchaser is authorized to access multiple accounts in order to complete a transaction (see Ortiz [0026]); and 2) a need exists for a cashless payment system that uses a camera (see Hashimoto [0009]). Rendering the code on the mobile device and displaying a message allows for status messaging on touchless payment devices.
Ortiz in view of Hashimoto discloses the limitations above. Ortiz in view of Hashimoto does not disclose:
Determining… store.
Satyanarayan teaches:
determining a store (store, see [0067, 0082]) where the shopper (customer, see [0067, 0082]) wants to use the payment code as a vison-based frictionless payment during a transaction at a transaction terminal (POS, see [0051]) of the store.
Ortiz in view of Hashimoto discloses a server, a medium, instructions that cause a processor to: receiving a request for a payment code, identifying payment services, identifying payment types, identifying available payment methods, selecting an available payment method, obtaining payment details, generating a string of information, appending the string of information on payment details, encoding the string of information and payment details, rendering the code on the mobile device, and displaying a message. Ortiz in view of Hashimoto does not disclose determining a store to use the payment code, but Satyanarayan does. It would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to combine the method for location-based token transaction processing of Ortiz, in view of Hashimoto, with the determining a store to use the payment code of Satyanarayan because a need exists for facilitating smooth, efficient, and intuitive in-store and online checkout for customers that reduces the amount of time spent at the checkout (see Satyanarayan [0015]). Determining a store to use the payment code can help reduce time at checkout.
Claims 9 and 16 are rejected under 35 U.S.C. 103(a) as being unpatentable over Ortiz et al. (US 2018/0293573), in view of Hashimoto et al. (US 2022/0414644), and further in view of Morgan et al. (US 2021/0406859).
Claim 9
Ortiz in view of Hashimoto discloses the limitations above. Ortiz in view of Hashimoto does not disclose:
Generating… shopper.
Morgan teaches:
generating the payment code further includes encoding, in the payment code, a number representing a total number of times that the payment code is usable by the shopper (preset time limitation that expires, see [0038]).
Ortiz in view of Hashimoto discloses receiving a request for a payment code, identifying a payment method, obtaining payment details, generating the payment code, providing the code to the mobile device, displaying the code on the device, and displaying a message. Ortiz in view of Hashimoto does not disclose encoding a number of times the code is usable, but Morgan does. It would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to combine the method for location-based token transaction processing of Ortiz, in view of Hashimoto, with the encoding a number of times the code is usable of Morgan because a need exists for status messages provided to touchless payment devices in real time (see Morgan [0006]). Encoding a number of times the code is usable ensures the code is not used beyond the permitted uses.
Claim 16
Ortiz in view of Hashimoto discloses the limitations above. Furthermore, Ortiz discloses:
appending further includes adding an expiration date (expiry date, see [0475], claim 8) and time (time stamp, see [0292]).
Ortiz in view of Hashimoto does not disclose:
A total… information.
Morgan teaches:
a total number of uses for the payment code (preset time limitation that expires, see [0038]) to the string of information.
Ortiz in view of Hashimoto discloses receiving a request for a payment code, identifying a payment method, obtaining payment details, appending a string of information comprising a payment token identifier, encoding the string of information and payment details, displaying the code on the device, rendering the code on the mobile device, and displaying a message. Ortiz in view of Hashimoto does not disclose a total number of uses for the code, but Morgan does. It would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to combine the method for location-based token transaction processing of Ortiz, in view of Hashimoto, with the total number of uses for the code of Morgan because a need exists for status messages provided to touchless payment devices in real time (see Morgan [0006]). Having a total number of uses for the code ensures the code is not used beyond the permitted uses.
Response to Arguments
101 arguments
Applicant argues that the claimed invention is a technical improvement to frictionless payment processing. Specifically, Applicant argues that the payment code format is a specifically structured code, there is spatial arrangement for the vision system to capture items, and the terminal has enhanced processing.
Examiner disagrees. The claimed invention is not a technical improvement to frictionless payment processing. First, the payment code is structured the same as standard payment codes. There is no technical improvement in the payment code structure. Second, having spatial arrangement to capture items is not a technical solution. Finally, the terminal does not have enhanced processing; the terminal simply has a camera recognizing a payment code as a payment request on a mobile device.
103 arguments
Applicant argues that the prior art does not teach a payment code displayed on a mobile device alongside items being purchased to terminal cameras, wherein the terminal recognizes the payment code as a payment request and processes payment after a countdown timer expires. Applicant also argues there is insufficient motivation to combine Ortiz with Morgan.
Please see revised rejection.
Claim Interpretation
Applicant is reminded that functional recitation(s) using the word and/or phrases “for”, “adapted to”, or other functional language (e.g. see claim 19 which recites “wants to use”) have been considered but are given little patentable weight because they fail to add any structural limitations and are thereby regarded as intended use language. To be especially clear, all limitations have been considered. However, a recitation of the intended use of the claimed product must result in a structural difference between the claimed product and the prior art in order to patentably distinguish the claimed product from the prior art. If the prior art structure is capable of performing the intended use, then it reads on the claimed limitation. In re Casey, 370 F.2d 576, 152 USPQ 235 (CCPA 1967) ("The manner or method in which such a machine is to be utilized is not germane to the issue of patentability of the machine itself.”); In re Otto, 136 USPQ 458, 459 (CCPA 1963). See also MPEP §§ 2106 II (C.), 2114 and 2115. Unless expressly noted otherwise by Examiner, the claim interpretation principles in the paragraph apply to all examined claims currently pending.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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 of a general nature or relating to the status of this application or concerning this communication or earlier communications from Examiner should be directed to Chrystina Zelaskiewicz whose telephone number is 571-270-3940. Examiner can normally be reached on Monday-Friday, 9:30am-5:00pm. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, Neha Patel can be reached at 571-270-1492.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://portal.uspto.gov/external/portal/pair <http://pair-direct.uspto.gov>. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866.217.9197 (toll-free).
/CHRYSTINA E ZELASKIEWICZ/Primary Examiner, Art Unit 3699