DETAILED ACTION
This is a Final Office action is in response to communications filed on May 12th, 2026. Claims 1, 8, 15, and 19 are amended. Claim 1-20 have been examined in this application. The Information Disclosure Statement (IDS) filed on January 20th, 2026 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;
presenting, via a display of the merchant device, payment options for the order, wherein the payment options include an electronic checkout option;
receiving, by the one or more processors of the merchant device, a first selection by the customer corresponding to a selection of the electronic checkout option;
in response to receiving the first selection, presenting, via the display of the merchant device, a plurality of link delivery methods associated with the electronic checkout option;
receiving, by the one or more processors of the merchant device, a second selection corresponding to a selection of a link delivery method of the plurality of link delivery methods;
in response to receiving the second selection, generating, by the one or more processors of the merchant device, a checkout link to a web page based on the selected link delivery method, wherein the web page is provided by a checkout service of payment gateway;
delivering, by the one or more processors, to a customer device, the checkout link for the customer via the selected link delivery method of the plurality of link delivery methods, 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 via 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, wherein the checkout link is received according to a link delivery method selected via the merchant device from among a plurality of link delivery methods, wherein the web page is provided by a checkout service of a payment gateway configured to process a payment of an amount of the retail purchase;
accessing, by the one or more processors on the customer device, 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 on the customer device, payment data from the customer interactively providing the payment data into input fields of the web page for processing the payment for the amount of the retail purchase;
sending, by the one or more processors on the customer device, the payment data for the electronic checkout option to the payment gateway;
receiving, by the one or more processors on the customer device, 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 independent claims 1 and 8 recite the abstract idea of facilitating a commercial payment transaction, specifically organizing interactions between a merchant and a customer to complete payment through an electronically delivered checkout link. The claims recite presenting payment options, receiving a selection of an electronic checkout option, presenting available checkout link delivery methods, receiving a selection of a delivery method, generating and delivering the checkout link according to the selected method, and updating payment status. Collectively, these limitations concern the selection of payment and communication options, transmission of payment information, and recording of a transaction result, which constitute commercial interactions and fundamental economic practices falling within “Certain Methods of Organizing Human Activity”. The ordered presentation and selection of an electronic checkout option and a link delivery method do not alter the character of the abstract idea. These limitations merely prescribe the commercial and informational sequence by which the merchant and customer select how the payment request will be communicated and completed.
Further, the independent claim 15 similarly recites the abstract idea of conducting a retail payment transaction through electronic information exchange. Claim 15 recites receiving a checkout link according to a delivery method selected through the merchant device, accessing a checkout webpage, obtaining and transmitting customer payment information, and receiving payment confirmation and a receipt. These limitations describe collecting, transmitting, and processing payment information and communicating the results of a commercial transaction, which are longstanding commercial practices performed in an electronic environment, 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 steps of obtaining a checkout request, presenting payment options, receiving a first selection of an electronic-checkout option, presenting link-delivery methods, receiving a second selection of a link delivery method, generating and delivering a checkout link according to the selected method, receiving the checkout link on the customer device, accessing the linked webpage, and obtaining payment data through the webpage merely constitute pre-solution data-gathering and preparatory activity. These steps collect, present, and communicate the transaction information, customer selections, delivery channel selection, and payment information used to perform the abstract process of conducting and managing a commercial payment transaction. The subsequent steps of transmitting the payment data, updating the payment status, receiving a payment confirmation and receipt, displaying a paid or canceled status, and synchronizing the payment status between the merchant and customer devices merely constitute post-solution activity that communicates, records, or displays the result of the abstract commercial payment process. Similarly, determining customer location, identifying backordered items, identifying estimated delivery dates, setting payment due or expiration dates, selecting funding sources, and storing orders in a pending checkout list merely gather, organize, or store information used in administering the commercial transaction. Accordingly, to the extent these input, presentation, selection, link generation, transmission, storage, and status output limitations are considered additional elements, they merely append insignificant pre-solution data gathering and post-solution output presentation to the judicial exception, and 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) obtaining a checkout request, presenting payment and delivery options, receiving customer or merchant selections, generating a URL or QR-based checkout link, receiving and accessing the link, obtaining payment data, determining customer location or item availability, selecting funding sources, setting due dates or expiration periods, and storing an order in a pending-checkout list merely collect, receive, organize, and store the information used to conduct and administer the abstract commercial transaction (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 steps of transmitting payment information, processing the payment through the gateway, receiving a confirmation or receipt, updating the payment as paid or canceled, and synchronizing payment status between the merchant and customer devices merely transmit, record, and present the result of the abstract payment transaction. 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, 4, 8, 11, and 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. 20190205859 (“Torres”) in view U.S. Pat. 11100490 (“Doyle”).
As per claims 1 and 8, Torres 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 that Torres discloses a sales-associate application executing on a sales-associate mobile device that maintains a virtual shopping bag identifying the items, prices, taxes, discounts, and total amount of the customer’s order. The sales associate selects a displayed “checkout” button to initiate the checkout process. More particularly, the sales-associate application determines the total price, receives selection of the checkout button, and sends the order details, customer identity, store location, and amount to the payment server. Torres’s merchant device is operatively coupled to the payment-gateway service through the payment server) (0051-0053, 0069-0075, 0081-0083, 0095-0096; Figs. 5, 6, and 13);
presenting, via a display of the merchant device, payment options for the order, wherein the payment options include an electronic checkout option (Examiner interprets that Torres discloses displaying payment options on the sales-associate device, including cash, check, gift card, manually entered credit card, and an electronic “NewStore Checkout” option. Torres explains that “the sales associate app prompts the sales associate to select the payment option for the customer, such as cash or gift card,” and that one of the available options is “NewStore Checkout.” The sales associate selects the NewStore Checkout option. Torres also discloses a split-payment option in which payment is divided among different payment instruments, such as a gift card and credit card) (“ales associate app prompts the sales associate to select the payment option for the customer, such as cash or gift card. One of these options is sometimes referred to by the present applicant as “NewStore Checkout,” which corresponds to one or more of the embodiments described herein. The sales associate chooses the “NewStore Checkout” option in this example. An example screenshot 60 of the display on the sales associate phone 100 in this step is illustrated in FIG. 6. In some embodiments, the sales associate app can allow the sales associate to select a “split payment” option where customer payment is split between different payment instruments (e.g., gift card and credit card)”) (0052, 0082, Fig. 6);
receiving, by the one or more processors of the merchant device, a first selection by the customer corresponding to a selection of the electronic checkout option (Examiner interprets Torres discloses that the sales-associate application determines which displayed payment option was selected and, when NewStore Checkout is selected, proceeds with the electronic-checkout process. Specifically, if NewStore Checkout is selected in step 1306, the process proceeds to step 1312, where the sales-associate application sends the order details to the payment server. The payment server generates a unique Payment ID corresponding to the customer’s order and sends the Payment ID to the sales-associate application) (“the sales associate app determines which payment option was selected in step 1306. If a payment option other than NewStore Checkout was selected in step 1306, the flow chart 1300 proceeds to step 1310 where the corresponding payment flow occurs, which is not further described in this application. If NewStore Checkout was selected in step 1306, the flow chart 1300 proceeds to step 1312 where the sales associate app sends all order details (e.g., the items to be purchased, the customer's identity, store location, etc.) to the payment server (e.g., payment server 130). The payment server receives the order details and generates a unique Payment ID that corresponds to the customer's order and customer information in step 1314. In step 1316, the payment server sends the Payment ID to the sales associate app on the sales associate's mobile device where it is received”) (0083; Fig. 13, steps 1306-1312);
in response to receiving the first selection, presenting, via the display of the merchant device, a plurality of link delivery methods associated with the electronic checkout option (Examiner interprets that after determining that NewStore Checkout was selected, Torres discloses that the merchant application receives a unique Payment ID, generates a checkout URL containing the Payment ID, presents the URL as a QR code, and provides alternatives for sending the URL by text message, email, or another medium. Figure 7 specifically displays the QR-code option and a selectable “Send link via message” option. Torres states that “the sales associate app generates a link (e.g., a URL) to the payment server that includes the Payment ID,” encodes the link as a QR code, and may also provide an option to send the link by text message, email, or another medium) (“the sales associate app generates a link (e.g., a URL) to the payment server that includes the Payment ID received in step 1316. The link is then encoded in as a QR code, which the sales associate app generates and displays in step 1318. The sales associate app can also provide an option to send the link via text message, email, or another medium, for example if the customer mobile device does not include a QR code reader”) (0084 and 0089; Figs. 7 and 14-15);
receiving, by the one or more processors of the merchant device, a second selection corresponding to a selection of a link delivery method of the plurality of link delivery methods (Torres discloses that the customer informs the sales associate whether the Payment-ID link should be delivered optically through a QR code or through a text message, email, or another medium. Torres further discloses that, when text-message delivery is selected, the merchant application presents a field for entering the customer’s mobile telephone number and sends the URL using the selected text-message delivery method) (“sending the link (e.g., via text message), in step 1322 the sales associate shows the QR code displayed on the sales associate mobile device to the customer for scanning with a QR code reader on the customer mobile device. The QR code includes a link to the payment server to retrieve the customer order details. If the sales associate selects text messaging to deliver the link to the customer, in step 1326 the sales associate app displays a text field where the sales associate (or the customer) enters the customer's mobile phone number. Alternatively, the customer payment app can display a text field to enter the customer's mobile phone number, which is then provided to the sales associate app …”) (0085 and 0089; Fig. 14, steps 1326-1328, Fig. 15, step 1504);
in response to receiving the second selection, generating, by the one or more processors of the merchant device, a checkout link to a web page based on the selected link delivery method (Examiner notes that the underlined limitation is disclosed by another prior art. Examiner interprets Torres discloses generating a URL containing the unique Payment ID and providing the URL in a form corresponding to the selected delivery method. For optical delivery, the application encodes the URL in a QR code and displays the QR code. For text-message or email delivery, the application incorporates the URL into the selected electronic message) (0056, 0058, 0084-0085, and 0089-0090), wherein the web page is provided by a checkout service of payment gateway (Torres discloses that the URL directs the customer’s browser to payment server 130; the browser downloads and executes the customer payment application from payment server 130; the payment server receives the customer’s payment data; and the payment server sends the payment information to payment-gateway service 140 for processing and authorization) (0059-0061, 0069-0073, 0091-0096);
delivering, by the one or more processors, to a customer device, the checkout link for the customer via the selected link delivery method of the plurality of link delivery methods (Torres discloses displaying the QR code on the merchant device for optical capture by the customer device or sending an SMS or email containing the checkout URL to the customer device) (0056-0058, 0084-0085, 0089-0090), wherein the customer device is operatively coupled to the payment gateway via the web page (Torres discloses that the customer device opens the selected URL in a web browser, executes the customer payment application, retrieves the order information, obtains customer payment data, and transmits encrypted payment data to the payment server. The payment server subsequently transmits the payment data to the payment-gateway service for processing and authorization) (0058-0070, 0090-0095);
and updating, by the one or more processors, a status of the payment of the amount requested with the checkout link via the payment gateway (Torres discloses that the payment-gateway service returns a successful or failed payment authorization to the payment server. The payment server stores the authorization with the customer’s order and sends the result to both the customer payment application and the sales-associate application. The customer device and merchant device then display the corresponding successful or unsuccessful payment status. Torres also teaches that the merchant device may receive a push notification or periodically poll the payment server to determine whether payment has been completed) (0053, 0070-0076, 0095-0096, 0075).
Torres specifically doesn’t discloses, generating, by the one or more processors of the merchant device, a checkout link to a web page based on the selected link delivery method, however Doyle discloses, generating, by the one or more processors of the merchant device, a checkout link to a web page based on the selected link delivery method, wherein the web page is provided by a checkout service of the payment gateway (Examiner interprets Doyle, however, teaches that a transaction code may be generated based on transaction data, dynamically generated and specific to the transaction, associated with a URL or deep link, and delivered to the customer through a text message, email, in-app notification, instant application, or similar delivery channel. The phrase “generating … a checkout link … based on the selected link delivery method” does not require the underlying destination address to be different for every delivery channel. Under the broadest reasonable interpretation, it is met when the merchant device generates the link in a delivery-specific form-such as a QR encoded URL for optical delivery or a message-embedded URL for SMS or email delivery. To the extent that Torres distinguishes payment server 130 from payment-gateway service 140, Doyle also teaches an integrated checkout and payment-gateway architecture. Doyle discloses a payment-processing platform integrated with a P2P payment platform through an API; a gateway that receives a request to begin a transaction; a transaction code corresponding to authorization data, such as a URL or token; a notifier configured to provide updates to merchant and customer devices; and gateway, notifier, and payment-processing components that may be components of the payment-processing server, also see col. 21, ln. 19-65; col. 22, ln. 1-35; Doyle further teaches a POS application causing a text message containing a resource locator associated with a payment platform to be sent to a customer device, wherein interaction with the resource locator triggers API communications between the payment platform and the payment-processing platform. See Doyle, col. 4, ln. 49-67; col. 5, ln. 1-10) (col. 15, ln. 15-33; col. 16, ln. 6-33; col. 17, ln. 18-33).
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, presenting, via a display of the merchant device, payment options for the order, wherein the payment options include an electronic checkout option, receiving, by the one or more processors of the merchant device, a first selection by the customer corresponding to a selection of the electronic checkout option, in response to receiving the first selection, presenting, via the display of the merchant device, a plurality of link delivery methods associated with the electronic checkout option, receiving, by the one or more processors of the merchant device, a second selection corresponding to a selection of a link delivery method of the plurality of link delivery methods, in response to receiving the second selection, generating, by the one or more processors of the merchant device, a checkout link to a web page based on the selected link delivery method, wherein the web page is provided by a checkout service of payment gateway, as disclosed by Torres, generating, by the one or more processors of the merchant device, a checkout link to a web page based on the selected link delivery method, as taught by Doyle for the purpose to employ transaction-specific resource locator and integrated payment-gateway architecture to associate the selected checkout link with the particular transaction, facilitate secure payment through the selected delivery channel, and consistently update the customer and merchant devices when the payment is completed.
As per claims 4 and 11, Torres 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 (Torres discloses that the customer order may include or encode a cost identifying: a total-product cost; a payment-installment cost; and a down-payment cost. Torres also discloses a split-payment option in which payment is divided between different payment methods or instruments, such as a gift card and credit card i.e. Torres’s disclosure of a “payment installment cost” included in the electronic-checkout order request as indicating that the NewStore Checkout process supports an installment-payment transaction arrangement.) (0086, 0052, 0062).
As per claims 15, Torres 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 (Examiner interprets that Torres generates a URL containing a unique Payment ID and delivers the URL to the customer device by QR code, text message, or email. The customer receives and opens the delivered URL) (0056-0059, 0084-0090; Figs. 7, and 14-15),
wherein the checkout link is received according to a link delivery method selected via the merchant device from among a plurality of link delivery methods (Examiner interprets that Torres provides QR-code, text-message, email, or another-medium delivery. The customer informs the sales associate which method to use, and the merchant application receives the selection and implements that delivery method) (0084-0090, Figs. 14-15),
accessing, by the one or more processors on the customer device, the web page led by the checkout link on a web browser of the customer device, the web page being operatively coupled to the payment gateway for the merchant device via a digital communication network (Examiner notes that the underlined limitation is disclosed by another prior art. Examiner interprets the QR-decoded or message-embedded URL opens in the browser of the customer device. The browser downloads and executes the customer payment application) (0057-0060, 0089-0091);
obtaining, by the one or more processors on the customer device, payment data from the customer interactively providing the payment data into input fields of the web page for processing the payment for the amount of the retail purchase (Examiner interprets that the browser-based payment application displays available payment methods, allows the customer to select a stored payment method, permits manual payment-data entry, and obtains authentication and contact information) (0061-0068, 0091-0094, Figs. 9-11 and 15-17);
sending, by the one or more processors on the customer device, the payment data for the electronic checkout option to the payment gateway (Torres discloses that the customer application sends encrypted payment data and the Payment ID to payment server 130, which sends the encrypted data and transaction amount to payment-gateway service 140) (0069-0072 and 0094-0095);
receiving, by the one or more processors on the customer device, a payment confirmation and a receipt from the payment gateway (Examiner notes that the underlined limitation is disclosed by another prior art. Examiner interprets Torres discloses that, after authorization and submission, the transaction server causes an email or text receipt to be generated and delivered to the customer) (0078).
Torres discloses, that the URL opens a customer payment application supplied by payment server and receives payment data and submits it to payment-gateway service, but specifically doesn’t disclose, wherein the web page is provided by a checkout service of a payment gateway configured to process a payment of an amount of the retail purchase, the web page being operatively coupled to the payment gateway for the merchant device via a digital communication network, and a receipt from the payment gateway, however Doyle discloses, wherein the web page is provided by a checkout service of a payment gateway configured to process a payment of an amount of the retail purchase (Examiner interprets Doyle supplies the integrated gateway architecture. Doyle discloses a gateway, notifier, payment-processing component, and payment-processing server, wherein the gateway and notifier may be components of the payment-processing server. The gateway receives a request to begin a transaction and communicates with an integrated P2P payment platform through an API) (col. 21, ln. 16-35; col. 22, ln. 1-65; Fig. 2B),
the web page being operatively coupled to the payment gateway for the merchant device via a digital communication network (Doyle further teaches API communications among the customer mobile-payment platform, gateway, notifier, payment-processing server, and merchant POS application) (col. 21, ln. 16-35; col. 22, ln. 1-65),
and a receipt from the payment gateway (Doyle discloses a digital-receipt user interface containing transaction and payment information and further teaches that the gateway, notifier, and payment-processing components may be integrated components of the payment-processing server) (col. 17, ln. 5-15; col. 21, ln. 1-15; col. 22, ln. 1-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, presenting, via a display of the merchant device, payment options for the order, wherein the payment options include an electronic checkout option, receiving, by the one or more processors of the merchant device, a first selection by the customer corresponding to a selection of the electronic checkout option, in response to receiving the first selection, presenting, via the display of the merchant device, a plurality of link delivery methods associated with the electronic checkout option, receiving, by the one or more processors of the merchant device, a second selection corresponding to a selection of a link delivery method of the plurality of link delivery methods, in response to receiving the second selection, generating, by the one or more processors of the merchant device, a checkout link to a web page based on the selected link delivery method, wherein the web page is provided by a checkout service of payment gateway, as disclosed by Torres, wherein the web page is provided by a checkout service of a payment gateway configured to process a payment of an amount of the retail purchase, the web page being operatively coupled to the payment gateway for the merchant device via a digital communication network, and a receipt from the payment gateway, as taught by Doyle for the purpose to employ transaction-specific resource locator and integrated payment-gateway architecture to associate the selected checkout link with the particular transaction, facilitate secure payment through the selected delivery channel, and consistently update the customer and merchant devices when the payment is completed.
As per claims 16, Torres 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 (Torres generates a URL directed to payment server 130 and containing the unique Payment ID, and expressly embeds the URL in an email or text message sent to the customer’s device) (0056-0058, 0084-0085, 0090), as selected by the customer (“The customer informs the sales associate whether to use optical QR delivery or text-message, email, or another delivery medium) (0089, Fig. 15, step 1504).
As per claims 17, Torres 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 (Torres causes the merchant device to generate and display a QR code, and generated URL contains the unique Payment ID and is encoded within the QR code; the customer directs the customer-device camera toward the merchant-device QR code, scans the code, decodes the URL, and opens it in the browser) (0056-0057, 0084-0085, 0089, Figs. 7-8 and 15).
As per claims 18, Torres discloses, wherein the web page includes electronic currencies and digital wallet credits as available sources of fund to pay for the order (Examiner notes that the underlined limitation is disclosed by another prior art. Torres discloses a browser-based payment application presenting payment alternatives and states that the payment server may coordinate bank, credit-card, electronic, and cryptocurrency payments) (0061-0062, 0097), and wherein the payment data from the customer selects a source of fund amongst the electronic currencies and the digital wallet credits (Examiner notes that the underlined limitation is disclosed by another prior art. Examiner interprets Torres identifies Apple Pay, PayPal One Touch, gift-card payment, and securely stored payment data i.e. Torres presents payment alternatives and allows the customer to select Apple Pay, PayPal, a gift card, stored cards, or another available payment method and also provides the electronic/cryptocurrency side of the combination) (0061-0066, 0091-0094, 0097).
Torres discloses, a browser-based payment application presenting payment alternatives and states that the payment server may coordinate bank, credit-card, electronic, and cryptocurrency payments, but specifically doesn’t disclose, and the digital wallet credits, however Doyle discloses, and the digital wallet credits (Doyle expressly teaches payment using funds from a stored customer balance maintained by a P2P payment platform. The stored balance can also be linked to another payment source, such as a debit card or external bank account; Doyle presents a customer-device interface with selectable controls for choosing one of multiple P2P payment platforms or service providers, and processes payment through the selected platform and supplies stored digital-wallet balances and selectable P2P payment platforms) (col. 19, ln. 5-30; col. 20, ln. 1-45, col. 43, ln. 1-20; col. 44, ln. 1-20; Fig. 16B),
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, presenting, via a display of the merchant device, payment options for the order, wherein the payment options include an electronic checkout option, receiving, by the one or more processors of the merchant device, a first selection by the customer corresponding to a selection of the electronic checkout option, in response to receiving the first selection, presenting, via the display of the merchant device, a plurality of link delivery methods associated with the electronic checkout option, receiving, by the one or more processors of the merchant device, a second selection corresponding to a selection of a link delivery method of the plurality of link delivery methods, in response to receiving the second selection, generating, by the one or more processors of the merchant device, a checkout link to a web page based on the selected link delivery method, wherein the web page is provided by a checkout service of payment gateway, as disclosed by Torres, and the digital wallet credits, as taught by Doyle for the purpose to employ transaction-specific resource locator and integrated payment-gateway architecture to associate the selected checkout link with the particular transaction, facilitate secure payment through the selected delivery channel, and consistently update the customer and merchant devices when the payment is completed.
As per claims 19, Torres discloses, wherein a status of the payment available for the merchant device (Torres sends successful or unsuccessful authorization information to the sales-associate application and displays the corresponding payment status on the merchant device and also sends the same successful or unsuccessful authorization to the customer application and sales-associate application. The customer device and merchant device display the corresponding result) (0070-0076, 0095-0096) is automatically synchronized with the customer device via the payment gateway subsequent to the payment confirmation and the receipt becoming available to the customer device (Examiner notes that the underlined limitation is disclosed by another prior art. Examiner interprets Torres sends a successful-payment acknowledgment to the customer application, which displays a successful-payment message, and after payment authorization and submission, Torres generates and sends the customer a receipt by email or text) (0073-0074, 0078, 0095-0096).
Torres discloses, all three events, customer confirmation, merchant-device status, and customer receipt, but specifically doesn’t disclose, is automatically synchronized with the customer device via the payment gateway, however Doyle discloses, is automatically synchronized with the customer device via the payment gateway (Doyle expressly sends transaction-completion notifications to both the POS application and customer mobile-payment application. Both applications then present interfaces indicating that the transaction is complete. Doyle further teaches that gateway 228, notifier 230, and payment-processing component 126 can be components of the payment-processing server, and that notifier 230 provides notifications to merchant and customer devices) (col. 21, ln. 1-35, col. 22, ln. 1-65).
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, presenting, via a display of the merchant device, payment options for the order, wherein the payment options include an electronic checkout option, receiving, by the one or more processors of the merchant device, a first selection by the customer corresponding to a selection of the electronic checkout option, in response to receiving the first selection, presenting, via the display of the merchant device, a plurality of link delivery methods associated with the electronic checkout option, receiving, by the one or more processors of the merchant device, a second selection corresponding to a selection of a link delivery method of the plurality of link delivery methods, in response to receiving the second selection, generating, by the one or more processors of the merchant device, a checkout link to a web page based on the selected link delivery method, wherein the web page is provided by a checkout service of payment gateway, as disclosed by Torres, is automatically synchronized with the customer device via the payment gateway, as taught by Doyle for the purpose to employ transaction-specific resource locator and integrated payment-gateway architecture to associate the selected checkout link with the particular transaction, facilitate secure payment through the selected delivery channel, and consistently update the customer and merchant devices when the payment is completed.
Claims 2 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. 20190205859 (“Torres”) in view U.S. Pat. 11100490 (“Doyle”) in view U.S. Pub. 20180276652 (“Sofronas”).
As per claims 2 and 9, Torres discloses that a customer may create a virtual shopping bag remotely, such as from a computer at home, and that the sales associate may retrieve the remotely created virtual shopping bag using the sales-associate application and also discloses that the customer may communicate with the sales associate through the customer payment application and may receive the checkout link through a text message, email, or another electronic communication medium, but does not expressly disclose, ascertaining that the customer is not present at a location of the merchant device but communicating with a merchant operating the merchant device, however Sofronas discloses, ascertaining that the customer is not present at a location of the merchant device but communicating with a merchant operating the merchant device (Examiner interprets that a customer mobile device periodically transmits its current location to a transaction server, that the transaction server stores and may query the customer device’s current location, and that the location of a merchant-associated wireless device may also be registered and stored by the transaction server and further discloses that a merchant may send an invoice directly to another customer requesting payment through the transaction server) (0096-0098, 0100).
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, presenting, via a display of the merchant device, payment options for the order, wherein the payment options include an electronic checkout option, receiving, by the one or more processors of the merchant device, a first selection by the customer corresponding to a selection of the electronic checkout option, in response to receiving the first selection, presenting, via the display of the merchant device, a plurality of link delivery methods associated with the electronic checkout option, receiving, by the one or more processors of the merchant device, a second selection corresponding to a selection of a link delivery method of the plurality of link delivery methods, in response to receiving the second selection, generating, by the one or more processors of the merchant device, a checkout link to a web page based on the selected link delivery method, wherein the web page is provided by a checkout service of payment gateway, as disclosed by Torres, ascertaining that the customer is not present at a location of the merchant device, as taught by Sofronas for the purpose to use location information to compare the customer-device location with the merchant-device location and thereby ascertain that the customer is not present at the merchant-device location, while using text-message, email, or application communication to permit the remotely located customer to communicate with the merchant and complete the checkout transaction.
Claims 3, 7, 10, 14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. 20190205859 (“Torres”) in view U.S. Pat. 11100490 (“Doyle”) in view U.S. Pat. 11321726 (“Pandhi”).
As per claims 3 and 10, Torres 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 (Pandhi discloses determining that an order includes an unavailable item. Specifically, when a seller cannot fulfill an order because one or more items are out of stock or otherwise unavailable, the service provider uses another seller or sales channel to fulfill the order, and further discloses an invoice tender option permitting payment after the point of sale and an estimate service that stores a timeline for providing goods or services and generates an invoice based on the estimate, including after the goods or services are provided) (“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, Col. 9, ln. 1-10; col. 12, ln. 45-67).
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, presenting, via a display of the merchant device, payment options for the order, wherein the payment options include an electronic checkout option, receiving, by the one or more processors of the merchant device, a first selection by the customer corresponding to a selection of the electronic checkout option, in response to receiving the first selection, presenting, via the display of the merchant device, a plurality of link delivery methods associated with the electronic checkout option, receiving, by the one or more processors of the merchant device, a second selection corresponding to a selection of a link delivery method of the plurality of link delivery methods, in response to receiving the second selection, generating, by the one or more processors of the merchant device, a checkout link to a web page based on the selected link delivery method, wherein the web page is provided by a checkout service of payment gateway, as disclosed by Torres, 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 make payment due by the estimated availability of the unavailable item so that payment timing corresponds to fulfillment of the order.
As per claims 7 and 14, Torres 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 (Pandhi discloses determining that an order includes an unavailable item. Specifically, when a seller cannot fulfill an order because one or more items are out of stock or otherwise unavailable, the service provider uses another seller or sales channel to fulfill the order, and further discloses an invoice tender option permitting payment after the point of sale and an estimate service that stores a timeline for providing goods or services and generates an invoice based on the estimate, including after the goods or services are provided) (“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, Col. 9, ln. 1-10; col. 12, ln. 45-67);
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 (Pandhi further discloses selecting an invoice tender option so that payment is not required at the point of sale and associating a flag or indicator with the transaction so that the invoice is sent at a later time, and also discloses presenting one or more invoices on the seller computing device and tracking outstanding invoices through the invoice module) (col. 14, ln. 25-37);
and storing the order in a pending checkout list of the merchant device (presenting one or more invoices on the seller computing device and tracking outstanding invoices through the invoice module) (col. 12, ln. 1-30; col. 18, ln. 24-35).
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, presenting, via a display of the merchant device, payment options for the order, wherein the payment options include an electronic checkout option, receiving, by the one or more processors of the merchant device, a first selection by the customer corresponding to a selection of the electronic checkout option, in response to receiving the first selection, presenting, via the display of the merchant device, a plurality of link delivery methods associated with the electronic checkout option, receiving, by the one or more processors of the merchant device, a second selection corresponding to a selection of a link delivery method of the plurality of link delivery methods, in response to receiving the second selection, generating, by the one or more processors of the merchant device, a checkout link to a web page based on the selected link delivery method, wherein the web page is provided by a checkout service of payment gateway, as disclosed by Torres, 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 set the deferred-payment due date according to the estimated fulfillment date and maintain the unpaid invoice in the seller device’s outstanding-invoice list, corresponding to the claimed pending checkout list.
As per claims 20, Torres 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 (Pandhi discloses estimates including a timeline for providing goods or services and generating an invoice based on the estimate, including after the goods or services are provided, and further discloses that payment for an invoice may occur at a different time from delivery or provision of the item) (col. 12, ln. 45-67, col. 17, ln. 1-20).
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, presenting, via a display of the merchant device, payment options for the order, wherein the payment options include an electronic checkout option, receiving, by the one or more processors of the merchant device, a first selection by the customer corresponding to a selection of the electronic checkout option, in response to receiving the first selection, presenting, via the display of the merchant device, a plurality of link delivery methods associated with the electronic checkout option, receiving, by the one or more processors of the merchant device, a second selection corresponding to a selection of a link delivery method of the plurality of link delivery methods, in response to receiving the second selection, generating, by the one or more processors of the merchant device, a checkout link to a web page based on the selected link delivery method, wherein the web page is provided by a checkout service of payment gateway, as disclosed by Torres, 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 set the checkout-link due date no sooner than the estimated delivery date so that payment is deferred until the unavailable item is expected to be provided.
Claims 5-6 and 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. 20190205859 (“Torres”) in view U.S. Pat. 11100490 (“Doyle”) in view U.S. Pub. 20200320523 (“Singh”).
As per claims 5 and 12, Torres discloses, setting an expiration timer for the checkout link for a window during which the customer can process the payment (Examiner notes that the underlined limitation is disclosed by another prior art. Torres teaches that the sales-associate application waits while the customer completes payment using NewStore Checkout. After receiving a successful-payment message, the merchant application displays a message informing the sales associate that payment was successful and permits finalization of the sale; Torres also teaches that: the payment-gateway service returns successful or failed authorization; the payment server stores the authorization with the customer order; the payment result is transmitted to the customer application and merchant application; the merchant device displays successful-payment status; and the merchant device may receive a push notification or poll the payment server for payment status) (0087, 0053, 0070-0076, 0095-0096),
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 (Examiner notes that the underlined limitation is disclosed by another prior art. Torres further discloses receiving successful payment authorization and updating the merchant device to display successful or paid status) (0070-0076, 87, and 0095-0096)
Torres does not expressly disclose, an expiration timer assigned to the checkout link and based on ascertaining that the payment has been posted prior to the expiration timer of the checkout link runs out, however Singh discloses, setting an expiration timer for the checkout link (Singh discloses setting an expiration timer for a unique payment link for a window during which a transaction may be completed. Specifically, Singh teaches receiving an expiration date and time that places a time limit on the transaction and setting the unique payment link to expire at the received date and time) (0005, 0022-0025, Fig. 2A, step 212);
and based on ascertaining that the payment has been posted prior to the expiration timer of the checkout link runs out (Singh discloses determining whether the unique payment link has expired by comparing the link expiration with the date and time of selection and allowing the transaction process to continue when the link is selected at or before expiration) (0028).
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, presenting, via a display of the merchant device, payment options for the order, wherein the payment options include an electronic checkout option, receiving, by the one or more processors of the merchant device, a first selection by the customer corresponding to a selection of the electronic checkout option, in response to receiving the first selection, presenting, via the display of the merchant device, a plurality of link delivery methods associated with the electronic checkout option, receiving, by the one or more processors of the merchant device, a second selection corresponding to a selection of a link delivery method of the plurality of link delivery methods, in response to receiving the second selection, generating, by the one or more processors of the merchant device, a checkout link to a web page based on the selected link delivery method, wherein the web page is provided by a checkout service of payment gateway, as disclosed by Torres, an expiration timer assigned to the checkout link and based on ascertaining that the payment has been posted prior to the expiration timer of the checkout link runs out, as taught by Singh for the purpose to apply expiration period to checkout link to prevent use of a stale transaction-specific payment link and when payment is posted during the permitted period, payment-status notification would update the merchant device to indicate that the payment was paid.
As per claims 6 and 13, Torres discloses, setting an expiration timer for the checkout link for a window during which the customer can process the payment (Examiner notes that the underlined limitation is disclosed by another prior art. Torres teaches that the sales-associate application waits while the customer completes payment using NewStore Checkout. After receiving a successful-payment message, the merchant application displays a message informing the sales associate that payment was successful and permits finalization of the sale; Torres also teaches that: the payment-gateway service returns successful or failed authorization; the payment server stores the authorization with the customer order; the payment result is transmitted to the customer application and merchant application; the merchant device displays successful-payment status; and the merchant device may receive a push notification or poll the payment server for payment status) (0087, 0053, 0070-0076, 0095-0096),
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 (Torres discloses, sending a cancellation or unsuccessful-payment message to the sales-associate application and displaying the corresponding status on the merchant device) (0076, 0087).
Torres specifically doesn’t discloses, setting an expiration timer for the checkout link 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 Singh discloses, setting an expiration timer for the checkout (“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 (Singh discloses determining that the expiration timer of the unique payment link has expired by comparing the link-expiration time with the date and time of selection. When the link is selected at or after expiration, the transaction system prevents access to the transaction portal and the transaction process ceases. Singh further teaches that, when the transaction is not completed before the expiration time, the transaction is canceled) (0022, 0025, 0028).
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, presenting, via a display of the merchant device, payment options for the order, wherein the payment options include an electronic checkout option, receiving, by the one or more processors of the merchant device, a first selection by the customer corresponding to a selection of the electronic checkout option, in response to receiving the first selection, presenting, via the display of the merchant device, a plurality of link delivery methods associated with the electronic checkout option, receiving, by the one or more processors of the merchant device, a second selection corresponding to a selection of a link delivery method of the plurality of link delivery methods, in response to receiving the second selection, generating, by the one or more processors of the merchant device, a checkout link to a web page based on the selected link delivery method, wherein the web page is provided by a checkout service of payment gateway, as disclosed by Torres, an expiration timer assigned to the checkout link and based on ascertaining that the payment has been posted prior to the expiration timer of the checkout link runs out, as taught by Singh for the purpose to apply expiration period to checkout link to prevent use of a stale transaction-specific payment link and when payment is posted during the permitted period, payment-status notification would update the merchant device to indicate that the payment was paid.
Response to Arguments
With regards to § 101 rejections:
The arguments filed on May 12th, 2026, with respect to the rejection(s) of claims 1-20 under 35 U.S.C 101 have been fully considered but are unpersuasive. The rejection is maintained and updated to address the amended claims.
Applicant’s arguments have been considered but are not persuasive. The Office has evaluated each claim as a whole, including the recited “in response to” and “based on” relationships. Those relationships merely define the order in which the underlying commercial-payment activity is performed: presenting payment options, receiving selections, generating and delivering a checkout link, processing payment, and reporting transaction status. They do not recite a technological solution to a technological problem or improve the operation of the merchant device, customer device, payment gateway, network, browser, or any other computer technology. Applicant’s reliance on generalized statements in the Specification does not establish eligibility because the asserted technological improvement must be reflected in the claim itself. The recited processors, devices, browser, payment gateway, and communication network perform only their ordinary functions of receiving, displaying, generating, transmitting, processing, and updating information. Merely implementing the identified commercial transaction through generic computer components, even in a specified sequence, does not integrate the abstract idea into a practical application. Nor do the data-receipt, link-delivery, payment-confirmation, receipt, and status-update limitations impose a meaningful technological limitation; they constitute necessary data gathering, communication, and output incidental to the commercial transaction. MPEP §§ 2106.04(d), 2106.05(f)–(h). At Step 2B, the additional elements have also been considered both individually and as an ordered combination. The ordered combination merely instructs generic computer components to execute the abstract checkout workflow and therefore does not supply an inventive concept. The dependent claims similarly add commercial rules - such as deferred or installment payment, backorder-based payment timing, link expiration, selectable delivery formats, funding-source selection, and payment-status synchronization - implemented through the same generic computing functions. Accordingly, the claims remain directed to an abstract commercial practice without significantly more, and the rejection under 35 U.S.C. § 101 is maintained.
With regards to § 103 rejections:
Applicant's arguments, see pages 11-12, filed May 12th, 2026, with respect to the rejection(s) of claims 1-20 under 35 U.S.C 102/103 have been fully considered but are directed to references and findings that are no longer the basis of the current rejection and therefore do not overcome the newly stated rejection.
Applicant’s arguments have been considered but are not persuasive, because they are directed to the previously applied Borden based rejection and do not address the teachings of Torres relied upon in the present rejection. In particular, Torres expressly discloses the claimed ordered sequence: the merchant application first displays payment options; determines that the NewStore Checkout option was selected; thereafter generates a URL containing a transaction-specific Payment ID; presents QR-code, text-message, email, or other link-delivery alternatives; receives selection of the delivery method; and delivers the checkout link through the selected method. See Torres ¶¶ 82-85 and 89-90; Figs. 13-15. Contrary to Applicant’s assertion concerning server-side generation in Borden, Torres expressly states that the sales associate application executing on the merchant device generates the URL and generates and displays the QR code, after receiving the Payment ID from the payment server. See Torres ¶ 84. Torres further discloses that the customer informs the sales associate whether to use optical QR-code delivery or text-message, email, or another medium, thereby supplying the claimed customer-selected delivery method. See Torres ¶¶ 85 and 89-90. Doyle is relied upon for the transaction specific resource locator and integrated payment-gateway architecture. It would have been obvious to implement Torres’s selectable checkout-link workflow using Doyle’s known transaction-specific URL/token and gateway integration so that the selected link identifies the particular transaction, enables payment processing through the integrated payment platform, and provides transaction-status notifications to the merchant and customer devices. Thus, the present rejection does not require the modification of Borden challenged by Applicant, and Applicant’s arguments do not overcome the newly applied combination.
Thus, the dependent claims 2-7, 9-14, and 16-20 that depend from claims 1, 8, and 15 respectively are also moot/unpersuasive.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US. Pat. 20160283925 (“Lavu”).
Yun discloses, a methods and systems multi-channel shopping and mobile payment system and method makes in-store checkout flow at a retail store smooth, efficient and intuitive to the customer to thereby improve the customer's experience as well as reducing an amount of time spent at the checkout by both the customer and retail store sales associate. The system and method can reduce long checkout lines during peak period and allow retail store sales associates to spend more time on the sales floor helping customers and increasing sales. A mobile wallet associated with each customer can be used as the mechanism to compute an order, determine and apply offers and loyalty rewards, and give the customer a single click checkout experience at a point-of-sale device in the retail store.
THIS ACTION IS MADE FINAL. 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 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
Prosecution Insights