Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This action is in reply to the replay filed on 08/11/2025.
Claims 1-16 are elected
Claims 17-20 are cancelled.
Claims 21-24 are newly added.
Claims 1-16, 21-24 are currently pending and have been examined.
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-16, and 21-24 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
In the instant case, claims 1, 9 and 21 are directed to a method, system, and non-transitory computer-readable recording medium.
Claim 1 recites “purchasing and tracking orders” which is a grouped under “Certain methods of organizing human activity — fundamental economic practices” in prong one of step 2A (MPEP 2106.04(a)). For the purposes of this analysis, representative claim 1 is addressed. (Step 2A, prong 1) Abstract ideas are in bold below, and represents a “purchasing and tracking orders”
receiving an indication that a transaction was processed at a merchant device between a user and a merchant, wherein the transaction includes an order for the merchant to fulfill for the user, and wherein the indication includes a transaction identifier usable to track a status of whether the transaction has been fulfilled;
generating notification data for the transaction that tracks the status using the transaction identifier, wherein the notification data is displayable via at least one of an application interface or a webpage;
transmitting a notification associated with the notification data to one of the merchant device of the merchant or a mobile device of the user;
providing the notification data via the notification in the at least one of the application interface or the webpage without requiring an identifier of the mobile device or the user;
receiving, from the merchant device, an update to the status of the transaction based on the transaction identifier; and
updating the notification data provided via the notification based on the update.
The additional elements of claim 1 such as “… device…”, “…displayable via at least one of an application interface or a webpage”, “ … of the merchant or a mobile device of the user”, “providing the notification data via the notification in the at least one of the application interface or the webpage without requiring an identifier of the mobile device or the user”, “receiving, from the merchant device, an update to the status of the transaction based on the transaction identifier”, “updating the notification data provided via the notification based on the update.” represent the use of a computer as a tool to perform an abstract idea and/or does no more than generally link the abstract idea to a particular field of use.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration into a practical application, the additional elements amount to no more than mere instructions to apply the abstract idea of using generic computer components. The claim elements when considered separately and in an ordered combination, do not add significantly more than implementing the abstract idea of purchasing and tracking orders.
Hence, claims 1, 9 and 21 is not patent eligible.
Claim 2 and 22 recites the additional elements of “generating the webpage and a webpage address for the webpage based on the notification data, wherein the webpage includes the transaction and the status accessible via the webpage address for viewing; and hosting the webpage over a network for access using the webpage address.” does no more than use a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. Therefore, as it is no more than apply it does not improve the functioning of a computer, or improve other technology or technical field.
Claim 3 and 23 recites the additional elements of “transmitting, to the merchant device, code having the webpage address embedded in the code.” does no more than use a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. Therefore, as it is no more than apply it does not improve the functioning of a computer, or improve other technology or technical field.
Claims 4 and 24 recites the additional elements of “wherein the code comprises at least one of a near field communication (NFC) data token comprising an executable command that loads the webpage using the webpage address without requiring a message file attachment or a quick response (QR) code that includes displayable encoded data for the webpage address.” does no more than use a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. Therefore, as it is no more than apply it does not improve the functioning of a computer, or improve other technology or technical field.
Claim 5 recites “wherein the indication further comprises loyalty data for the user from a digital wallet on the mobile device of the user, wherein the loyalty data is received with a payment from the digital wallet for the transaction, and wherein the loyalty data is linked to at least the status for tracking on behalf of the user.” However, this does no more than describe the abstract idea.
Claim 6 recites “determining an identifier associated with the user based on the loyalty data, wherein the notification is transmitted to the mobile device using the identifier.” However, this does no more than describe the abstract idea.
Claim 7 recites the additional elements of “wherein the identifier is associated with an account of the user accessible via a mobile application on the mobile device, and wherein the notification comprises an in-application notification published in the mobile application using the identifier.” does no more than use a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. Therefore, as it is no more than apply it does not improve the functioning of a computer, or improve other technology or technical field.
Claim 8 recites “wherein the order is for a good or a service that requires fulfillment at a merchant location of the merchant where the transaction takes place, and wherein the update to the status includes at least one of a prepared order number or order retrieval instructions provided via the notification data based on the updated notification data.” However, this does no more than describe the abstract idea.
Claim 10 recites “wherein the account data is received from the merchant … when processing the transaction based on a payment instrument provided by the … to the merchant ….” However, this does no more than describe the abstract idea. The additional elements of “…system… mobile device…” does no more than use a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. Therefore, as it is no more than apply it does not improve the functioning of a computer, or improve other technology or technical field.
Claim 11 recites “wherein the payment instrument comprises a … wallet token or a payment card token from a … wallet on the …, and wherein the account data is tokenized or encrypted when transferred to the merchant system with the …wallet token or the payment card token.” However, this does no more than describe the abstract idea. The additional elements of “…digital… mobile device… system…” does no more than use a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. Therefore, as it is no more than apply it does not improve the functioning of a computer, or improve other technology or technical field.
Claim 12 recites the additional elements of “generating one of application interface data for the application interface or webpage data for the webpage based on the transaction and the first status.” does no more than use a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. Therefore, as it is no more than apply it does not improve the functioning of a computer, or improve other technology or technical field.
Claim 13 recites the additional elements of “wherein the notification data is transmitted to the user via the account using a push notification to the application when the application is logged in to the account.” does no more than use a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. Therefore, as it is no more than apply it does not improve the functioning of a computer, or improve other technology or technical field.
Claim 14 recites the additional elements of “wherein the notification data is transmitted over a network to the mobile device separately from merchant system, and wherein the merchant system is prevented from receiving an identifier associated with the user or the account when transmitting the notification data.” does no more than use a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. Therefore, as it is no more than apply it does not improve the functioning of a computer, or improve other technology or technical field.
Claim 15 recites “the additional elements of “wherein the at least one subsequent status comprises a second status indicating the fulfillment of the transaction is completed and instructions for receiving one or more items and/or one or more services for the transaction.” does no more than use a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. Therefore, as it is no more than apply it does not improve the functioning of a computer, or improve other technology or technical field.
Claim 16 recites the additional elements of “wherein the merchant system comprises one of a standalone payment terminal in communication with the system over a network or a merchant POS device and a connectable payment terminal in communication with the merchant POS device.” does no more than use a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. Therefore, as it is no more than apply it does not improve the functioning of a computer, or improve other technology or technical field.
The claims as a whole do not amount to significantly more than the abstract idea itself. This is because the claims do not affect an improvement to another technology or technical field, the claims do not amount to an improvement to the functioning of a computer system itself, and the claims do not move beyond a general link of the use of an abstract idea to a particular technological environment.
Accordingly, there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 22-24 are rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends. Claims 22-24 are dependent on claims 29 and 30, which are not present in the application. Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
Claim Rejections - 35 USC § 102
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 (i.e., changing from AIA to pre-AIA ) 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 7-10, 12-16, and 21 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Vudathu (US 2023/0316283 A1)
Regarding claims 1 and 21
receiving an indication that a transaction was processed at a merchant device between a user and a merchant, wherein the transaction includes an order for the merchant to fulfill for the user, and wherein the indication includes a transaction identifier usable to track a status of whether the transaction has been fulfilled; (See at least Vudathu [0049] [0050] and [0052]:[0049] In step 205, a customer may shop for a product from a merchant that has been onboarded or registered with a financial institution or similar, and may pay for the product using a payment method issued by or registered to the financial institution. For example, the order may be placed online, at a merchant point of sale. [0050] In step 210, as part of the transaction approval process, the merchant may submit transaction data for the transaction to the acquirer, then to a Card Network (e.g., VISA or MasterCard), and ultimately to the issuing financial institution. [0052] In step 220, the financial institution may provide the transaction data to an order tracking system for tracking and monitoring. The order tracking system may persist the metadata for the transaction, such as the transaction identifier, transaction amount, transaction date, payment card number, merchant identifier, etc.
generating notification data for the transaction that tracks the status using the transaction identifier, wherein the notification data is displayable via at least one of an application interface or a webpage; (See at least Vudathu [0052] In step 220, the financial institution may provide the transaction data to an order tracking system for tracking and monitoring. The order tracking system may persist the metadata for the transaction, such as the transaction identifier, transaction amount, transaction date, payment card number, merchant identifier, etc.
transmitting a notification associated with the notification data to one of the merchant device of the merchant or a mobile device of the user; (See at least Vudathu [0047] Order tracking system 118 may interface with merchants 140 (e.g., 1401, 1402, . . . 140N), delivery providers 150 (e.g., 1501, 1502, . . . 150N), etc. and may provide updates to customers via app 135.
providing the notification data via the notification in the at least one of the application interface or the webpage without requiring an identifier of the mobile device or the user; (See at least Vudathu [0047] Order tracking system 118 may interface with merchants 140 (e.g., 1401, 1402, . . . 140N), delivery providers 150 (e.g., 1501, 1502, . . . 150N), etc. and may provide updates to customers via app 135.
receiving, from the merchant device, an update to the status of the transaction based on the transaction identifier; and (See at least Vudathu [0047, and [0081]:[0047] Order tracking system 118 may interface with merchants 140 (e.g., 1401, 1402, . . . 140N), delivery providers 150 (e.g., 1501, 1502, . . . 150N), etc. and may provide updates to customers via app 135. [0081] In step 505, an order tracking system may periodically initiate a background update to refresh the order status by fetching the current status from a merchant backend. For example, the order tracking system may provide identifiers for any open orders to the merchant backend.
updating the notification data provided via the notification based on the update. (See at least Vudathu [0057], and [0058]: [0057] In one embodiment, the order status may include an order status and/or delivery status, such as order placed, ready for shipment, shipped, delivered, cancelled, return started, refund issued, etc. in process, shipped, completed, etc. [0058] In step 240, the order tracking system may persist the digital receipt with, for example, a digital receipt system, for storage and safe keeping. In one embodiment, the customer may access the digital receipt using, for example, a mobile application, a web browser, a digital wallet, etc.
Regarding claim 7
wherein the identifier is associated with an account of the user accessible via a mobile application on the mobile device, and wherein the notification comprises an in-application notification published in the mobile application using the identifier. (See at least Vudathu [0079] In step 420, the order tracking system may return the consolidated order/shipping information to the customer. For example, the order/shipping information may be sent to a registered customer email address, registered customer electronic device, registered customer phone number, registered customer application etc. mobile/web app for display to the customer. The customer email address, customer electronic device, customer phone number, customer application, etc. may be registered as part of the Know Your Customer (KYC) process, may be part of the customer profile, etc.
Regarding claim 8
wherein the order is for a good or a service that requires fulfillment at a merchant location of the merchant where the transaction takes place, and wherein the update to the status includes at least one of a prepared order number or order retrieval instructions provided via the notification data based on the updated notification data. (See at least Vudathu [0042] and [0077]: [0042] In embodiments, the customer may order items that require delivery, items that do not require delivery (like a service or digital content), and items that are picked up. For pickup and digital content/services, the order tracking service may interface with the merchant to identify the order and delivery status. [0077] In step 410, the order tracking system may use a unique identifier, such as an order number, to request an order status from a merchant backend associated with the merchant for the order.
Regarding claim 9
a non-transitory memory; and one or more hardware processors coupled to the non-transitory memory and configured to execute instructions to cause the system to: (See at least Vudathu [0085] FIG. 6 depicts an exemplary computing system for implementing aspects of the present disclosure. FIG. 6 depicts exemplary computing device 600. Computing device 600 may represent the system components described herein. Computing device 600 may include processor 605 that may be coupled to memory 610. Memory 610 may include volatile memory. Processor 605 may execute computer-executable program code stored in memory 610, such as software programs 615. Software programs 615 may include one or more of the logical steps disclosed herein as a programmatic instruction, which may be executed by processor 605. Memory 610 may also include data repository 620, which may be nonvolatile memory for data persistence. Processor 605 and memory 610 may be coupled by bus 630. Bus 630 may also be coupled to one or more network interface connectors 640, such as wired network interface 642 or wireless network interface 644. Computing device 600 may also have user interface components, such as a screen for displaying graphical user interfaces and receiving input from the user, a mouse, a keyboard and/or other input/output components (not shown).
receive, from a merchant system, account data for a user and a first status of a transaction processed between the user and a merchant corresponding to the merchant system, wherein the first status indicates the transaction is pending a fulfillment of the transaction by the merchant and is usable to track the fulfillment of the transaction by the merchant; (See at least Vudathu [0049] and [0050]: [0049] In step 205, a customer may shop for a product from a merchant that has been onboarded or registered with a financial institution or similar, and may pay for the product using a payment method issued by or registered to the financial institution. For example, the order may be placed online, at a merchant point of sale. [0050] In step 210, as part of the transaction approval process, the merchant may submit transaction data for the transaction to the acquirer, then to a Card Network (e.g., VISA or MasterCard), and ultimately to the issuing financial institution.
generate notification data for the transaction that tracks a progress of the fulfillment of the transaction between the first status and at least one subsequent status, (See at least Vudathu [0052] In step 220, the financial institution may provide the transaction data to an order tracking system for tracking and monitoring. The order tracking system may persist the metadata for the transaction, such as the transaction identifier, transaction amount, transaction date, payment card number, merchant identifier, etc.
wherein the notification data is displayable via at least one of an application interface or a webpage displayable in an application on a mobile device of the user; (See at least Vudathu [0076] and [0079]:[0076] Referring to FIG. 4, a method for providing a real-time order status update is disclosed according to an embodiment. In step 405, using a mobile application or a web browser, a customer may request order status information from an order tracking system. For example, the customer may enter an order number, may select a digital receipt for the order, etc. The customer may also select a transaction in the customer's card transaction history and then be provided with the order details for the selected transaction. [0079] In step 420, the order tracking system may return the consolidated order/shipping information to the customer. For example, the order/shipping information may be sent to a registered customer email address, registered customer electronic device, registered customer phone number, registered customer application etc. mobile/web app for display to the customer. The customer email address, customer electronic device, customer phone number, customer application, etc. may be registered as part of the Know Your Customer (KYC) process, may be part of the customer profile, etc.
determine an account of the user based on the account data; (See at least Vudathu [0038] and [0039]: [0038] Embodiments may coordinate a customer's purchases across multiple financial instruments, accounts, etc. For example, purchases made using a customer's personal and business accounts may be aggregated and presented together in one interface. Thus, tracking information for all transactions involving an account associated with the customer may be presented. [0039] In one embodiment, machine learning may be used to identify the accounts, transaction types, etc. that the customer may want to include or not include in the aggregated report.
transmit the notification data to the user via the account, wherein transmitting the notification causes the application on the mobile device to display the notification data; (See at least Vudathu [0084] In step 520, the order tracking system may send notifications for any orders where the order or shipping status has changed. For example, the order tracking system may update a mobile application or a web browser, may send a message (e.g., SMS, email, etc.), may send a push notification (e.g., an in-app message), etc.
and update the notification data based on the at least one subsequent status when received. (See at least Vudathu [0084] In step 520, the order tracking system may send notifications for any orders where the order or shipping status has changed. For example, the order tracking system may update a mobile application or a web browser, may send a message (e.g., SMS, email, etc.), may send a push notification (e.g., an in-app message), etc.
Regarding claim 10
The system of claim 9, wherein the account data is received from the merchant system when processing the transaction based on a payment instrument provided by the mobile device to the merchant system. (See at least Vudathu [0043] A customer may conduct a transaction for a good or service with a merchant (e.g., merchant 1401) directly or using customer electronic device 130, and may access order details using application 135, such as a mobile or web application, on customer electronic device 130.
Regarding claim 12
generating one of application interface data for the application interface or webpage data for the webpage based on the transaction and the first status. (See at least Vudathu [0079] In step 420, the order tracking system may return the consolidated order/shipping information to the customer. For example, the order/shipping information may be sent to a registered customer email address, registered customer electronic device, registered customer phone number, registered customer application etc. mobile/web app for display to the customer. The customer email address, customer electronic device, customer phone number, customer application, etc. may be registered as part of the Know Your Customer (KYC) process, may be part of the customer profile, etc.
Regarding claim 13
wherein the notification data is transmitted to the user via the account using a push notification to the application when the application is logged in to the account. (See at least Vudathu [0084] In step 520, the order tracking system may send notifications for any orders where the order or shipping status has changed. For example, the order tracking system may update a mobile application or a web browser, may send a message (e.g., SMS, email, etc.), may send a push notification (e.g., an in-app message), etc.
Regarding claim 14
wherein the notification data is transmitted over a network to the mobile device separately from merchant system, and wherein the merchant system is prevented from receiving an identifier associated with the user or the account when transmitting the notification data. (See at least Vudathu [0084] In step 520, the order tracking system may send notifications for any orders where the order or shipping status has changed. For example, the order tracking system may update a mobile application or a web browser, may send a message (e.g., SMS, email, etc.), may send a push notification (e.g., an in-app message), etc.
Regarding claim 15
The system of claim 9, wherein the at least one subsequent status comprises a second status indicating the fulfillment of the transaction is completed and instructions for receiving one or more items and/or one or more services for the transaction. (See at least Vudathu [0042] In embodiments, the customer may order items that require delivery, items that do not require delivery (like a service or digital content), and items that are picked up. For pickup and digital content/services, the order tracking service may interface with the merchant to identify the order and delivery status. For items that need delivery, the order tracking service may interface with the merchant to identify delivery updates (e.g., where the merchant fulfills delivery) or with third party delivery suppliers (e.g., where the merchant uses a third party for delivery).
Regarding claims 16
wherein the merchant system comprises one of a standalone payment terminal in communication with the system over a network or a merchant POS device and a connectable payment terminal in communication with the merchant POS device. (See at least Vudathu [0049] In step 205, a customer may shop for a product from a merchant that has been onboarded or registered with a financial institution or similar, and may pay for the product using a payment method issued by or registered to the financial institution. For example, the order may be placed online, at a merchant point of sale.
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 (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 2 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Vudathu (US 2023/0316283 A1) in view of Bansal (US 2017/0300909 A1)
Regarding claims 2 and 22
generating the webpage and a webpage address for the webpage based on the notification data, wherein the webpage includes the transaction and the status accessible via the webpage address for viewing; (See at least Vudathu [0074] and [0079]: [0074] In step 350, the order tracking system may persist the digital receipt with, for example, a digital receipt system, for storage and safe keeping. In one embodiment, the customer may access the digital receipt using, for example, a mobile application, a web browser, a digital wallet, etc. [0079] In step 420, the order tracking system may return the consolidated order/shipping information to the customer. For example, the order/shipping information may be sent to a registered customer email address, registered customer electronic device, registered customer phone number, registered customer application etc. mobile/web app for display to the customer. The customer email address, customer electronic device, customer phone number, customer application, etc. may be registered as part of the Know Your Customer (KYC) process, may be part of the customer profile, etc.
However Vudathu does not specifically teach: hosting the webpage over a network for access using the webpage address.
However Bansal teaches at least at: [0050] With reference to FIG. 7C, a method 760 may complete an e-commerce transaction within the system 100 where a merchant e-commerce computer system 104 is integrated with a partner to handle its payment processing or the partner hosts the website 158
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the methods for merchant integration to track orders and shipments status of Vudathu in view of the method for secure web payments as taught by Bansal in order to securely facilitate payment reconciliation between a credit account holder and a merchant (Bansal [0021])
Claims 3-4 and 23-24 are rejected under 35 U.S.C. 103 as being unpatentable over Vudathu (US 2023/0316283 A1) in view of Bansal (US 2017/0300909 A1) and further in view of Licht et al (US 2018/0047090 A1)
Regarding claims 3 and 23
Vudathu does not specifically teach transmitting, to the merchant device, code having the webpage address embedded in the code
However, Licht teaches at least at [0030] The real-time notification for order fulfillment state also includes a novel Quick Response (QR) code generated by either the event manager 111 or the POS system/devices 120. In the case where the event manager 111 generates the QR code, the QR code is in a format that can be read and processed by the POS system/devices 120. The QR code is encoded for identifying and retrieving an entire transaction of the customer that is relevant to the real-time order fulfillment change in state notification. This permits the customer to have the QR code scanned from a display of the user-device 130 by a POS device 120. This permits the customer to identify his transaction at an enterprise where the order is to be picked up and/or paid for. The QR code can also be automatically presented (through a scan at a POS device 120 for order modification (adding an item, deleting an item, or modifying an item or item quantity for the transaction).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the methods for merchant integration to track orders and shipments status of Vudathu in view of the real time order notifications processing as taught by Licht in order to dynamically deliver the change in real time to a mobile device being operated by a customer associated with the order. (Licht [0008])
Regarding claims 4 and 24
Vudathu does not specifically teach wherein the code comprises at least one of a near field communication (NFC) data token comprising an executable command that loads the webpage using the webpage address without requiring a message file attachment or a quick response (QR) code that includes displayable encoded data for the webpage address.
However Licht teaches at least at [0030] The real-time notification for order fulfillment state also includes a novel Quick Response (QR) code generated by either the event manager 111 or the POS system/devices 120. In the case where the event manager 111 generates the QR code, the QR code is in a format that can be read and processed by the POS system/devices 120. The QR code is encoded for identifying and retrieving an entire transaction of the customer that is relevant to the real-time order fulfillment change in state notification. This permits the customer to have the QR code scanned from a display of the user-device 130 by a POS device 120. This permits the customer to identify his transaction at an enterprise where the order is to be picked up and/or paid for. The QR code can also be automatically presented (through a scan at a POS device 120 for order modification (adding an item, deleting an item, or modifying an item or item quantity for the transaction).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the methods for merchant integration to track orders and shipments status of Vudathu in view of the real time order notifications processing as taught by Licht in order to dynamically deliver the change in real time to a mobile device being operated by a customer associated with the order. (Licht [0008])
Claims 5-6 are rejected under 35 U.S.C. 103 as being unpatentable over Vudathu (US 2023/0316283 A1) in view of Nelson (2019/0050884 A1)
Regarding claim 5
Vudathu does not specifically teach: wherein the indication further comprises loyalty data for the user from a digital wallet on the mobile device of the user, wherein the loyalty data is received with a payment from the digital wallet for the transaction, and wherein the loyalty data is linked to at least the status for tracking on behalf of the user.
However, Nelson teaches at least at: [0047] At 206, method 200 includes the loyalty platform tracking user purchases made using the registered or linked payment method, and distributing rewards to a user account on the loyalty platform based on eligible purchases made at rewarding companies to which user has selected loyalty (described in more detail with regard to FIGS. 4A-4C). In one example, eligible purchases may include purchases made by users with an active user account on the loyalty platform, the purchase occurring at a PHC or business to which the user has selected loyalty, and said PHC or business having an active rewards program through the loyalty platform (with a positive non-zero rewards program fund balance associated with said active rewards program). In this way, PHCs and users may be advantageously connected through a loyalty platform which enables creation, execution, and management, of a rewards program offering equity, or equity-like, rewards.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the methods for merchant integration to track orders and shipments status of Vudathu in view of distributing success linked rewards to customers of privately held companies as taught by Nelson in order to provide success-linked assets to users as rewards for certain behaviors, such as purchasing goods. (Nelson [0019])
Regarding claim 6
Vudathu does not specifically teach: determining an identifier associated with the user based on the loyalty data, wherein the notification is transmitted to the mobile device using the identifier.
However, Nelson teaches at least at: [0068] At 314C, method 300C includes prompting the user to input payment method information into designated fields on the display/interface using user input devices. Payment information entered by the user is used by the loyalty platform to track purchases made by the user for purposes of loyalty purchase identification and automatic reward allocation, as given in more detail by FIGS. 4A-4C. In one example payment information may include credit card information, such as a credit card number, expiration date, and pin. In another example, payment information may include a digital wallet address, or account information for a digital payment service (such as PayPal, Venmo, etc.). Upon an indication to the loyalty platform that the user has entered information in all of the required fields, method 300C may then proceed 316C.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the methods for merchant integration to track orders and shipments status of Vudathu in view of distributing success linked rewards to customers of privately held companies as taught by Nelson in order to provide success-linked assets to users as rewards for certain behaviors, such as purchasing goods. (Nelson [0019])
Claims 11 is rejected under 35 U.S.C. 103 as being unpatentable over Vudathu (US 2023/0316283 A1) in view of Sarin (US 2022/0067703 A1)
Regarding claim 11
wherein the payment instrument comprises a digital wallet token or a payment card token from a digital wallet on the mobile device, and wherein the account data is tokenized or encrypted when transferred to the merchant system with the digital wallet token or the payment card token.
However, Sarin teaches at least at [0014] In order to avoid transmitting the funding account data during the processing of electronic payment transactions, the funding account data may be tokenized (e.g., by the digital wallet application, a digital wallet server, a token service provider server). For example, tokens may be generated for each of the one or more funding accounts to be used in electronic payment transactions in association with the one or more funding accounts. A token may include encrypted data that represent the funding account data of the corresponding funding account. With a proper encryption key, the token may be decrypted or detokenized (e.g., by a payment server, etc.) to obtain the funding account data, but any malicious users who intercepts the token without the encryption key will not have access to the funding account data. In some embodiments, the tokens are single-use tokens that can only be used once to further enhance security of the funding accounts.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the methods for merchant integration to track orders and shipments status of Vudathu in view of multi-tenant payment tokens as taught by Serin in order to enable the one or more existing tokens to be usable in electronic payment transactions in association with the first funding account or the second funding account. (Serin (abstract))
Prior art of record not relied upon
Wetz (US 2021/0350424 A1) Teaches: consumer tracking system.
Blackhurst (US 2015/0032642 A1) Teaches: Use of re-encrypted to verify ownership and service.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GREGORY MARK JAMES whose telephone number is (571)272-5155. The examiner can normally be reached M-F 8:30am - 5:00pm EST.
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, Ryan Donlon can be reached at 571-270-3602. 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.
/GREGORY M JAMES/Examiner, Art Unit 3692
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692