DETAILED ACTION
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 office action is in response to the election with traverse filed on 6/22/2026.
Claims 1, 3, 8, 12, and 14 have been amended.
Claims 2 and 13 have been canceled.
Claims 1, 3-12, and 14-17 are pending and have been examined.
Election/Restrictions
The examiner withdraws the restriction based on the amendments to the claims filed on 6/22/2026. As a result, the election with traverse is moot.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 3-12, and 14-17 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-8 of US Patent No. 12254487. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims are directed to the same subject matter, perform the equivalent functions and a person of ordinary skill in the art would not be free to practice one of the claimed inventions without infringing upon the other. The claimed invention is merely broader than the patented invention above.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 3-7 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites “(iv) transmitting the transaction data captured at the first POS device through the network; (v) receiving, at the first POS device, through the network, the customer token ID information;” It is unclear as to which “network” this is referring to. Previously, the claim establishes “direct network communication with an access point to a central network” and “a node-to-node network.” Thus, it is unclear as to which network this is referring to. Claims 3-7 are rejected as each depends from claim 1.
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, 3-12, and 14-17 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Claims 1-3-7 are directed to a method. Claims 8-11 are directed to a method. Claims 12, 14-17 are directed to a plurality of POS devices. Thus, on their face they fall within the four statutory categories of patentable subject matter.
Step 2A prong 1:
The following limitations, when considered individually and as an ordered combination, are merely descriptive of abstract concepts:
Claim 1:
(i) providing a payment vehicle
(ii) providing a first POS of a plurality of POS, each of the plurality of POS configured to: process a commercial transaction through direct communication with an access point to a central entity or configured to process the commercial transaction through node- to-node established by at least one other POS of the plurality of POS that is in communication with at least one access point to the central entity, and configured to obtain customer token ID information from a credit vault intermediary institution and to associate the customer token ID information with the payment vehicle;
(iii) capturing transaction data associated with the payment vehicle, at the first POS, for processing the commercial transaction;
(iv) transmitting the transaction data captured at the first POS;
(v) receiving, at the first POS the customer token ID information; and
(vi) invoking, at the first POS, an incentive credit based on the customer token ID information.
Claim 8:
(i) providing a payment vehicle
(ii) providing a first POS of a plurality of POS, the first POS configured to process a commercial transaction through direct communications with an access point to a central entity, and, when experiencing communication issues with the access point, further configured to process the commercial transaction through a node-to-node;
(iii) capturing transaction data associated with the payment vehicle, at the first POS, for processing the commercial transaction;
(iv) providing a second POS of the plurality of POS, the second POS in communication with at the least one access point to the central entity;
(v) establishing, with the plurality of POS, the node-to-node for processing the commercial transaction, the node-to-node configured to enable communications between the plurality of POS and the central entity, and configured to obtain customer token ID information from a credit vault intermediary institution and to associate the customer token ID information with the payment vehicle; and
(vi) invoking, at the first POS, an incentive credit based on the customer token ID information.
Claim 12:
(i) a payment vehicle;
(ii) a plurality of POS establishing a node-to-node, for processing a commercial transaction, and configured to enable communications between the plurality of POS and a central entity, and configured to obtain customer token ID information from a credit vault intermediary institution and to associate the customer token ID information with the payment vehicle; and
(iii) a first POS of the plurality of POS, the first POS configured to process the commercial transaction through direct communications with an access point to a central entity, and, when experiencing network communication issues with the access point, further configured to process the commercial transaction through the node-to-node, the first POS further configured to capture transaction data associated with the payment vehicle and further configured to transmit the transaction data, through the node-to-node, and the first POS further configured to invoke an incentive credit based on the customer token ID information.
The following dependent claim limitations, when considered individually and as an ordered combination, are merely further descriptive of abstract concepts:
Claim 3, 14:
further comprising a second POS of the plurality of POS, the second POS in communication with at least one access point to the central entity and configured to transmit the transaction data captured at the first POS, through the node-to- node, to the second POS.
Claim 4:
transmitting, from the second POS to the central entity, through the at least one access point,
information for the commercial transaction.
Claim 5, 9, 15:
further comprising synchronizing the plurality of POS with the transaction data.
Claim 6, 10, 16:
wherein invoking the incentive credit is based on the customer token ID information and network timestamp information.
Claim 7, 11, 17:
wherein invoking the incentive credit is based on globally unique identifier (GUID) information.
The claims provide a manner of using a payment device to process a transaction at a point of sale and providing the user an incentive credit. Thus, when considered individually and as an ordered combination, the claims embody certain methods of organizing human activity. Specifically, such activity is in the form of commercial interactions (in the form of advertising, marketing or sales activities or behaviors).
Step 2A prong 2: This judicial exception is not integrated into a practical application. The claims recite the following additional elements: payment vehicle configured as an RFID band or as an NFC wireless communication object; (claim 1, 8, 12); first POS device of a plurality of POS devices (claim 1, 8, 12, 14); plurality of POS devices (claim 1, 3, 5, 8, 9, 12, 15); network, central network (claim 1, 4, 8, 12); through a node- to-node network established by at least one other POS device of the plurality of POS devices that is in communication with at least one access point to the central network/ node to node network (claim 1, 3, 8, 12); second POS device of a plurality of POS devices (claim 3, 8, 14); the second POS in communication with at least one access point to the central network (claim 3, 4, 14);
The first POS device of a plurality of POS devices, plurality of POS devices, network, central network, second POS device of a plurality of POS devices, and the second POS in communication with at least one access point to the central network are recited at a high level of generality and merely “apply it” (the abstract idea) using generic computing components (spec [0075]). The devices are merely used to process data (capturing, invoking, synchronizing) and send and receive data (transmitting, receiving). Nothing in the claims improves technology or a technical field (See MPEP 2106.05(f)).
The node- to-node network established by at least one other POS device of the plurality of POS devices that is in communication with at least one access point to the central network/ node to node network merely provide a general link to a particular technological environment in which to practice the abstract idea (i.e. peer to peer / node to node environment). Nothing in the claims improves upon peer to peer / node to node technology or a technical field (See MPEP 2106.05(h)).
The payment vehicle configured as an RFID band or as an NFC wireless communication object is recited at a high level of generality and does not go beyond the “apply it” level of implementation. Nothing in the claims improves payment vehicle technology or a technical field (See MPEP 2106.05(f)).
Accordingly, when considered both individually and as an ordered combination, the additional elements do not impose any meaningful limits on practicing the abstract idea.
Step 2B: The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Similarly, as above with regard to practical application, the additional elements when considered both individually and as an ordered combination, do not provide an inventive concept as they merely provide generic computing components used as a tool to implement the abstract idea or provide a general link to a particular technological environment or field of use (i.e. online).
As a result, the claims are not patent eligible.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
Claim(s) 1, 3, 4, 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bonsi (US 2020/0074437) in view of D’Arbeloff et al (US 2003/0009382) in view of Barsoum et al (US 2015/0235256)
As per claim 1:
Bonsi teaches:
A method of providing an incentive credit via a plurality of point of sale (POS) devices having intermittent or unreliable network communications with a central network, comprising:
(i) providing a payment vehicle configured as an RFID band or as an NFC wireless communication object; (paragraph [0075] The customer selects their items for purchase and presents them at the merchant POS device 14. The merchant inputs payment amount or purchase price into the POS app. The customer taps their NFC enabled payment card, mobile device, or dips their chip enabled card, or swipes their card 30 onto the merchant's POS device 14.)
(ii) providing a first POS device of a plurality of POS devices, each of the plurality of POS devices configured to: process a commercial transaction through direct network communications with an access point to a central network or configured to process the commercial transaction through a node- to-node network established by at least one other POS device of the plurality of POS devices that is in communication with at least one access point to the central network, (paragraph [0075] As seen in FIG. 5, the token is first communicated to the mesh network via a BLE radio on the merchants POS device 14. attempts to reach the network for verification of transaction. The application will perform a multi-hop routing protocol to communicate with the AP/gateway 18 across multiple hops. Each user that has the wallet app on a mobile device 16 or POS application in a POS device 14 is a node or a hop in the network. Furthermore, relay nodes 17 may be provided to extend the reach of the mesh network as needed. Every time a user is in proximity of another user with a device, the application orients itself in the array in relation to the closest gateway in the array, given the updated position of the node (14, 16, 17) it is passing. Thus, the application or the node knows the probability or the expected transmission count needed to reach the closest gateway access point 18. The application will choose the shortest number of hops to reach a gateway access point 18.)
(iii) capturing transaction data associated with the payment vehicle, at the first POS device, for processing the commercial transaction; (paragraph [0075] The customer selects their items for purchase and presents them at the merchant POS device 14. The merchant inputs payment amount or purchase price into the POS app. The customer taps their NFC enabled payment card, mobile device, or dips their chip enabled card, or swipes their card 30 onto the merchant's POS device 14. A secure token is transmitted by the POS device 14 via Bluetooth communication protocol. Eventually the token is transmitted to the payment processor as shown in FIG. 5 for confirmation. As illustrated in FIG. 6, the payment processing network 50 (e.g., network used to clear the payment with the credit card or bank server) returns the response (approved or declined) to the gateway access point 18, which in turn communicates the response to the merchant's POS device 18 and (if applicable) the customer's user device 16 via the long range Bluetooth network 12.)
(iv) transmitting the transaction data captured at the first POS device through the network; (Fig. 5; paragraph [0075] As seen in FIG. 5, the token is first communicated to the mesh network via a BLE radio on the merchants POS device 14. attempts to reach the network for verification of transaction. The application will perform a multi-hop routing protocol to communicate with the AP/gateway 18 across multiple hops. Each user that has the wallet app on a mobile device 16 or POS application in a POS device 14 is a node or a hop in the network. As illustrated in FIG. 6, the payment processing network 50 (e.g., network used to clear the payment with the credit card or bank server) returns the response (approved or declined) to the gateway access point 18, which in turn communicates the response to the merchant's POS device 18 and (if applicable) the customer's user device 16 via the long range Bluetooth network 12.)
Bonsi does not expressly teach and configured to obtain customer token ID information from a credit vault intermediary institution and to associate the customer token ID information with the payment vehicle.
D’Arbeloff teaches:
and configured to obtain customer token ID information from a credit vault intermediary institution and to associate the customer token ID information with the payment vehicle; ([0064] A consumer may specifically state his/her wish to be part of a loyalty rewards program and to use his/her payment or debit card as an identifier for the loyalty program. In addition, the merchant payment process 100 keeps the consumers card number private. Specifically, once the consumer's payment or debit card is swiped in the magnetic card reader, or entered by some manner, the merchant payment process 100 encrypts the card's number using a one-way encryption algorithm. Passing it through the customer contact point, the merchant payment process 100 sends the encrypted PIN to an identification database that matches the encrypted number to the buyer's loyalty identification number. The buyer's loyalty identification number is then sent to the loyalty database, which interacts with the customer contact point (POS -see [0054]) to allow the buyer to participate in the seller's loyalty program.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include configured to obtain customer token ID information from a credit vault intermediary institution and to associate the customer token ID information with the payment vehicle as taught by D’Arbeloff with the peer to peer POS network of Bonsi in order to provide consumers simpler, faster, more convenient, and more flexible methods of payment and access to their loyalty rewards ([0003]).
Bonsi in view of D’Arbeloff does not expressly teach (v) receiving, at the first POS device, through the network, the customer token ID information; and (vi) invoking, at the first POS device, an incentive credit based on the customer token ID information.
Barsoum
(v) receiving, at the first POS device, through the network, the customer token ID information; and ([0045] If the loyalty applet is successfully selected, at step 620 the terminal reader 110 sends a command for retrieving the loyalty ID field and redemption points (Loyalty Proprietary Field) from the SE. Based on the input parameters, the loyalty applet matches the stored loyalty ID within the SE, and responds with the loyalty ID and user pre-set redemption points (Loyalty Proprietary Field).
(vi) invoking, at the first POS device, an incentive credit based on the customer token ID information. ([0046] Once read, the terminal reader 110 sends an update loyalty transaction command to the SE to allow the wallet application to determine if the points have been read by the terminal reader 110 (step 630). [0047] The POS terminal 120 then sends a web service call with the loyalty ID and the requested points to the loyalty CRM system 170 for authorization (step 640). [0048] The loyalty CRM system 170 then verifies the loyalty ID and authorizes the requested redemption points. If authorized, the loyalty CRM system 170 responds with response data indicating one of either success, error code, and MaxPointAllowed (same as points requested if success, if not enough, then max points allowed). [0049] The POS terminal 120 then adjusts the final transaction amount by the available points for redemption (step 650).)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include receiving, at the first POS device, through the network, the customer token ID information; and invoking, at the first POS device, an incentive credit based on the customer token ID information as taught by Barsoum with the peer to peer POS network of Bonsi in view of D’Arbeloff in order to provide point-of-sale processing of a loyalty transaction within a standard financial transaction through a contactless interface using contactless NFC communications ([0006]).
Bonsi in view of D’Arbeloff in view of Barsoum teaches the limitations of claim 1. As per claim 3:
Bonsi further teaches:
further comprising providing a second POS device of the plurality of POS devices, the second POS device in communication with at least one access point to the central network and transmitting the transaction data captured at the first POS device, through the node-to-node network, to the second POS device.(Fig. 5; paragraph [0075] The customer selects their items for purchase and presents them at the merchant POS device 14. The merchant inputs payment amount or purchase price into the POS app. The customer taps their NFC enabled payment card, mobile device, or dips their chip enabled card, or swipes their card 30 onto the merchant's POS device 14. A secure token is transmitted by the POS device 14 via Bluetooth communication protocol. Eventually the token is transmitted to the payment processor as shown in FIG. 5 for confirmation. As seen in FIG. 5, the token is first communicated to the mesh network via a BLE radio on the merchants POS device 14. attempts to reach the network for verification of transaction. The application will perform a multi-hop routing protocol to communicate with the AP/gateway 18 across multiple hops. Each user that has the wallet app on a mobile device 16 or POS application in a POS device 14 is a node or a hop in the network. The application will choose the shortest number of hops to reach a gateway access point 18. The gateway access point 18 provides a multi radio (Bluetooth and wifi or ethernet) beacon that has the capabilities to receive encrypted information (such as the token) from the relay nodes 17 or nodes 14, 16 via Bluetooth, wifi radio or ethernet, and then to the payment processing network 50 via a cellular provider 42 or broadband provider 44 that routes data using TCP/IP protocols. As illustrated in FIG. 6, the payment processing network 50 (e.g., network used to clear the payment with the credit card or bank server) returns the response (approved or declined) to the gateway access point 18, which in turn communicates the response to the merchant's POS device 18 and (if applicable) the customer's user device 16 via the long range Bluetooth network 12.)
PNG
media_image1.png
385
584
media_image1.png
Greyscale
Bonsi in view of D’Arbeloff in view of Barsoum teaches the limitations of claim 3. As per claim 4:
Bonsi further teaches:
further comprising transmitting, from the second POS device to the central network, through the at least one access point, information for the commercial transaction. (Fig. 5; paragraph [0075] The customer selects their items for purchase and presents them at the merchant POS device 14. The merchant inputs payment amount or purchase price into the POS app. The customer taps their NFC enabled payment card, mobile device, or dips their chip enabled card, or swipes their card 30 onto the merchant's POS device 14. A secure token is transmitted by the POS device 14 via Bluetooth communication protocol. Eventually the token is transmitted to the payment processor as shown in FIG. 5 for confirmation. As seen in FIG. 5, the token is first communicated to the mesh network via a BLE radio on the merchants POS device 14. attempts to reach the network for verification of transaction. The application will perform a multi-hop routing protocol to communicate with the AP/gateway 18 across multiple hops. Each user that has the wallet app on a mobile device 16 or POS application in a POS device 14 is a node or a hop in the network. The application will choose the shortest number of hops to reach a gateway access point 18. The gateway access point 18 provides a multi radio (Bluetooth and wifi or ethernet) beacon that has the capabilities to receive encrypted information (such as the token) from the relay nodes 17 or nodes 14, 16 via Bluetooth, wifi radio or ethernet, and then to the payment processing network 50 via a cellular provider 42 or broadband provider 44 that routes data using TCP/IP protocols. As illustrated in FIG. 6, the payment processing network 50 (e.g., network used to clear the payment with the credit card or bank server) returns the response (approved or declined) to the gateway access point 18, which in turn communicates the response to the merchant's POS device 18 and (if applicable) the customer's user device 16 via the long range Bluetooth network 12.)
Bonsi in view of D’Arbeloff in view of Barsoum teaches the limitations of claim 1. As per claim 6:
Bonsi does not expressly teach wherein invoking the incentive credit is based on {…} network timestamp information.
D’Arbeloff teaches:
wherein invoking the incentive credit is based on {…} network timestamp information. (claim 1; applying rules specific to the customer, merchant, store and time and routing the loyalty or payment request to an internal loyalty or payment program stored value or in-house charge and/or to one of a plurality of loyalty and/or payment networks. [0029] A system that can apply loyalty rules in real-time including: point programs, frequency programs, club membership, birthday, web registration. [0030] A system that can apply rules specific to a customer, merchant, time, date range and/or store number.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include wherein invoking the incentive credit is based on {…} network timestamp information as taught by D’Arbeloff with the peer to peer POS network of Bonsi in order to provide consumers simpler, faster, more convenient, and more flexible methods of payment and access to their loyalty rewards ([0003]).
Bonsi in view of D’Arbeloff does not expressly teach wherein invoking the incentive credit is based on the customer token ID information.
Barsoum teaches:
wherein invoking the incentive credit is based on the customer token ID information {…} ([0046] Once read, the terminal reader 110 sends an update loyalty transaction command to the SE to allow the wallet application to determine if the points have been read by the terminal reader 110 (step 630). [0047] The POS terminal 120 then sends a web service call with the loyalty ID and the requested points to the loyalty CRM system 170 for authorization (step 640). [0048] The loyalty CRM system 170 then verifies the loyalty ID and authorizes the requested redemption points. If authorized, the loyalty CRM system 170 responds with response data indicating one of either success, error code, and MaxPointAllowed (same as points requested if success, if not enough, then max points allowed). [0049] The POS terminal 120 then adjusts the final transaction amount by the available points for redemption (step 650).)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include r wherein invoking the incentive credit is based on the customer token ID information as taught by Barsoum with the peer to peer POS network of Bonsi in view of D’Arbeloff in order to provide point-of-sale processing of a loyalty transaction within a standard financial transaction through a contactless interface using contactless NFC communications ([0006]).
Claim(s) 5, 8, 9, 10, 12, 14, 15, 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bonsi (US 2020/0074437) in view of D’Arbeloff et al (US 2003/0009382) in view of Barsoum et al (US 2015/0235256) in view of Siefken et al (US 2020/0005267)
Bonsi in view of D’Arbeloff in view of Barsoum teaches the limitations of claim 1. As per claim 5:
Bonsi in view of D’Arbeloff in view of Barsoum does not expressly teach further comprising synchronizing the plurality of POS devices with the transaction data.
Siefken teaches:
further comprising synchronizing the plurality of POS devices with the transaction data. (paragraph [0038] The blockchain itself may be stored in the POS terminals connected via the network. [0046] In at least one embodiment, the network 111 is configured to communicate with individual POS terminals therein such that complete replication of data on a plurality of terminals is effectuated. By implementing peer-to-peer communication, a common set of data may be shared between POS terminals at any given site. The blockchain stores a fingerprint (a blockchain entity) which uniquely identifies the ledger, the chain index, and the current hash associated with a transaction. More particularly, each fingerprint is broadcast by each node (e.g., individual terminal) in the blockchain, together with a node identifier and node address. Each node receiving the broadcast compares the broadcast fingerprint (entity) to the blockchain entity stored by that node. Any discrepancy or mismatch between the stored entity and the broadcast entity requires the node to request an updated entity from the broadcasting node via the node address. Each node then validates the received entity and attempts to resolve any conflicts. After conflict resolution and validation, the node stores the updated blockchain, such that all nodes are updated with the current blockchain.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include synchronizing the plurality of POS devices with the transaction data as taught by Siefken with the node to node payment network of Bonsi in view of D’Arbeloff in view of Barsoum in order to ensure that data for a significant business time period may be preserved even when server access is unavailable (paragraph [0066]).
As per claim 8:
Bonsi teaches:
A method of providing an incentive credit via a customer relationship management (CRM) system operating on a plurality of point of sale (POS) devices having intermittent or unreliable network communications with a central network, comprising:
(i) providing a payment vehicle configured as an RFID band or as an NFC wireless communication object; (paragraph [0075] The customer selects their items for purchase and presents them at the merchant POS device 14. The merchant inputs payment amount or purchase price into the POS app. The customer taps their NFC enabled payment card, mobile device, or dips their chip enabled card, or swipes their card 30 onto the merchant's POS device 14.)
(ii) providing a first POS device of a plurality of POS devices, the first POS device configured to process a commercial transaction {…} further configured to process the commercial transaction through a node-to-node network; (paragraph [0075] As seen in FIG. 5, the token is first communicated to the mesh network via a BLE radio on the merchants POS device 14. attempts to reach the network for verification of transaction. The application will perform a multi-hop routing protocol to communicate with the AP/gateway 18 across multiple hops. Each user that has the wallet app on a mobile device 16 or POS application in a POS device 14 is a node or a hop in the network. Furthermore, relay nodes 17 may be provided to extend the reach of the mesh network as needed. Every time a user is in proximity of another user with a device, the application orients itself in the array in relation to the closest gateway in the array, given the updated position of the node (14, 16, 17) it is passing. Thus, the application or the node knows the probability or the expected transmission count needed to reach the closest gateway access point 18. The application will choose the shortest number of hops to reach a gateway access point 18. The {…} indicates a modification to the claim language to show what is expressly taught by Bonsi. Limitations regarding the POS directly connecting to an access point and experiencing connectivity issues will be addressed below by Siefken.)
(iii) capturing transaction data associated with the payment vehicle, at the first POS device, for processing the commercial transaction; (paragraph [0075] The customer selects their items for purchase and presents them at the merchant POS device 14. The merchant inputs payment amount or purchase price into the POS app. The customer taps their NFC enabled payment card, mobile device, or dips their chip enabled card, or swipes their card 30 onto the merchant's POS device 14. A secure token is transmitted by the POS device 14 via Bluetooth communication protocol. Eventually the token is transmitted to the payment processor as shown in FIG. 5 for confirmation. As illustrated in FIG. 6, the payment processing network 50 (e.g., network used to clear the payment with the credit card or bank server) returns the response (approved or declined) to the gateway access point 18, which in turn communicates the response to the merchant's POS device 18 and (if applicable) the customer's user device 16 via the long range Bluetooth network 12.)
(iv) providing a second POS device of the plurality of POS devices, the second POS device in communication with the least one access point to the central network; (Fig. 5; paragraph [0075] As seen in FIG. 5, the token is first communicated to the mesh network via a BLE radio on the merchants POS device 14. attempts to reach the network for verification of transaction. The application will perform a multi-hop routing protocol to communicate with the AP/gateway 18 across multiple hops. Each user that has the wallet app on a mobile device 16 or POS application in a POS device 14 is a node or a hop in the network.)
(v) establishing, with the plurality of POS devices, the node-to-node network for processing the commercial transaction, the node-to-node network configured to enable communications between the plurality of POS devices and the central network, (Fig. 5; paragraph [0075] As seen in FIG. 5, the token is first communicated to the mesh network via a BLE radio on the merchants POS device 14. attempts to reach the network for verification of transaction. The application will perform a multi-hop routing protocol to communicate with the AP/gateway 18 across multiple hops. Each user that has the wallet app on a mobile device 16 or POS application in a POS device 14 is a node or a hop in the network. As illustrated in FIG. 6, the payment processing network 50 (e.g., network used to clear the payment with the credit card or bank server) returns the response (approved or declined) to the gateway access point 18, which in turn communicates the response to the merchant's POS device 18 and (if applicable) the customer's user device 16 via the long range Bluetooth network 12.)
Bonsi does not expressly teach and configured to obtain customer token ID information from a credit vault intermediary institution and to associate the customer token ID information with the payment vehicle.
D’Arbeloff teaches:
and configured to obtain customer token ID information from a credit vault intermediary institution and to associate the customer token ID information with the payment vehicle ([0064] A consumer may specifically state his/her wish to be part of a loyalty rewards program and to use his/her payment or debit card as an identifier for the loyalty program. In addition, the merchant payment process 100 keeps the consumers card number private. Specifically, once the consumer's payment or debit card is swiped in the magnetic card reader, or entered by some manner, the merchant payment process 100 encrypts the card's number using a one-way encryption algorithm. Passing it through the customer contact point, the merchant payment process 100 sends the encrypted PIN to an identification database that matches the encrypted number to the buyer's loyalty identification number. The buyer's loyalty identification number is then sent to the loyalty database, which interacts with the customer contact point (POS -see [0054]) to allow the buyer to participate in the seller's loyalty program.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include configured to obtain customer token ID information from a credit vault intermediary institution and to associate the customer token ID information with the payment vehicle as taught by D’Arbeloff with the peer to peer POS network of Bonsi in order to provide consumers simpler, faster, more convenient, and more flexible methods of payment and access to their loyalty rewards ([0003]).
Bonsi in view of D’Arbeloff does not expressly teach (vi) invoking, at the first POS device, an incentive credit based on the customer token ID information.
Barsoum teaches
(vi) invoking, at the first POS device, an incentive credit based on the customer token ID information. ([0045] If the loyalty applet is successfully selected, at step 620 the terminal reader 110 sends a command for retrieving the loyalty ID field and redemption points (Loyalty Proprietary Field) from the SE. Based on the input parameters, the loyalty applet matches the stored loyalty ID within the SE, and responds with the loyalty ID and user pre-set redemption points (Loyalty Proprietary Field).[0046] Once read, the terminal reader 110 sends an update loyalty transaction command to the SE to allow the wallet application to determine if the points have been read by the terminal reader 110 (step 630). [0047] The POS terminal 120 then sends a web service call with the loyalty ID and the requested points to the loyalty CRM system 170 for authorization (step 640). [0048] The loyalty CRM system 170 then verifies the loyalty ID and authorizes the requested redemption points. If authorized, the loyalty CRM system 170 responds with response data indicating one of either success, error code, and MaxPointAllowed (same as points requested if success, if not enough, then max points allowed). [0049] The POS terminal 120 then adjusts the final transaction amount by the available points for redemption (step 650).)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include invoking, at the first POS device, an incentive credit based on the customer token ID information as taught by Barsoum with the peer to peer POS network of Bonsi in view of D’Arbeloff in order to provide point-of-sale processing of a loyalty transaction within a standard financial transaction through a contactless interface using contactless NFC communications ([0006]).
Bonsi in view of D’Arbeloff in view of Barosum does not expressly teach {a POS for processing a transaction} through direct network communications with an access point to a central network, and, when experiencing network communication issues with the access point, {process the payment through the node to node network}
Seifken teaches:
{a POS for processing a transaction} through direct network communications with an access point to a central network, and, when experiencing network communication issues with the access point, {process the payment through the node to node network} (Fig 11 – POS 1 directly connected to cloud server; paragraph [0064] FIG. 11 depicts a system according to at least one embodiment, including process operations during a period when connectivity is absent. More particularly, as shown in FIG. 11, a plurality of POS terminals (POS1, POS2, POS3, POS4) are connected. The processing utilizing the components described above differs when a POS is disconnected from the network and therefore not communicating with server 109, i.e., during periods of downtime. Dashed lines between the POSs indicate periods of disconnectivity or weak connectivity, whereas solid lines depict periods of sufficient connectivity to permit better communication. When a POS is disconnected from the network, processing according to at least one embodiment occurs in the following manner. [0065] When a POS is disconnected from server 109 due to a network connectivity issue, a daily chain is created between connected destinations (e.g., POSs) until a predetermined time (e.g., a start of a business period, such as a new business day).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include using the relay of information from one node to another to complete the transaction when detecting a connection issue with one of the POS devices to an access point or reconciling the transaction using the node to node network as taught by Siefken with the node to node payment network of Bonsi in view of D’Arbeloff in view of Barosum in order to ensure that data for a significant business time period may be preserved even when server access is unavailable (paragraph [0066]).
Bonsi in view of D’Arbeloff in view of Barsoum in view of Seifken teaches the limitations of claim 8. As per claim 9:
Bonsi in view of D’Arbeloff in view of Barsoum does not expressly teach further comprising synchronizing the plurality of POS devices with the transaction data.
Siefken teaches:
further comprising synchronizing the plurality of POS devices with the transaction data. (paragraph [0038] The blockchain itself may be stored in the POS terminals connected via the network. [0046] In at least one embodiment, the network 111 is configured to communicate with individual POS terminals therein such that complete replication of data on a plurality of terminals is effectuated. By implementing peer-to-peer communication, a common set of data may be shared between POS terminals at any given site. The blockchain stores a fingerprint (a blockchain entity) which uniquely identifies the ledger, the chain index, and the current hash associated with a transaction. More particularly, each fingerprint is broadcast by each node (e.g., individual terminal) in the blockchain, together with a node identifier and node address. Each node receiving the broadcast compares the broadcast fingerprint (entity) to the blockchain entity stored by that node. Any discrepancy or mismatch between the stored entity and the broadcast entity requires the node to request an updated entity from the broadcasting node via the node address. Each node then validates the received entity and attempts to resolve any conflicts. After conflict resolution and validation, the node stores the updated blockchain, such that all nodes are updated with the current blockchain.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include synchronizing the plurality of POS devices with the transaction data as taught by Siefken with the node to node payment network of Bonsi in view of D’Arbeloff in view of Barsoum in order to ensure that data for a significant business time period may be preserved even when server access is unavailable (paragraph [0066]).
Bonsi in view of D’Arbeloff in view of Barsoum in view of Seifken teaches the limitations of claim 8. As per claim 10:
Bonsi in view of Seifken does not expressly teach wherein invoking the incentive credit is based on {…} network timestamp information.
D’Arbeloff teaches:
wherein invoking the incentive credit is based on {…} network timestamp information. (claim 1; applying rules specific to the customer, merchant, store and time and routing the loyalty or payment request to an internal loyalty or payment program stored value or in-house charge and/or to one of a plurality of loyalty and/or payment networks. [0029] A system that can apply loyalty rules in real-time including: point programs, frequency programs, club membership, birthday, web registration. [0030] A system that can apply rules specific to a customer, merchant, time, date range and/or store number.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include wherein invoking the incentive credit is based on {…} network timestamp information as taught by D’Arbeloff with the peer to peer POS network of Bonsi in view of Seifken in order to provide consumers simpler, faster, more convenient, and more flexible methods of payment and access to their loyalty rewards ([0003]).
Bonsi in view of D’Arbeloff in view of Seifken does not expressly teach wherein invoking the incentive credit is based on the customer token ID information.
Barsoum teaches:
wherein invoking the incentive credit is based on the customer token ID information {…} ([0046] Once read, the terminal reader 110 sends an update loyalty transaction command to the SE to allow the wallet application to determine if the points have been read by the terminal reader 110 (step 630). [0047] The POS terminal 120 then sends a web service call with the loyalty ID and the requested points to the loyalty CRM system 170 for authorization (step 640). [0048] The loyalty CRM system 170 then verifies the loyalty ID and authorizes the requested redemption points. If authorized, the loyalty CRM system 170 responds with response data indicating one of either success, error code, and MaxPointAllowed (same as points requested if success, if not enough, then max points allowed). [0049] The POS terminal 120 then adjusts the final transaction amount by the available points for redemption (step 650).)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include r wherein invoking the incentive credit is based on the customer token ID information as taught by Barsoum with the peer to peer POS network of Bonsi in view of D’Arbeloff in view of Seifken in order to provide point-of-sale processing of a loyalty transaction within a standard financial transaction through a contactless interface using contactless NFC communications ([0006]).
As per claim 12:
Bonsi teaches:
A plurality of point of sale (POS) devices having intermittent or unreliable network communications, for providing an incentive credit,
comprising:
(i) a payment vehicle configured as an RFID band or as an NFC wireless communication object; (paragraph [0075] The customer selects their items for purchase and presents them at the merchant POS device 14. The merchant inputs payment amount or purchase price into the POS app. The customer taps their NFC enabled payment card, mobile device, or dips their chip enabled card, or swipes their card 30 onto the merchant's POS device 14.)
(ii) a plurality of POS devices establishing a node-to-node network, for processing a commercial transaction, and configured to enable communications between the plurality of POS devices and a central network, (paragraph [0075] As seen in FIG. 5, the token is first communicated to the mesh network via a BLE radio on the merchants POS device 14. attempts to reach the network for verification of transaction. The application will perform a multi-hop routing protocol to communicate with the AP/gateway 18 across multiple hops. Each user that has the wallet app on a mobile device 16 or POS application in a POS device 14 is a node or a hop in the network. Furthermore, relay nodes 17 may be provided to extend the reach of the mesh network as needed. Every time a user is in proximity of another user with a device, the application orients itself in the array in relation to the closest gateway in the array, given the updated position of the node (14, 16, 17) it is passing. Thus, the application or the node knows the probability or the expected transmission count needed to reach the closest gateway access point 18. The application will choose the shortest number of hops to reach a gateway access point 18.)
(iii) a first POS device of the plurality of POS devices, the first POS device configured to process the commercial transaction {…} further configured to process the commercial transaction through the node-to-node network, (paragraph [0075] As seen in FIG. 5, the token is first communicated to the mesh network via a BLE radio on the merchants POS device 14. attempts to reach the network for verification of transaction. The application will perform a multi-hop routing protocol to communicate with the AP/gateway 18 across multiple hops. Each user that has the wallet app on a mobile device 16 or POS application in a POS device 14 is a node or a hop in the network. Furthermore, relay nodes 17 may be provided to extend the reach of the mesh network as needed. Every time a user is in proximity of another user with a device, the application orients itself in the array in relation to the closest gateway in the array, given the updated position of the node (14, 16, 17) it is passing. Thus, the application or the node knows the probability or the expected transmission count needed to reach the closest gateway access point 18. The application will choose the shortest number of hops to reach a gateway access point 18. The {…} indicates a modification to the claim language to show what is expressly taught by Bonsi. Limitations regarding the POS directly connecting to an access point and experiencing connectivity issues will be addressed below by Siefken.)
the first POS device further configured to capture transaction data associated with the payment vehicle (paragraph [0075] The customer selects their items for purchase and presents them at the merchant POS device 14. The merchant inputs payment amount or purchase price into the POS app. The customer taps their NFC enabled payment card, mobile device, or dips their chip enabled card, or swipes their card 30 onto the merchant's POS device 14. A secure token is transmitted by the POS device 14 via Bluetooth communication protocol. Eventually the token is transmitted to the payment processor as shown in FIG. 5 for confirmation. As illustrated in FIG. 6, the payment processing network 50 (e.g., network used to clear the payment with the credit card or bank server) returns the response (approved or declined) to the gateway access point 18, which in turn communicates the response to the merchant's POS device 18 and (if applicable) the customer's user device 16 via the long range Bluetooth network 12.)
and further configured to transmit the transaction data, through the node-to-node network, (Fig. 5; paragraph [0075] As seen in FIG. 5, the token is first communicated to the mesh network via a BLE radio on the merchants POS device 14. attempts to reach the network for verification of transaction. The application will perform a multi-hop routing protocol to communicate with the AP/gateway 18 across multiple hops. Each user that has the wallet app on a mobile device 16 or POS application in a POS device 14 is a node or a hop in the network. As illustrated in FIG. 6, the payment processing network 50 (e.g., network used to clear the payment with the credit card or bank server) returns the response (approved or declined) to the gateway access point 18, which in turn communicates the response to the merchant's POS device 18 and (if applicable) the customer's user device 16 via the long range Bluetooth network 12.)
Bonsi does not expressly teach and configured to obtain customer token ID information from a credit vault intermediary institution and to associate the customer token ID information with the payment vehicle.
D’Arbeloff teaches:
and configured to obtain customer token ID information from a credit vault intermediary institution and to associate the customer token ID information with the payment vehicle; ([0064] A consumer may specifically state his/her wish to be part of a loyalty rewards program and to use his/her payment or debit card as an identifier for the loyalty program. In addition, the merchant payment process 100 keeps the consumers card number private. Specifically, once the consumer's payment or debit card is swiped in the magnetic card reader, or entered by some manner, the merchant payment process 100 encrypts the card's number using a one-way encryption algorithm. Passing it through the customer contact point, the merchant payment process 100 sends the encrypted PIN to an identification database that matches the encrypted number to the buyer's loyalty identification number. The buyer's loyalty identification number is then sent to the loyalty database, which interacts with the customer contact point (POS -see [0054]) to allow the buyer to participate in the seller's loyalty program.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include configured to obtain customer token ID information from a credit vault intermediary institution and to associate the customer token ID information with the payment vehicle as taught by D’Arbeloff with the peer to peer POS network of Bonsi in order to provide consumers simpler, faster, more convenient, and more flexible methods of payment and access to their loyalty rewards ([0003]).
Bonsi in view of D’Arbeloff does not expressly teach and the first POS device further configured to invoke an incentive credit based on the customer token ID information.
Barsoum teaches
and the first POS device further configured to invoke an incentive credit based on the customer token ID information ([0045] If the loyalty applet is successfully selected, at step 620 the terminal reader 110 sends a command for retrieving the loyalty ID field and redemption points (Loyalty Proprietary Field) from the SE. Based on the input parameters, the loyalty applet matches the stored loyalty ID within the SE, and responds with the loyalty ID and user pre-set redemption points (Loyalty Proprietary Field).[0046] Once read, the terminal reader 110 sends an update loyalty transaction command to the SE to allow the wallet application to determine if the points have been read by the terminal reader 110 (step 630). [0047] The POS terminal 120 then sends a web service call with the loyalty ID and the requested points to the loyalty CRM system 170 for authorization (step 640). [0048] The loyalty CRM system 170 then verifies the loyalty ID and authorizes the requested redemption points. If authorized, the loyalty CRM system 170 responds with response data indicating one of either success, error code, and MaxPointAllowed (same as points requested if success, if not enough, then max points allowed). [0049] The POS terminal 120 then adjusts the final transaction amount by the available points for redemption (step 650).)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include and the first POS device further configured to invoke an incentive credit based on the customer token ID information as taught by Barsoum with the peer to peer POS network of Bonsi in view of D’Arbeloff in order to provide point-of-sale processing of a loyalty transaction within a standard financial transaction through a contactless interface using contactless NFC communications ([0006]).
Bonsi in view of D’Arbeloff in view of Barosum does not expressly teach {a POS for processing a transaction} through direct network communications with an access point to a central network, and, when experiencing network communication issues with the access point, {process the payment through the node to node network}
Seifken teaches:
{a POS for processing a transaction} through direct network communications with an access point to a central network, and, when experiencing network communication issues with the access point, {process the payment through the node to node network} (Fig 11 – POS 1 directly connected to cloud server; paragraph [0064] FIG. 11 depicts a system according to at least one embodiment, including process operations during a period when connectivity is absent. More particularly, as shown in FIG. 11, a plurality of POS terminals (POS1, POS2, POS3, POS4) are connected. The processing utilizing the components described above differs when a POS is disconnected from the network and therefore not communicating with server 109, i.e., during periods of downtime. Dashed lines between the POSs indicate periods of disconnectivity or weak connectivity, whereas solid lines depict periods of sufficient connectivity to permit better communication. When a POS is disconnected from the network, processing according to at least one embodiment occurs in the following manner. [0065] When a POS is disconnected from server 109 due to a network connectivity issue, a daily chain is created between connected destinations (e.g., POSs) until a predetermined time (e.g., a start of a business period, such as a new business day).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include using the relay of information from one node to another to complete the transaction when detecting a connection issue with one of the POS devices to an access point or reconciling the transaction using the node to node network as taught by Siefken with the node to node payment network of Bonsi in view of D’Arbeloff in view of Barosum in order to ensure that data for a significant business time period may be preserved even when server access is unavailable (paragraph [0066]).
Bonsi in view of D’Arbeloff in view of Barsoum in view of Siefken teaches the limitations of claim 12. As per claim 14:
Bonsi further teaches:
further comprising a second POS device of the plurality of POS devices, the second POS device in communication with at least one access point to the central network and configured to transmit the transaction data captured at the first POS device, through the node-to- node network, to the second POS device Fig. 5; paragraph [0075] The customer selects their items for purchase and presents them at the merchant POS device 14. The merchant inputs payment amount or purchase price into the POS app. The customer taps their NFC enabled payment card, mobile device, or dips their chip enabled card, or swipes their card 30 onto the merchant's POS device 14. A secure token is transmitted by the POS device 14 via Bluetooth communication protocol. Eventually the token is transmitted to the payment processor as shown in FIG. 5 for confirmation. As seen in FIG. 5, the token is first communicated to the mesh network via a BLE radio on the merchants POS device 14. attempts to reach the network for verification of transaction. The application will perform a multi-hop routing protocol to communicate with the AP/gateway 18 across multiple hops. Each user that has the wallet app on a mobile device 16 or POS application in a POS device 14 is a node or a hop in the network. The application will choose the shortest number of hops to reach a gateway access point 18. The gateway access point 18 provides a multi radio (Bluetooth and wifi or ethernet) beacon that has the capabilities to receive encrypted information (such as the token) from the relay nodes 17 or nodes 14, 16 via Bluetooth, wifi radio or ethernet, and then to the payment processing network 50 via a cellular provider 42 or broadband provider 44 that routes data using TCP/IP protocols. As illustrated in FIG. 6, the payment processing network 50 (e.g., network used to clear the payment with the credit card or bank server) returns the response (approved or declined) to the gateway access point 18, which in turn communicates the response to the merchant's POS device 18 and (if applicable) the customer's user device 16 via the long range Bluetooth network 12.)
PNG
media_image1.png
385
584
media_image1.png
Greyscale
Bonsi in view of D’Arbeloff in view of Barsoum in view of Seifken teaches the limitations of claim 14. As per claim 15:
Bonsi in view of D’Arbeloff in view of Barsoum does not expressly teach further comprising synchronizing the plurality of POS devices with the transaction data.
Siefken teaches:
wherein the second POS device is further configured to synchronize the plurality of POS devices with the transaction data. (paragraph [0038] The blockchain itself may be stored in the POS terminals connected via the network. [0046] In at least one embodiment, the network 111 is configured to communicate with individual POS terminals therein such that complete replication of data on a plurality of terminals is effectuated. By implementing peer-to-peer communication, a common set of data may be shared between POS terminals at any given site. The blockchain stores a fingerprint (a blockchain entity) which uniquely identifies the ledger, the chain index, and the current hash associated with a transaction. More particularly, each fingerprint is broadcast by each node (e.g., individual terminal) in the blockchain, together with a node identifier and node address. Each node receiving the broadcast compares the broadcast fingerprint (entity) to the blockchain entity stored by that node. Any discrepancy or mismatch between the stored entity and the broadcast entity requires the node to request an updated entity from the broadcasting node via the node address. Each node then validates the received entity and attempts to resolve any conflicts. After conflict resolution and validation, the node stores the updated blockchain, such that all nodes are updated with the current blockchain.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include synchronizing the plurality of POS devices with the transaction data as taught by Siefken with the node to node payment network of Bonsi in view of D’Arbeloff in view of Barsoum in order to ensure that data for a significant business time period may be preserved even when server access is unavailable (paragraph [0066]).
Bonsi in view of D’Arbeloff in view of Barsoum in view of Seifken teaches the limitations of claim 14. As per claim 16:
Bonsi in view of Seifken does not expressly teach wherein invoking the incentive credit is based on {…} network timestamp information.
D’Arbeloff teaches:
Invoke the incentive credit is based on {…} network timestamp information. (claim 1; applying rules specific to the customer, merchant, store and time and routing the loyalty or payment request to an internal loyalty or payment program stored value or in-house charge and/or to one of a plurality of loyalty and/or payment networks. [0029] A system that can apply loyalty rules in real-time including: point programs, frequency programs, club membership, birthday, web registration. [0030] A system that can apply rules specific to a customer, merchant, time, date range and/or store number.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include wherein invoking the incentive credit is based on {…} network timestamp information as taught by D’Arbeloff with the peer to peer POS network of Bonsi in view of Seifken in order to provide consumers simpler, faster, more convenient, and more flexible methods of payment and access to their loyalty rewards ([0003]).
Bonsi in view of D’Arbeloff in view of Seifken does not expressly teach wherein invoking the incentive credit is based on the customer token ID information.
Barsoum teaches:
wherein the first POS device is configured to invoke the incentive credit is based on the customer token ID information {…} ([0046] Once read, the terminal reader 110 sends an update loyalty transaction command to the SE to allow the wallet application to determine if the points have been read by the terminal reader 110 (step 630). [0047] The POS terminal 120 then sends a web service call with the loyalty ID and the requested points to the loyalty CRM system 170 for authorization (step 640). [0048] The loyalty CRM system 170 then verifies the loyalty ID and authorizes the requested redemption points. If authorized, the loyalty CRM system 170 responds with response data indicating one of either success, error code, and MaxPointAllowed (same as points requested if success, if not enough, then max points allowed). [0049] The POS terminal 120 then adjusts the final transaction amount by the available points for redemption (step 650).)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include r wherein invoking the incentive credit is based on the customer token ID information as taught by Barsoum with the peer to peer POS network of Bonsi in view of D’Arbeloff in view of Seifken in order to provide point-of-sale processing of a loyalty transaction within a standard financial transaction through a contactless interface using contactless NFC communications ([0006]).
Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bonsi (US 2020/0074437) in view of D’Arbeloff et al (US 2003/0009382) in view of Barsoum et al (US 2015/0235256) in view of Fordyce et al (US 2008/0059306)
Bonsi in view of D’Arbeloff in view of Barsoum teaches the limitations of claim 1. As per claim 7:
Bonsi in view of D’Arbeloff in view of Barsoum does not expressly teach wherein invoking the incentive credit is based on globally unique identifier (GUID) information.
Fordyce teaches:
wherein invoking the incentive credit is based on globally unique identifier (GUID) information. (paragraph [0009] The determination of a loyalty program incentive for a transaction between a consumer and a merchant is facilitated using an identifier (GUID) for a merchant that is globally unique within a payment processing system. In one implementation, data regarding the transaction includes the GUID for the merchant and an identifier for an account (e.g., account number) that the transaction is payable on. The GUIDs for the merchant and the account are matched against GUIDs for a plurality of merchants and accounts, respectively, within a database. The database, such as a loyalty program database, can have at least one account and one merchant that are each distinguished, in association with the database, as a loyalty program participant. When both the GUID for the merchant and the identifier for the account find corresponding matches in the database and the matches reveal that the account and the merchant are participants of the loyalty program, the transaction is eligible towards an incentive for the loyalty program. The GUID for the merchant may be derived given a merchant code that may not be unique within the payment processing system. Moreover, the determination of the eligibility of the transaction toward the incentive may further entail matching a good or a service identifier (e.g., Stock Keeping Unit number) against identifiers of goods or services within the database, wherein some of the identifiers of the goods or services in the database are distinguished, in association with the database, as a participant of the loyalty program.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include w wherein invoking the incentive credit is based on globally unique identifier (GUID) information as taught by Fordyce with the peer to peer POS network of Bonsi in view of D’Arbeloff in view of Barsoum in order to identify merchants participating in a loyalty program (paragraph [0009]).
Claim(s) 11, 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bonsi (US 2020/0074437) in view of D’Arbeloff et al (US 2003/0009382) in view of Barsoum et al (US 2015/0235256) in view of Siefken et al (US 2020/0005267) in view of Fordyce et al (US 2008/0059306)
Bonsi in view of D’Arbeloff in view of Barsoum in view of Seifken teaches the limitations of claim 8. As per claim 11:
Bonsi in view of D’Arbeloff in view of Barsoum in view of Seifken does not expressly teach wherein invoking the incentive credit is based on globally unique identifier (GUID) information.
Fordyce teaches:
wherein invoking the incentive credit is based on globally unique identifier (GUID) information. (paragraph [0009] The determination of a loyalty program incentive for a transaction between a consumer and a merchant is facilitated using an identifier (GUID) for a merchant that is globally unique within a payment processing system. In one implementation, data regarding the transaction includes the GUID for the merchant and an identifier for an account (e.g., account number) that the transaction is payable on. The GUIDs for the merchant and the account are matched against GUIDs for a plurality of merchants and accounts, respectively, within a database. The database, such as a loyalty program database, can have at least one account and one merchant that are each distinguished, in association with the database, as a loyalty program participant. When both the GUID for the merchant and the identifier for the account find corresponding matches in the database and the matches reveal that the account and the merchant are participants of the loyalty program, the transaction is eligible towards an incentive for the loyalty program. The GUID for the merchant may be derived given a merchant code that may not be unique within the payment processing system. Moreover, the determination of the eligibility of the transaction toward the incentive may further entail matching a good or a service identifier (e.g., Stock Keeping Unit number) against identifiers of goods or services within the database, wherein some of the identifiers of the goods or services in the database are distinguished, in association with the database, as a participant of the loyalty program.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include w wherein invoking the incentive credit is based on globally unique identifier (GUID) information as taught by Fordyce with the peer to peer POS network of Bonsi in view of D’Arbeloff in view of Barsoum in view of Seifken in order to identify merchants participating in a loyalty program (paragraph [0009]).
Bonsi in view of D’Arbeloff in view of Barsoum in view of Seifken teaches the limitations of claim 14. As per claim 17:
Bonsi in view of D’Arbeloff in view of Barsoum in view of Seifken does not expressly teach wherein the first POS device is configured to invoke the incentive credit based on GUID information.
Fordyce teaches:
wherein the first POS device is configured to invoke the incentive credit based on GUID information. (paragraph [0009] The determination of a loyalty program incentive for a transaction between a consumer and a merchant is facilitated using an identifier (GUID) for a merchant that is globally unique within a payment processing system. In one implementation, data regarding the transaction includes the GUID for the merchant and an identifier for an account (e.g., account number) that the transaction is payable on. The GUIDs for the merchant and the account are matched against GUIDs for a plurality of merchants and accounts, respectively, within a database. The database, such as a loyalty program database, can have at least one account and one merchant that are each distinguished, in association with the database, as a loyalty program participant. When both the GUID for the merchant and the identifier for the account find corresponding matches in the database and the matches reveal that the account and the merchant are participants of the loyalty program, the transaction is eligible towards an incentive for the loyalty program. The GUID for the merchant may be derived given a merchant code that may not be unique within the payment processing system. Moreover, the determination of the eligibility of the transaction toward the incentive may further entail matching a good or a service identifier (e.g., Stock Keeping Unit number) against identifiers of goods or services within the database, wherein some of the identifiers of the goods or services in the database are distinguished, in association with the database, as a participant of the loyalty program.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include wherein the first POS device is configured to invoke the incentive credit based on GUID information as taught by Fordyce with the peer to peer POS network of Bonsi in view of D’Arbeloff in view of Barsoum in view of Seifken in order to identify merchants participating in a loyalty program (paragraph [0009]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTOPHER STROUD whose telephone number is (571)272-7930. The examiner can normally be reached Mon. - Fri. 9AM-5PM.
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, Waseem Ashraff can be reached at (571) 270-3948. 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.
CHRISTOPHER STROUD
Primary Examiner
Art Unit 3621
/CHRISTOPHER STROUD/ Primary Examiner, Art Unit 3621
Prosecution Insights