DETAILED ACTION
This action is in response to a filing filed on August 22nd, 2024. Claim 1-20 have been examined in this application. The Information Disclosure Statement (IDS) filed on August 22nd, 2024 has been acknowledged.
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 .
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. an abstract idea) without significantly more.
Step 1: Claims 1-7 and 15-20 is/are drawn to method (i.e., a process), and claims 8-14 is/are drawn to system (i.e., a manufacture). (Step 1: YES).
Step 2A - Prong One: In prong one of step 2A, the claim(s) is/are analyzed to evaluate whether it/they recite(s) a judicial exception.
Claim 1: A computer implemented method comprising:
obtaining, by one or more processors on a merchant device operatively coupled to a payment gateway, a checkout request for an order of an amount by a customer;
receiving, by the one or more processors, an electronic checkout option selected by the customer;
generating, by the one or more processors, a checkout link to a web page for the customer to process a payment of the amount by the electronic checkout option, wherein the web page is operatively coupled to the payment gateway;
delivering, by the one or more processors, to a customer device, the checkout link for the customer via a link delivery method selected by the customer, wherein the customer device is operatively coupled to the payment gateway via the web page;
and updating, by the one or more processors, a status of the payment of the amount requested with the checkout link with the payment gateway.
Claim 15: A computer implemented method comprising:
receiving, by one or more processors on a customer device operated by a customer, a checkout link to a web page for the customer from a merchant device for a retail purchase, the web page being to process a payment of an amount of an order for the customer by an electronic checkout option;
accessing, by the one or more processors, the web page led by the checkout link on a web browser of the customer device, the web page being operatively coupled to a payment gateway for the merchant device via a digital communication network;
obtaining, by the one or more processors, payment data from the customer interactively providing the payment data into input fields of the web page for processing the payment for the amount;
sending, by the one or more processors, the payment data for the electronic checkout option to the payment gateway;
receiving, by the one or more processors, a payment confirmation and a receipt from the payment gateway.
(Examiner notes: The underlined claim terms above are interpreted as additional elements beyond the abstract idea and are further analyzed under Step 2A - Prong Two)
Under their broadest reasonable interpretation, the claim 1 is/are directed to the abstract idea of facilitating a commercial transaction using electronic payment processing, specifically organizing interactions between a merchant and a customer to complete payment through an electronically delivered checkout link. The claim recites steps of receiving a checkout request, selecting an electronic checkout option, generating and delivering a link to a payment web page, and updating payment status, which collectively amount to organizing human activity related to sales and payment transactions and managing information flow between parties. These steps reflect fundamental economic practices; such as offering payment options, transmitting payment instructions, and confirming payment status, implemented using generic computer components and network communication, without reciting a specific technological improvement to computer functionality and falls under “Certain Methods of Organizing Human Activity”.
Further the claim 15 is/are directed to the abstract idea of conducting a retail payment transaction via electronic information exchange, specifically enabling a customer to complete payment by accessing a checkout link, entering payment data into a web page, transmitting the payment data, and receiving confirmation and a receipt. The claim focuses on collecting, transmitting, and processing payment information and communicating transaction results, which are longstanding commercial practices in the field of electronic commerce. The recited steps constitute data entry, data transmission, and notification of results in the context of a financial transaction, implemented using a customer device, web browser, and payment gateway, and do not recite a technological improvement beyond automating conventional payment activities, and falls under “Certain Methods of Organizing Human Activity”. From applicant’s specification, the claimed invention is implemented to “The payment gateway 150 is operatively coupled to payment network for brand credit cards and bank cards to handle all conventional payment transactions as in conventional payment devices, which are not shown in FIG. 1. Particularly in aspects of the omnichannel checkout system 100, the payment gateway 150 provides a checkout service 160, a customer service 170, a messaging service 180, and an event service 190 for the merchant device 110.[0042] The checkout service 160 of the payment gateway 150 is a destination of the checkout URL 127 or the checkout QR code 129, offering a web page for processing payments for the customer 103 regarding the order” (see 0040 of instant specification). The steps under its broadest reasonable interpretation specifically directed to an abstract idea of collecting, transmitting, and processing payment information and communicating transaction results, which is an instance of certain methods of organizing human activity. The Examiner notes that although the claim limitations are summarized, the analysis regarding subject matter eligibility considers the entirety of the claim and all of the claim elements individually, as a whole, and in ordered combination.
And the dependent claims 2-7, 9-14, and 16-20 recites an abstract idea, directed to additional aspects of organizing and managing a commercial payment transaction, including determining customer presence, handling backordered items, offering alternative payment arrangements, and controlling the timing and status of payment completion. These claims recite steps such as ascertaining whether a customer is remote, identifying backordered items and associated due dates, providing deferred, installment, or recurring payment options, setting expiration timers for checkout links, updating payment status based on whether payment is completed within a defined time window, canceling payment upon expiration, and storing orders in a pending checkout list. Collectively, these limitations amount to organizing human activity and fundamental economic practices related to sales, inventory management, payment scheduling, and order processing. The claims focus on business rules and transactional logic such as when payment is due, how long a checkout option remains valid, and how orders are tracked, implemented using generic computing components, without reciting any specific technological improvement to computer functionality or payment network operations. Further, dependent claims 16–20 further narrow the abstract idea by further conducting an electronic retail payment transaction through information exchange, including specifying formats for delivering checkout links, selecting funding sources, synchronizing payment status, and aligning payment timing with item availability. These claims recite delivering a checkout link via email, SMS, messenger notification, or QR code; allowing payment using electronic currencies or digital wallet credits; synchronizing payment status between merchant and customer devices after confirmation; and setting payment due dates based on estimated delivery of backordered items. Together, these limitations describe communicating payment information, selecting among available payment options, and managing transaction status and timing, which are longstanding commercial practices in electronic commerce. The claims rely on generic communication channels, generic payment sources, and routine status updates, and merely automate conventional financial and order-management activities using standard computing and networking technology. As such, the claims are directed to an abstract idea involving certain methods of organizing human activity, which falls within a judicial exception under 35 U.S.C. §101.
Independent claim(s) 8 recite/describe nearly identical steps (and therefore also recite limitations that fall within this subject matter grouping of abstract ideas), and this/these claim(s) is/are therefore determined to recite an abstract idea under the same analysis.
As such, the Examiner concludes that claims 1 and 15 recites an abstract idea (Step 2A – Prong One: YES).
Step 2A - Prong Two: In prong two of step 2A, an evaluation is made whether a claim recites any additional element, or combination of additional elements, that integrate the exception into a practical application of that exception. An “addition element” is an element that is recited in the claim in addition to (beyond) the judicial exception (i.e., an element/limitation that sets forth an abstract idea is not an additional element). The phrase “integration into a practical application” is defined as requiring an additional element or a combination of additional elements in the claim to apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that it is more than a drafting effort designed to monopolize the exception.
The requirement to execute the claimed steps/functions using a computing device, processors, memory, payment gateway, customer device, digital communication network, etc. (Claims 1, 8, and 15) is/are equivalent to adding the words “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer.
Similarly, the limitations of using a computing device, processors, memory, payment gateway, customer device, digital communication network, etc. (Claims 1, 8, and 15, and dependent claims 2-7, 9-14, and 16-20) are recited at a high level of generality and amount to no more than mere instructions to apply the exception using generic computer components. This/these limitation(s) do/does not impose any meaningful limits on practicing the abstract idea, and therefore do/does not integrate the abstract idea into a practical application (see MPEP 2106.05(f)).
Further, the additional limitations beyond the abstract idea identified above, serves merely to generally link the use of the judicial exception to a particular technological environment or field of use. Specifically, it/they serve(s) to limit the application of the abstract idea to computerized environments (e.g., receive, capture, detect, generate, transmit, identify, etc. steps performed by computing device, processors, memory, payment gateway, customer device, digital communication network, etc.). This reasoning was demonstrated in Intellectual Ventures I LLC v. Capital One Bank (Fed. Cir. 2015), where the court determined "an abstract idea does not become nonabstract by limiting the invention to a particular field of use or technological environment, such as the Internet [or] a computer"). This/these limitation(s) do/does not impose any meaningful limits on practicing the abstract idea, and therefore do/does not integrate the abstract idea into a practical application (see MPEP 2106.05(h)).
The recited additional element(s) of obtaining, by one or more processors on a merchant device operatively coupled to a payment gateway, a checkout request for an order of an amount by a customer; receiving, by the one or more processors, an electronic checkout option selected by the customer; delivering, by the one or more processors, to a customer device, the checkout link for the customer via a link delivery method selected by the customer, wherein the customer device is operatively coupled to the payment gateway via the web page; and updating, by the one or more processors, a status of the payment of the amount requested with the checkout link with the payment gateway; receiving, by one or more processors on a customer device operated by a customer, a checkout link to a web page for the customer from a merchant device for a retail purchase, the web page being to process a payment of an amount of an order for the customer by an electronic checkout option; accessing, by the one or more processors, the web page led by the checkout link on a web browser of the customer device, the web page being operatively coupled to a payment gateway for the merchant device via a digital communication network;
obtaining, by the one or more processors, payment data from the customer interactively providing the payment data into input fields of the web page for processing the payment for the amount; receiving, by the one or more processors, a payment confirmation and a receipt from the payment gateway (Independent Claims 1, 8, and 15), additionally and/or alternatively simply append insignificant extra-solution activity to the judicial exception, (e.g., mere pre-solution activity, such as data gathering, in conjunction with an abstract idea). This/these limitation(s) do/does not impose any meaningful limits on practicing the abstract idea, and therefore do/does not integrate the abstract idea into a practical application. (See MPEP 2106.05(g)).
Dependent claims 2-7, 9-14, and 16-20 fail to include any additional elements. In other words, each of the limitations/elements recited in respective dependent claims is/are further part of the abstract idea as identified by the Examiner for each respective dependent claim (i.e., they are part of the abstract idea recited in each respective claim).
The Examiner has therefore determined that the additional elements, or combination of additional elements, do not integrate the abstract idea into a practical application. Accordingly, the claim(s) is/are directed to an abstract idea (Step 2A – Prong two: NO).
Step 2B: In step 2B, the claims are analyzed to determine whether any additional element, or combination of additional elements, is/are sufficient to ensure that the claims amount to significantly more than the judicial exception. This analysis is also termed a search for an "inventive concept." An "inventive concept" is furnished by an element or combination of elements that is recited in the claim in addition to (beyond) the judicial exception, and is sufficient to ensure that the claim as a whole amounts to significantly more than the judicial exception itself. Alice Corp., 134 S. Ct. at 2355, 110 USPQ2d at 1981 (citing Mayo, 566 U.S. at 72-73, 101 USPQ2d at 1966).
As discussed above in “Step 2A – Prong 2”, the identified additional elements in independent Claim(s) 1, 8, and 15, and dependent claims 2-7, 9-14, and 16-20 are equivalent to adding the words “apply it” on a generic computer, and/or generally link the use of the judicial exception to a particular technological environment or field of use. Therefore, the claims as a whole do not amount to significantly more than the judicial exception itself.
The recited additional element(s) of obtaining, by one or more processors on a merchant device operatively coupled to a payment gateway, a checkout request for an order of an amount by a customer; receiving, by the one or more processors, an electronic checkout option selected by the customer; delivering, by the one or more processors, to a customer device, the checkout link for the customer via a link delivery method selected by the customer, wherein the customer device is operatively coupled to the payment gateway via the web page; and updating, by the one or more processors, a status of the payment of the amount requested with the checkout link with the payment gateway; receiving, by one or more processors on a customer device operated by a customer, a checkout link to a web page for the customer from a merchant device for a retail purchase, the web page being to process a payment of an amount of an order for the customer by an electronic checkout option; accessing, by the one or more processors, the web page led by the checkout link on a web browser of the customer device, the web page being operatively coupled to a payment gateway for the merchant device via a digital communication network; obtaining, by the one or more processors, payment data from the customer interactively providing the payment data into input fields of the web page for processing the payment for the amount; receiving, by the one or more processors, a payment confirmation and a receipt from the payment gateway (Independent Claims 1, 8, and 15), additionally and/or alternatively simply append insignificant extra-solution activity to the judicial exception, (e.g., mere pre-solution activity, such as data gathering, in conjunction with an abstract idea) i.e. the claims recites the steps of obtaining a checkout request, receiving a selected electronic checkout option, delivering a checkout link via a selected delivery method, accessing a web page through a browser, interactively entering payment data into input fields, transmitting the payment data, and receiving a payment confirmation and receipt are routine and conventional actions that simply implement the abstract idea using generic computer and networking components. These steps amount to data gathering, data transmission, and post-solution activity, such as communicating results (payment confirmation and receipt), which is similar to “Receiving or transmitting data over a network, e.g., using the Internet to gather data”, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information), “Storing and retrieving information in memory”, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93; “Presenting offers to potential customers and gathering statistics generated based on the testing about how potential customers responded to the offers; the statistics are then used to calculate an optimized price”, OIP Technologies, 788 F.3d at 1363, 115 USPQ2d at 1092-93, Determining an estimated outcome and setting a price, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93, is a well-understood, routine, and conventional function when it is claimed in a merely generic manner (as it is here) (See MPEP 2106.05(d) (II)).
This conclusion is based on a factual determination. Applicant’s own disclosure at paragraph [0074] acknowledges that “all communication between the merchant device 110 and the payment gateway 150, including the checkout service 160, the customer service 170, the messaging service 180, and the event service 190, corresponding to respective blocks described herein indicate communication between software/hardware modules in accordance with an application programming interface (API) of the payment gateway 150, including but not limited to, call or any other invocation of a necessary module with a preconfigured parameter list and respective values corresponding to parameters of the parameter list. [0075] FIG. 3 is a flowchart 300 illustrating exemplary steps of the customer device in the omnichannel checkout system according to the present disclosure” (i.e., use of a merchant device, customer device, web browser, checkout link, web page, digital communication network, and payment gateway reflects generic computer implementation performing their ordinary functions; sending and receiving information, displaying web content, and processing electronic payments; without reciting any specialized hardware, unconventional data processing, or improvement to computer or network technology). This additional element therefore do not ensure the claim amounts to significantly more than the abstract idea.
Viewing the additional limitations in combination also shows that they fail to ensure the claims amount to significantly more than the abstract idea. When considered as an ordered combination, the additional components of the claims add nothing that is not already present when considered separately, and thus simply append the abstract idea with words equivalent to “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer or/and append the abstract idea with insignificant extra solution activity associated with the implementation of the judicial exception, (e.g., mere data gathering, post-solution activity) and/or simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception.
The dependent claims 2-7, 9-14, and 16-20 fail to include any additional elements. In other words, each of the limitations/elements recited in respective independent claims is/are further part of the abstract idea as identified by the Examiner for each respective dependent claim (i.e., they are part of the abstract idea recited in each respective claim).
Claims 2-7, 9-14, and 16-20 merely specify determining customer presence, identifying backordered items, setting payment due dates based on availability, offering deferred, installment, or recurring payment options, setting expiration timers for checkout links, updating payment status as paid or canceled based on timing, storing orders in a pending checkout list, delivering checkout links via common communication channels (email, SMS, messenger notifications, or QR codes), selecting among electronic currencies or digital wallet credits, synchronizing payment status between devices, and aligning payment timing with estimated delivery dates. The claims rely on standard timing mechanisms, routine conditional logic, conventional payment options, common communication formats, and ordinary record-keeping or synchronization steps, none of which recite a specific technical solution, specialized algorithm, or improvement to the functioning of a computer, network, or payment gateway. Instead, these limitations merely apply business rules, such as when payment is due, how long a checkout option remains valid, what payment methods are offered, and how transaction status is tracked to the abstract idea of facilitating a commercial transaction. Collectively, these dependent claims constitute well-understood, routine, and conventional activities performed by generic computer components and therefore fail to integrate the abstract commercial transaction concept into a practical application and it is recited at a high level of generality and does not integrate the judicial exception into a practical application.
The Examiner has therefore determined that no additional element, or combination of additional claims elements is/are sufficient to ensure the claim(s) amount to significantly more than the abstract idea identified above (Step 2B: NO).
Therefore, claims 1-20 are not eligible subject matter under 35 USC 101.
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 of this title, 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.
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 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:
Determining the scope and contents of the prior art.
Ascertaining the differences between the prior art and the claims at issue.
Resolving the level of ordinary skill in the pertinent art.
Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 4, 8-9, 11, and 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. 20210125165 (“Borden”) in view U.S. Pub. 20130246203 (“Laracey”).
As per claims 1 and 8, Borden discloses, obtaining, by one or more processors on a merchant device operatively coupled to a payment gateway, a checkout request for an order of an amount by a customer (Examiner interprets integration between a POS device and a purchaser’s personal device, and provides a system including server architecture hosting URL resources and a POS device, wherein the URL can be provided via an encoded URL such as a QR code) (“utilize the URL to allow for tight integration between a POS device, such as a POS terminal, and a personal device of the purchaser such as a smartphone, tablet, or wearable. The disclosed systems include a server architecture that hosts the resources identified by the URL, a POS device, and a system for providing the URL. In specific embodiment of the invention, the server architecture can be one or more servers hosting the resources identified by the URL. The system for providing the URL can be as simple as a piece of paper with an encoded URL, such as in the form of a QR code, to be scanned by an image sensor on the personal device”) (0004);
receiving, by the one or more processors, an electronic checkout option selected by the customer (Examiner interprets an electronic/remote checkout workflow initiated by the customer using the provided URL/QR. The “electronic checkout option” is reasonably interpreted as the customer choosing to complete payment via the URL/QR workflow instead of an alternative payment also discloses delivering a URL to the personal device (including via QR/SMS) enabling the customer to complete checkout electronically) (“providing the URL can alternatively or in combination include any form of networked communication that can be initiated by the server architecture and terminate with the delivery of the URL to the personal device. For example, the system could be a networked system for transmitting SMS messages to the personal device upon receiving instructions to do so from the POS terminal”) (0004);
generating, by the one or more processors, a checkout link to a web page for the customer to process a payment of the amount by the electronic checkout option (Examiner interprets providing a URL that routes the personal device to an order page / checkout page / payment page) (“providing the URL can alternatively or in combination include any form of networked communication that can be initiated by the server architecture and terminate with the delivery of the URL to the personal device. For example, the system could be a networked system for transmitting SMS messages to the personal device upon receiving instructions to do so from the POS terminal”) (0004), wherein the web page is operatively coupled to the payment gateway (“the user may scan the QR code with their personal device, and, upon successfully scanning the QR code, the customer's personal device will subsequently land on a checkout page, as represented in step 210, which can be similar to the payment pages disclosed elsewhere herein. The user can then enter credit card details and tip details or use another connected payment system accessible via the checkout page. In a next step 211, payment on the checkout page will either be successful, in which case the user's personal device will be redirected to a web receipt via step 212, or not, in which case the user can still pay using an alternative method, via step 208”) (0028-0031, also see 0029);
delivering, by the one or more processors, to a customer device, the checkout link for the customer via a link delivery method selected by the customer, wherein the customer device is operatively coupled to the payment gateway via the web page (Examiner notes that underlined limitation is disclosed by another reference.) (“user can use the built-in camera of their personal device to scan the QR code. At this point, the QR code 102 redirects the personal device 103 to a Web site which fetches the order contents from the server architecture using an encoding from the URL. In alternative embodiments, the order details are encoded as part of the URL itself in other embodiments. The order pages and payment pages disclosed herein can all be mobile optimized. The orders can be fetched on demand by the server architecture whenever the QR codes are scanned. Image 120 shows a payment page 104 for a user to complete the transaction … a scan-to-pay method in which a user scans an encoding, such as a QR code, in order to be taken to a payment page to authorize a payment for a transaction”) (0027-0028, also refer to 0030-0031);
and updating, by the one or more processors, a status of the payment of the amount requested with the checkout link with the payment gateway (Examiner interprets status update supported by disclosure that payment can be successful and the device is redirected to a web receipt; further supported by Borden’s explicit statement that server architecture can send trusted confirmation to POS device without additional POS processing) (“the user may scan the QR code with their personal device, and, upon successfully scanning the QR code, the customer's personal device will subsequently land on a checkout page, as represented in step 210, which can be similar to the payment pages disclosed elsewhere herein. The user can then enter credit card details and tip details or use another connected payment system accessible via the checkout page. In a next step 211, payment on the checkout page will either be successful, in which case the user's personal device will be redirected to a web receipt via step 212, or not, in which case the user can still pay using an alternative method, via step 208…”) (0028-0031).
Borden specifically doesn’t discloses, delivering, by the one or more processors, to a customer device, the checkout link for the customer via a link delivery method selected by the customer, however Laracey discloses, delivering, by the one or more processors, to a customer device, the checkout link for the customer via a link delivery method selected by the customer (“The application allows the customer to operate their mobile device to quickly and easily conduct payment transactions pursuant to the present invention. For phones or devices that are not capable of running such an application, a link or Web page may be created or provided to the customer that may be accessed via a mobile phone browser, so that the customer can conduct payment transactions pursuant to the present invention”) (0074).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention for obtaining, by one or more processors on a merchant device operatively coupled to a payment gateway, a checkout request for an order of an amount by a customer; receiving, by the one or more processors, an electronic checkout option selected by the customer; generating, by the one or more processors, a checkout link to a web page for the customer to process a payment of the amount by the electronic checkout option, wherein the web page is operatively coupled to the payment gateway and updating, by the one or more processors, a status of the payment of the amount requested with the checkout link with the payment gateway, as disclosed by Borden, delivering to a customer device, the checkout link for the customer via a link delivery method selected by the customer, as taught by Laracey for the purpose to ensure the customer can conduct the payment transaction even when the customer device cannot run the dedicated application, thereby improving device compatibility and reducing friction in the checkout process.
As per claims 2 and 9, Borden discloses, ascertaining that the customer is not present at a location of the merchant device but communicating with a merchant operating the merchant device (“The system for providing the URL can be as simple as a piece of paper with an encoded URL, such as in the form of a QR code, to be scanned by an image sensor on the personal device.”) (0004).
As per claims 4 and 11, Borden discloses, providing additional transaction services available from the electronic checkout option, the additional transaction services selected from the group consisting of a deferred payment, an installment payment, a recurring purchase, and combinations thereof (“the user may scan the QR code with their personal device, and, upon successfully scanning the QR code, the customer's personal device will subsequently land on a checkout page, as represented in step 210, which can be similar to the payment pages disclosed elsewhere herein. The user can then enter credit card details and tip details or use another connected payment system accessible via the checkout page. In a next step 211, payment on the checkout page will either be successful, in which case the user's personal device will be redirected to a web receipt via step 212, or not, in which case the user can still pay using an alternative method, via step 208”) (0028-0030).
As per claims 15, Borden discloses, receiving, by one or more processors on a customer device operated by a customer, a checkout link to a web page for the customer from a merchant device for a retail purchase, the web page being to process a payment of an amount of an order for the customer by an electronic checkout option (“utilize the URL to allow for tight integration between a POS device, such as a POS terminal, and a personal device of the purchaser such as a smartphone, tablet, or wearable. The disclosed systems include a server architecture that hosts the resources identified by the URL, a POS device, and a system for providing the URL. In specific embodiment of the invention, the server architecture can be one or more servers hosting the resources identified by the URL. The system for providing the URL can be as simple as a piece of paper with an encoded URL, such as in the form of a QR code, to be scanned by an image sensor on the personal device”) (0004);
accessing, by the one or more processors, the web page led by the checkout link on a web browser of the customer device (“providing the URL can alternatively or in combination include any form of networked communication that can be initiated by the server architecture and terminate with the delivery of the URL to the personal device. For example, the system could be a networked system for transmitting SMS messages to the personal device upon receiving instructions to do so from the POS terminal”) (0004), the web page being operatively coupled to a payment gateway for the merchant device via a digital communication network (“the user may scan the QR code with their personal device, and, upon successfully scanning the QR code, the customer's personal device will subsequently land on a checkout page, as represented in step 210, which can be similar to the payment pages disclosed elsewhere herein. The user can then enter credit card details and tip details or use another connected payment system accessible via the checkout page. In a next step 211, payment on the checkout page will either be successful, in which case the user's personal device will be redirected to a web receipt via step 212, or not, in which case the user can still pay using an alternative method, via step 208”) (0028-0031, also see 0029);
obtaining, by the one or more processors, payment data from the customer interactively providing the payment data into input fields of the web page for processing the payment for the amount (“user can use the built-in camera of their personal device to scan the QR code. At this point, the QR code 102 redirects the personal device 103 to a Web site which fetches the order contents from the server architecture using an encoding from the URL. In alternative embodiments, the order details are encoded as part of the URL itself in other embodiments. The order pages and payment pages disclosed herein can all be mobile optimized. The orders can be fetched on demand by the server architecture whenever the QR codes are scanned. Image 120 shows a payment page 104 for a user to complete the transaction … a scan-to-pay method in which a user scans an encoding, such as a QR code, in order to be taken to a payment page to authorize a payment for a transaction”) (0027-0028, also refer to 0030-0031);
receiving, by the one or more processors, a payment confirmation and a receipt from the payment gateway (“the user may scan the QR code with their personal device, and, upon successfully scanning the QR code, the customer's personal device will subsequently land on a checkout page, as represented in step 210, which can be similar to the payment pages disclosed elsewhere herein. The user can then enter credit card details and tip details or use another connected payment system accessible via the checkout page. In a next step 211, payment on the checkout page will either be successful, in which case the user's personal device will be redirected to a web receipt via step 212, or not, in which case the user can still pay using an alternative method, via step 208…” and “the URL could be generated and printed on a receipt such that it was inherently linked to that the transaction associated with the receipt. The links can be managed via transaction numbers issued by the POS device. The transaction number initialized by the POS device could be encoded with the URL when it was provided to the customer”) (0028-0031 and 0019).
Borden specifically doesn’t disclose, sending, by the one or more processors, the payment data for the electronic checkout option to the payment gateway, however Laracey discloses, sending, by the one or more processors, the payment data for the electronic checkout option to the payment gateway (“The application allows the customer to operate their mobile device to quickly and easily conduct payment transactions pursuant to the present invention. For phones or devices that are not capable of running such an application, a link or Web page may be created or provided to the customer that may be accessed via a mobile phone browser, so that the customer can conduct payment transactions pursuant to the present invention”) (0074).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention for receiving a checkout link to a web page for the customer from a merchant device for a retail purchase, the web page being to process a payment of an amount of an order for the customer by an electronic checkout option, accessing the web page led by the checkout link on a web browser of the customer device, the web page being operatively coupled to a payment gateway for the merchant device via a digital communication network, obtaining payment data from the customer interactively providing the payment data into input fields of the web page for processing the payment for the amount, receiving a payment confirmation and a receipt from the payment gateway, as disclosed by Borden, sending, by the one or more processors, the payment data for the electronic checkout option to the payment gateway, as taught by Laracey for the purpose to ensure the customer can conduct the payment transaction even when the customer device cannot run the dedicated application, thereby improving device compatibility and reducing friction in the checkout process.
As per claims 16, Borden discloses, wherein the checkout link to the web page for the order of the customer is in a form of Uniform Resource Locator (URL) to the web page for the electronic checkout option embedded in an email message, a short message service message, or a messenger app notification, as selected by the customer (“The server architecture can then send an SMS message to the customer with a URL embedded in the message in step 508. Subsequently, the purchaser and merchant can create the purchase order for the user with reference to the customer's name in step 509. When the customer is ready to pay, the customer can click on a link in the SMS message in step 510. The personal device can then be routed to a payment page by a URL in the link in the SMS message which is associated with the purchase order and transaction that the server architecture initially created, in step 511. The customer can then complete checkout on the payment page in step 512. Finally, the server architecture can notify the merchant that the transaction has settled, in step 513. The notification can be provided to the merchant through the standard order fulfillment workflow of the POS device”) (0032).
As per claims 17, Borden discloses, wherein the checkout link to the web page for the order of the customer is in a form of Quick Response (QR) code encoding a Uniform Resource Locator (URL) to the web page for the electronic checkout option for optical input for the customer device (“The customer can then either scan (if the encoded URL is in a QR code) or tap (if the encoded URL is in an RFID tag) to obtain the encoded URL from the advertisement in step 503. In a next step 504, the personal device of the user is routed to an order page. The order page can be similar to the order pages described herein (e.g., it can allow a user to enter identifying information to serve as the basis for a future order, or it can allow the user to directly modify their purchase order)”) (0032).
As per claims 18, Borden discloses, wherein the web page includes electronic currencies and digital wallet credits as available sources of fund to pay for the order (“The information is extracted and passed to a process for connecting to the POS device. Then post payment order management is completed and the payment/order status is synced to the POS device”) (0030), and wherein the payment data from the customer selects a source of fund amongst the electronic currencies and the digital wallet credits (“the order page includes a request for the customer to authorize a purchase order creation which is backed by a method of payment (e.g., an electronic wallet or credit card) in step 505. For example, the user could enter their Google Pay credentials. In a next step 506, the server architecture receives a payment token, customer name, and phone number from the payment system. This information can be provided from the electronic wallet after the user provides their credentials to the payment system, or it can be provided on the order page directly from the user. Next, in step 507, the server architecture creates a transaction and purchase order with the customer's name. The server architecture can then send an SMS message to the customer with a URL embedded in the message in step 508. Subsequently, the purchaser and merchant can create the purchase order for the user with reference to the customer's name in step 509. When the customer is ready to pay, the customer can click on a link in the SMS message in step 510”) (0032).
As per claims 19, Borden discloses, wherein a status of the payment available for the merchant device is automatically synchronized with the customer device via the payment gateway subsequent to the payment confirmation and the receipt became available to the customer device (“the server architecture can administrate both the request and receipt of the payment approval for a payment authorization request originating on the personal device and send a trusted confirmation of payment authorization to the POS device without requiring the POS device to conduct any additional processing steps. In specific embodiments of the invention, the integration with the POS device allows for any input on the personal device to have a direct and seamless impact on any transaction origination and processing workflow already in use on the POS device … purchase order for the initialized transaction could automatically show up on the restaurant's POS system as a food order that required fulfillment”) (0016-0017).
Claims 3, 7, 10, 14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. 20210125165 (“Borden”) in view U.S. Pub. 20130246203 (“Laracey”) in view U.S. Pat. 11321726 (“Pandhi”).
As per claims 3 and 10, Borden specifically doesn’t discloses, ascertaining that the order includes an item to be backordered, wherein the electronic checkout option indicates that the amount is due by the time the item backordered would be available for the customer, however Pandhi discloses, ascertaining that the order includes an item to be backordered, wherein the electronic checkout option indicates that the amount is due by the time the item backordered would be available for the customer (“service provider 1312 can provide omni-channel fulfillment services. For instance, if a buyer places an order with a seller and the seller cannot fulfill the order because one or more items are out of stock or otherwise unavailable, the service provider 1312 can leverage other sellers and/or sales channels that are part of the platform of the service provider 1312 to fulfill the buyer's order. That is, another seller can provide the one or more items to fulfill the order of the buyer.”) (Col. 39 Ln. 7-15).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention for obtaining, by one or more processors on a merchant device operatively coupled to a payment gateway, a checkout request for an order of an amount by a customer; receiving, by the one or more processors, an electronic checkout option selected by the customer; generating, by the one or more processors, a checkout link to a web page for the customer to process a payment of the amount by the electronic checkout option, wherein the web page is operatively coupled to the payment gateway and updating, by the one or more processors, a status of the payment of the amount requested with the checkout link with the payment gateway, as disclosed by Borden, ascertaining that the order includes an item to be backordered, wherein the electronic checkout option indicates that the amount is due by the time the item backordered would be available for the customer, as taught by Pandhi for the purpose to leverage alternate sellers/channels when items are out of stock (i.e. backordered/availability management).
As per claims 7 and 14, Borden specifically doesn’t discloses, ascertaining that the order includes an item to be backordered, wherein the electronic checkout option indicates that the amount is due by the time the item being backordered would be available for the customer, however Pandhi discloses, ascertaining that the order includes an item to be backordered, wherein the electronic checkout option indicates that the amount is due by the time the item being backordered would be available for the customer (“service provider 1312 can provide omni-channel fulfillment services. For instance, if a buyer places an order with a seller and the seller cannot fulfill the order because one or more items are out of stock or otherwise unavailable, the service provider 1312 can leverage other sellers and/or sales channels that are part of the platform of the service provider 1312 to fulfill the buyer's order. That is, another seller can provide the one or more items to fulfill the order of the buyer.”) (Col. 39 Ln. 7-15);
setting a due date no sooner than an estimated delivery date of the item being backordered by setting a deferred payment service with the electronic checkout option (“provide omni-channel fulfillment services. For instance, if a buyer places an order with a seller and the seller cannot fulfill the order because one or more items are out of stock or otherwise unavailable, the service provider 1312 can leverage other sellers and/or sales channels that are part of the platform of the service provider 1312 to fulfill the buyer's order. That is, another seller can provide the one or more items to fulfill the order of the buyer. Furthermore, in some examples, another sales channel (e.g., online, brick-and-mortar, etc.) can be used to fulfill the order of the buyer”) (Col. 39 Ln. 7-17);
and storing the order in a pending checkout list of the merchant device (“the buyer 102 can access one or more services of the service provider via the application. As an example, the buyer 102 can access rewards, loyalty, invoices (e.g., paid/unpaid), receipts, orders (e.g., fulfilled/unfulfilled), account information (e.g., funds associated therewith), and the like. In at least one example, the buyer user interface 108 can present a digital invoice to the buyer 102, to enable the buyer 102 to tender payment for the invoice via interaction with the buyer user interface 108” and “the service provider 1312 can provide omni-channel fulfillment services. For instance, if a buyer places an order with a seller and the seller cannot fulfill the order because one or more items are out of stock or otherwise unavailable, the service provider 1312 can leverage other sellers and/or sales channels that are part of the platform of the service provider 1312 to fulfill the buyer's order. That is, another seller can provide the one or more items to fulfill the order of the buyer. Furthermore, in some examples, another sales channel (e.g., online, brick-and-mortar, etc.) can be used to fulfill the order of the buyer”) (Col. 6 Ln. 24-33 and Col. 39 Ln. 7-17).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention for obtaining, by one or more processors on a merchant device operatively coupled to a payment gateway, a checkout request for an order of an amount by a customer; receiving, by the one or more processors, an electronic checkout option selected by the customer; generating, by the one or more processors, a checkout link to a web page for the customer to process a payment of the amount by the electronic checkout option, wherein the web page is operatively coupled to the payment gateway and updating, by the one or more processors, a status of the payment of the amount requested with the checkout link with the payment gateway, as disclosed by Borden, setting an expiration timer for the checkout link for a window during which the customer can process the payment; and based on ascertaining that the payment has been posted prior to the expiration timer of the checkout link runs out, updating the status of the payment of the amount requested with the checkout link with the payment gateway as being paid on the merchant device, as taught by Pandhi for the purpose to leverage alternate sellers/channels when items are out of stock (i.e. backordered/availability management).
As per claims 20, Borden specifically doesn’t disclose, wherein the checkout link is set with a due date no sooner than an estimated delivery date of any item being backordered, however Pandhi discloses, wherein the checkout link is set with a due date no sooner than an estimated delivery date of any item being backordered (“service provider 1312 can provide omni-channel fulfillment services. For instance, if a buyer places an order with a seller and the seller cannot fulfill the order because one or more items are out of stock or otherwise unavailable, the service provider 1312 can leverage other sellers and/or sales channels that are part of the platform of the service provider 1312 to fulfill the buyer's order. That is, another seller can provide the one or more items to fulfill the order of the buyer.”) (Col. 39 Ln. 7-15).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention for obtaining, by one or more processors on a merchant device operatively coupled to a payment gateway, a checkout request for an order of an amount by a customer; receiving, by the one or more processors, an electronic checkout option selected by the customer; generating, by the one or more processors, a checkout link to a web page for the customer to process a payment of the amount by the electronic checkout option, wherein the web page is operatively coupled to the payment gateway and updating, by the one or more processors, a status of the payment of the amount requested with the checkout link with the payment gateway, as disclosed by Borden, wherein the checkout link is set with a due date no sooner than an estimated delivery date of any item being backordered, as taught by Pandhi for the purpose to leverage alternate sellers/channels when items are out of stock (i.e. backordered/availability management).
Claims 5-6 and 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. 20210125165 (“Borden”) in view U.S. Pub. 20130246203 (“Laracey”) in view U.S. Pub. 20200210991 (“Bernholc”).
As per claims 5 and 12, Borden specifically doesn’t discloses, setting an expiration timer for the checkout link for a window during which the customer can process the payment and based on ascertaining that the payment has been posted prior to the expiration timer of the checkout link runs out, updating the status of the payment of the amount requested with the checkout link with the payment gateway as being paid on the merchant device, however Bernholc discloses, setting an expiration timer for the checkout link for a window during which the customer can process the payment (“The controller 12 compares the payment-facilitating information with previously received payment-facilitating information to identify any timer already associated with the payment-facilitating information. Upon identification of the timer that was started in step S93, the controller 12 restarts the timer in step S96, whereby the time window for product selection is extended. The controller 12 also identifies and registers the product associated with the tapped antenna 20d, and adds the product to the virtual shopping cart by associating the product with the payment-facilitating information. In step S97, the timer expires and, in response thereto, the controller 12 initiates the financial transaction by, in step S98, sending the payment-facilitating information together with product related information related to all the registered products (i.e., all products in the virtual shopping cart) to the backend payment system 40. In order to allow all products to be paid through a single financial transaction, the product related information sent to the backend system 40 should comprise the total price of the registered products, or at least information from which the total price of the products can be derived by the backend payment system 40.”) (0107);
and based on ascertaining that the payment has been posted prior to the expiration timer of the checkout link runs out, updating the status of the payment of the amount requested with the checkout link with the payment gateway as being paid on the merchant device (“a single financial transaction including electronic payment of products associated with antennas that have been tapped is initiated upon timeout or expiry of a timer. In this case, a first tap of an antenna by a portable payment device causes the payment processor 10 to open up a time window for product selection by starting a timer. If the same antenna or another antenna of the POS system is tapped with the same payment device before the time window closes (i.e., before expiry of the timer), the timer is restarted and so the time window is extended. When the timer finally expires, the payment processor 10 is configured to initiate a single electronic payment of all products associated with an antenna that has been tapped by the portable payment device within the time window”) (0106-0107).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention for obtaining, by one or more processors on a merchant device operatively coupled to a payment gateway, a checkout request for an order of an amount by a customer; receiving, by the one or more processors, an electronic checkout option selected by the customer; generating, by the one or more processors, a checkout link to a web page for the customer to process a payment of the amount by the electronic checkout option, wherein the web page is operatively coupled to the payment gateway and updating, by the one or more processors, a status of the payment of the amount requested with the checkout link with the payment gateway, as disclosed by Borden, setting an expiration timer for the checkout link for a window during which the customer can process the payment and based on ascertaining that the payment has been posted prior to the expiration timer of the checkout link runs out, updating the status of the payment of the amount requested with the checkout link with the payment gateway as being paid on the merchant device, as taught by Bernholc for the purpose to controlling the validity of payment-facilitating information via a timer thus applying a similar expiration control to checkout links prevents outdated or intercepted links from being used outside an intended time window, a known concern in electronic payment systems.
As per claims 6 and 13, Borden specifically doesn’t discloses, setting an expiration timer for the checkout link for a window during which the customer can process the payment and based on ascertaining that the expiration timer of the checkout link had run out, updating the status of the payment of the amount requested with the checkout link with the payment gateway as being canceled on the merchant device, however Bernholc discloses, setting an expiration timer for the checkout link for a window during which the customer can process the payment (“a single financial transaction including electronic payment of products associated with antennas that have been tapped is initiated upon timeout or expiry of a timer. In this case, a first tap of an antenna by a portable payment device causes the payment processor 10 to open up a time window for product selection by starting a timer. If the same antenna or another antenna of the POS system is tapped with the same payment device before the time window closes (i.e., before expiry of the timer), the timer is restarted and so the time window is extended. When the timer finally expires, the payment processor 10 is configured to initiate a single electronic payment of all products associated with an antenna that has been tapped by the portable payment device within the time window”) (0106-0107);
and based on ascertaining that the expiration timer of the checkout link had run out (“when the timer finally expires, the payment processor 10 is configured to initiate a single electronic payment of all products associated with an antenna that has been tapped by the portable payment device within the time window (i.e. since the timer was first started). In this way, only one financial transaction has to be performed no matter the number of products purchased by the customer”) (0106), updating the status of the payment of the amount requested with the checkout link with the payment gateway as being canceled on the merchant device (“the timer expires and, in response thereto, the controller 12 initiates the financial transaction by, in step S98, sending the payment-facilitating information together with product related information related to all the registered products (i.e., all products in the virtual shopping cart) to the backend payment system 40. In order to allow all products to be paid through a single financial transaction, the product related information sent to the backend system 40 should comprise the total price of the registered products, or at least information from which the total price of the products can be derived by the backend payment system”) (0107).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention for obtaining, by one or more processors on a merchant device operatively coupled to a payment gateway, a checkout request for an order of an amount by a customer; receiving, by the one or more processors, an electronic checkout option selected by the customer; generating, by the one or more processors, a checkout link to a web page for the customer to process a payment of the amount by the electronic checkout option, wherein the web page is operatively coupled to the payment gateway and updating, by the one or more processors, a status of the payment of the amount requested with the checkout link with the payment gateway, as disclosed by Borden, setting an expiration timer for the checkout link for a window during which the customer can process the payment and based on ascertaining that the expiration timer of the checkout link had run out, updating the status of the payment of the amount requested with the checkout link with the payment gateway as being canceled on the merchant device, as taught by Bernholc for the purpose to controlling the validity of payment-facilitating information via a timer thus applying a similar expiration control to checkout links prevents outdated or intercepted links from being used outside an intended time window, a known concern in electronic payment systems.
Conclusion
25. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US. Pat. 20240191448 (“High”).
High discloses, a method for determining item availability are provided. A computer implemented method for determining item availability in a shopping space comprising: receiving a request for an item for purchase, instructing a motorized transport unit to travel to a display space in the shopping space corresponding to the item for the purchase, determining whether the item is available in the display space based on information captured by one or more sensors of the motorized transport unit, and in an event that the item for purchase is not available in the display space: determining an item unavailable response to present to the customer.
26. Any inquiry concerning this communication or earlier communications from the examiner should be directed to GAUTAM UBALE whose telephone number is (571)272-9861. The examiner can normally be reached Mon-Fri. 7:00 AM- 6:30 PM PST.
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, Marissa Thein can be reached at (571) 272-6764. 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.
/GAUTAM UBALE/
Primary Examiner, Art Unit 3689