DETAILED ACTION
This is a final office action on the merits. The U.S. Patent and Trademark Office (the Office) has received claims 1 – 20.
Claims 1, 5, 6, 9, 12, 16, and 17 are amended.
Claims 7 and 13 are canceled.
Claims 1-6, 8-12, and 14-20 are pending and have been examined on the merits.
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 .
Response to Arguments
Claim Objections
Applicant’s arguments, filed 9/30/2025, with respect to the “Claim Objections” have been fully considered and are persuasive. The Claim Objections of claims 16 and 17 has been withdrawn.
101 Rejection
Applicant’s arguments, filed 9/30/2025, with respect to the “101 Rejection” have been fully considered and are persuasive. The 101 Rejection of claims 1-20 has been withdrawn.
103 Rejection
Applicant's arguments filed have been fully considered but they are not persuasive.
Applicant argument: Malhotra and Jabbour are silent about two different transfer applications interacting using a digital tag.
Jabbour teaches that a user application tag is associated in a backend system and also associated in a separate POS system, and that the backend retrieves/matches application tags between systems (see ¶ 0110-0112). This is the same claimed concept of a digital tag being recognized/used across different platforms.
Applicant argument: Digital tag must be recognized in a first transfer app server but generated in a second transfer app server.
Jabbour teaches backend assigns/associates the user tag and separately the POS stores/uses the tag, meaning the tag is generated/managed in one system and relied on in another (see ¶ 0110).
The newly amended claims have been rejected as below.
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 inquires set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1066), that are applied for establishing a background for determining obviousness under 35 U.S.C. § 103 are summarized as follows:
Determining the scope and contents of the prior art.
Ascertaining the differences between the prior art and the claims at issue.
Resolving the level of ordinary skill in the pertinent art.
Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-6, 8-12, and 14-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Malhotra et al. (US20170364910A1) hereinafter Malhotra in view of Jabbour et al. (US20210374837A1) hereinafter Jabbour in further view of Wilson et. al (US20120284175A1) hereinafter Wilson.
Regarding Claims 1 and 16. Malhotra teaches: a method, a processor, and a non-transitory computer readable medium, the non-transitory computer readable medium comprising code, executable by the processor to perform operations comprising: receiving, by a digital tag computer from a first transfer application on a first user device associated with a first user, a transfer request message for a transfer transaction, the transfer request message comprising a digital tag associated with a second user and a transaction amount,
Malhotra - receiving a funds transfer request…The request is for requesting a funds transfer (Abstract). funds transfer request is received that includes such an alias as a beneficiary account designation, an alias directory is accessed to translate the alias into the relevant destination account details (¶ 0012). The service provider (first user device) 320 may be in communication with the gateway computer (digital tag computer) 306 to allow the service provider 320 to benefit from alias translation services (¶ 0035). including the merchant's bank account details and the transaction amount. The acquirer computer 106 may receive a payment account system authorization request message for the transaction from the merchant device 104 (The acquirer computer 106 may receive a payment account system authorization request message for the transaction from the merchant device 104 (¶ 0016). For example, the payment card issuer server computer 110 may perform such functions as (a) receiving and responding to requests for authorization of payment account transactions to be charged to payment accounts issued by the FI (¶ 0018).
wherein the digital tag is recognized to represent the second user in a first transfer application server associated with the first transfer application whereas the digital tag is generated in a second transfer application server associated with a second transfer application;
Malhotra - The sender of the funds transfer will only need the recipient's unique alias to send funds (¶ 0033). The system 300 may also include an originator PSP 304 in communication with the originator 302. The description of the originator PSP 204 in regard to FIG. 2 may also be applicable to the originator PSP 304 shown in FIG. 3. The originator PSP 304 may also be in communication with a gateway computer 306. The gateway computer 306, in turn, is shown operatively connected between a payment card network 310 and a payment switch/network 308. Although the gateway computer 306 is shown separately from the payment card network 310, it may, in some embodiments, be a component or components associated with or provided by and/or operated by the operator of the payment card network 310 (¶ 0029).
responsive to receiving the transfer request message, generating, by the digital tag computer, a code;
Malhotra - the merchant device 902 has been programmed to generate an optical code to support transaction processing as described herein (¶ 0093).
transmitting, by the digital tag computer, the encrypted payload to the encrypted payload to the second transfer application associated with the second user, wherein the second transfer application provided on a second user device
Malhotra - The gateway computer (digital tag) 306 is also shown connected to an alias directory 314. The purpose and functioning of the alias directory 314 will be described further below. The alias directory may translate a beneficiary/recipient's alias into destination account information (¶ 0032). the alias is translated (e.g., at the alias directory 314, FIG. 3; e.g., at the request of the gateway computer 306 (¶ 0073). ay transmit information to the service provider 320 based on the response received by the gateway computer 306 at 806 (¶ 0091).
is a different application than the first transfer application provided on the first user device, wherein the second transfer application retrieves the code, the digital tag, at least the portion of the credential, and the transaction amount from the encrypted payload using a public key of the digital tag compuer;
Malhotra - The consumer alias registry 108A maintained by the payment switch module 102 may track the senders and receivers of person-to-person transactions who are registered with respect to financial institutions 104. Account information as well as identifying information such as names and phone numbers may be associated with an alias. As of this writing, the alias of a sender or a receiver may comprise a mobile phone number or an e-mail address. However, the system 100 is not limited to these two forms of aliases. Other aliases may be used without departing from the scope of the system 100 as understood by one of ordinary skill in the art (¶ 0063).
receiving, by the digital tag computer, a confirmation message that the second user wants to conduct the transfer transaction and is sharing the code with the first user; and
Malhotra - The merchant may also receive other information such as billing address, shipping address, and loyalty account information in addition to a payment confirmation message (¶0083). At 1008, the customer's smartphone (via the app) prompts the customer to confirm that the customer is approving the transaction and the indicated payment to the merchant's account. Assuming the customer indicates confirmation/approval, then block 1010 follows block 1008 (¶ 0104).
Malhotra does not teach, however, Jabbour discloses:
responsive to receiving the confirmation message, transmitting, by the digital tag computer, the code to the first transfer application on the first user device, wherein first transfer application on the first user device compares the code received from the digital tag computer with the code received from the second user, and initiates the transfer transaction if the code received from the digital tag computer with the code received from the second user match.
Jabbour - The check number and seat number for the user is retrieved from the PoS (812). Such retrieval may be performed periodically at predetermined time intervals, or in response to certain events such as a user requesting to view their bill, the user requesting to settle their bill, etc. A determination is made if the user's tag assigned to the check and seat number in the PoS matches the user tag assigned to the check and seat number in the backend (814). If there is a match (YES at 814), it may be determined that the user has not moved tables/seats, and returns to retrieving the check number and seat number for the user (812) at the next predetermined time or next event (¶ 0111). If the user's tag for the check and seat number in the PoS does not match the user's tag in the backend (NO at 814), the backend retrieves all application tags from PoS associated with each check and for each seat number (816). All application tags are updated in the backend with the most recently retrieved check and seat number (818). The updated check number and seat number associated with the user's application tag is retrieved from the PoS (820). A determination is made if the application tag for the user is found (822). If the application tag for the user is found (YES at 822), the check number and seat number for the user is retrieved from the PoS (812) to confirm that the user's tag assigned to the check and seat number in the PoS matches the user tag assigned to the check and seat number in the backend (814). If the application tag for the user is not found (NO at 822), this suggests that the user has paid with a separate payment and the bill has been closed at the PoS by the establishment staff (824), that the staff has void the items ordered by the user and closed the check (826), or that the staff has deleted the application tag at the PoS system (828) (¶ 0112).
Therefore, it would have been obvious to one of ordinary skill of the art before the effective filing date of the claimed invention to modify the system and method for interfacing with POS systems and customer devices at an establishment of Malhotra with the system and methods to retrieve and match associated information content of Jabbour in order to provide product or identifier bearing item related information to a consumer purchasing goods or services.
The combination of Malhotra and Jabbour does not teach, however Wilson discloses:
generating, by the digital tag computer, an encrypted payload comprising at least the code, the digital tag, at least a portion of the credential, and the transaction amount using a private key of the digital tag computer
Wilson - In order to mitigate the possibility of replay attacks, payment switch module 102 may also establish a one-time use session token, or nonce (¶ 0097). both the payment switch module 102 and the Member FIs 104 may digitally sign message payloads using the sender's private certificate key. This layer of security may use a separate set of certificates from the ones used to establish the SSL connection, as understood by one of ordinary skill in the art (¶ 0095). the amount and destinations for money that is owed to other financial institutions 104 that are members and who are coupled to the payment switch module 102 (¶ 0137).
Regarding Claim 2. The combination of Malhotra, Jabbour, and Wilson further discloses the method of claim 1, wherein the code is formed from a random number.
Wilson - The verification code request comprises requesting the payment switch module 102 to generate a verification code. A verification code typically comprises random alphanumeric characters which may be sent to the customer via e-mail or via a mobile phone number in order to verify that the customer owns the e-mail account or mobile phone number selected for the alias (¶ 0318).
Therefore, it would have been obvious to one of ordinary skill of the art before the effective filing date of the claimed invention to modify the system and method for interfacing with POS systems and customer devices at an establishment of Malhotra with the system and methods to store and retrieve identifier associated information content of Jabbour and the random verification code of Wilson in order to provide product or identifier bearing item related information to a consumer purchasing goods or services and protect that information with a code.
Regarding Claim 3. The combination of Malhotra, Jabbour, and Wilson further discloses the method of claim 1, wherein the code is in a digital certificate when the code is transmitted from the digital tag computer to the second transfer application.
Wilson - All conversations between the Member FIs 104 and payment switch module usually employ encryption. For maximum security, payment switch module 102 and its partners will exchange public certificates through an out-of-band channel such as hand delivery or other secure transport. Using these certificates, payment switch module 102 and the Member FIs 104 may establish mutual SSL connections for all transactions as understood by one of ordinary skill in the art (¶ 0094). Additionally, both the payment switch module 102 and the Member FIs 104 may digitally sign message payloads using the sender's private certificate key. This layer of security may use a separate set of certificates from the ones used to establish the SSL connection, as understood by one of ordinary skill in the art (¶ 0095).
Therefore, it would have been obvious to one of ordinary skill of the art before the effective filing date of the claimed invention to modify the system and method for interfacing with POS systems and customer devices at an establishment of Malhotra with the system and methods to store and retrieve identifier associated information content of Jabbour and the random verification code of Wilson in order to provide product or identifier bearing item related information to a consumer purchasing goods or services and protect that information with a code.
Regarding Claim 4. The combination of Malhotra, Jabbour, and Wilson further discloses the method of claim 1, wherein the code is in a digital certificate when the code is transmitted from the digital tag computer to the second transfer application, and the digital certificate further comprises: a portion of a credential; the digital tag, a device identifier for the second user device, and the transaction amount.
Wilson - All conversations between the Member FIs 104 and payment switch module usually employ encryption. For maximum security, payment switch module 102 and its partners will exchange public certificates through an out-of-band channel such as hand delivery or other secure transport. Using these certificates, payment switch module 102 and the Member FIs 104 may establish mutual SSL connections for all transactions as understood by one of ordinary skill in the art (¶ 0094). Additionally, both the payment switch module 102 and the Member FIs 104 may digitally sign message payloads using the sender's private certificate key. This layer of security may use a separate set of certificates from the ones used to establish the SSL connection, as understood by one of ordinary skill in the art (¶ 0095).
Therefore, it would have been obvious to one of ordinary skill of the art before the effective filing date of the claimed invention to modify the system and method for interfacing with POS systems and customer devices at an establishment of Malhotra with the system and methods to store and retrieve identifier associated information content of Jabbour and the random verification code of Wilson in order to provide product or identifier bearing item related information to a consumer purchasing goods or services and protect that information with a code.
Regarding Claim 5. The combination of Malhotra, Jabbour, and Wilson further discloses the method of claim 1, wherein the code is in a digital certificate when the code is transmitted from the digital tag computer to the second transfer application, and the digital certificate further comprises: the portion of a credential; the digital tag, a device identifier for the second user device, and the transaction amount and a digital signature.
Wilson - Additionally, since the sender must sign the message using the W3C XML Signature WG standard, the SOAP message will include a Signature header using the sender's private key and only decrypt-able with the sender's public key. This usually guarantees that the message originated from the sender (¶ 0096). Once the financial institution 104 receives this account information for the third-party payment service provider 118, the financial institution 104 in block 1109 may launch a login webpage for the third-party payment service provider 118. Next, in block 1111 the third-party payment service provider 118 may display the login website page for the customer to enter his or her account credentials with the third-party financial service provider 118 (¶ 0286). In block 1115, the third-party payment service provider 118 verifies the login credentials from a customer. If the credentials are valid, then in block 1117, the third-party payment service provider 118 may provide options for the customer to select in order to authorize transfers to the payment switch module 102. These options are relayed to the portable computing device 101 via the financial institution 104 (¶ 0288).
Therefore, it would have been obvious to one of ordinary skill of the art before the effective filing date of the claimed invention to modify the system and method for interfacing with POS systems and customer devices at an establishment of Malhotra with the system and methods to store and retrieve identifier associated information content of Jabbour and the random verification code of Wilson in order to provide product or identifier bearing item related information to a consumer purchasing goods or services and protect that information with a code.
Regarding Claim 6. The combination Malhotra, Jabbour, and Wilson further discloses the method of claim 5, wherein the digital signature is formed by signing a hash of a concatenated value comprising at least the portion of a credential; the digital tag, the device identifier for the second user device, and the transaction amount using the private key of the digital tag computer.
Wilson – Additionally, both the payment switch module 102 and the Member FIs 104 may digitally sign message payloads using the sender's private certificate key. This layer of security may use a separate set of certificates from the ones used to establish the SSL connection, as understood by one of ordinary skill in the art (¶ 0095). Additionally, since the sender must sign the message using the W3C XML Signature WG standard, the SOAP message will include a Signature header using the sender's private key and only decrypt-able with the sender's public key. This usually guarantees that the message originated from the sender (¶ 0096). it could be the last four digits of the account number, or some hash value identifier associated with the account (¶ 0109).
Therefore, it would have been obvious to one of ordinary skill of the art before the effective filing date of the claimed invention to modify the system and method for interfacing with POS systems and customer devices at an establishment of Malhotra with the system and methods to store and retrieve identifier associated information content of Jabbour and the random verification code of Wilson in order to provide product or identifier bearing item related information to a consumer purchasing goods or services and protect that information with a code.
Regarding Claim 8. The combination of Malhotra, Jabbour, and Wilson further discloses the method of claim 1, further comprising: determining, by the digital tag computer, if the digital tag is stored in a database at the digital tag computer.
Malhotra - The programs stored in the storage device 404 may include, for example, a transaction handling application program 410. The transaction handling application program 410 may operate to handle transactions such as funds transfers in a manner or manners to be described below (¶ 0047). Another program that may be stored in the storage device 404 is an application program 412 for handling set-up requests received from deposit account holders. The purpose of the set-up requests may be to select aliases to represent deposit accounts held by the requesting individuals. Details of handling of set-up requests will also be described below (¶ 0048).
Regarding Claim 9. The combination of Malhotra, Jabbour, and Wilson further discloses the method of claim 8, further comprising: after determining that the digital tag is stored in the database, retrieving at least the portion of the credential and device identifier from the database.
Malhotra- According to one alternative network flow, a virtual or physical merchant card acceptance terminal initiates a transaction that is transmitted via a merchant system. Prior to transmitting the request, the merchant system may evaluate the payment credentials, and if the same are tokenized, may call a detokenization service provided by a Token Service Provider. Also prior to transmitting the request, the merchant system may determine the originator PSP (O-PSP), and build the transaction request message. The transaction request message is then submitted by the merchant system to the O-PSP. The O-PSP evaluates the transaction request message and authenticates the consumer credentials and debits the originator/consumer account. The flow then proceeds to the payment network (EFT network), which determines the routing path and routes to the beneficiary PSP (B-PSP). The B-PSP evaluates the messages, checks the validity of the beneficiary account, authorizes the transaction request message and posts the transaction (immediately or at a later point in time) against the beneficiary account. The B-PSP returns a response message to the O-PSP via the payment network (EFT network). The O-PSP returns the response to the merchant system/merchant card acceptance terminal (¶ 0079).
Regarding Claim 10. The combination of Malhotra, Jabbour, and Wilson further discloses the method of claim 9, further comprising: transmitting, by the digital tag computer, a digital certificate comprising the at least the portion of the credential, the digital tag, the device identifier for the second user device, and the transaction amount and a digital signature to the second user device.
Wilson - Additionally, since the sender must sign the message using the W3C XML Signature WG standard, the SOAP message will include a Signature header using the sender's private key and only decrypt-able with the sender's public key. This usually guarantees that the message originated from the sender (¶ 0096). Once the financial institution 104 receives this account information for the third-party payment service provider 118, the financial institution 104 in block 1109 may launch a login webpage for the third-party payment service provider 118. Next, in block 1111 the third-party payment service provider 118 may display the login website page for the customer to enter his or her account credentials with the third-party financial service provider 118 (¶ 0286). In block 1115, the third-party payment service provider 118 verifies the login credentials from a customer. If the credentials are valid, then in block 1117, the third-party payment service provider 118 may provide options for the customer to select in order to authorize transfers to the payment switch module 102. These options are relayed to the portable computing device 101 via the financial institution 104 (¶ 0288).
Therefore, it would have been obvious to one of ordinary skill of the art before the effective filing date of the claimed invention to modify the system and method for interfacing with POS systems and customer devices at an establishment of Malhotra with the system and methods to store and retrieve identifier associated information content of Jabbour and the signature of Wilson in order to provide product or identifier bearing item related information to a consumer purchasing goods or services and protect that information with a code.
Regarding Claim 11. The combination of Malhotra, Jabbour, and Wilson discloses the method of claim 10, wherein the device identifier is a phone number.
Malhotra- In such a situation, the user may provide his/her alias to the telco/merchant (again the alias may for example be an email address or a phone number) (¶ 0086).
Regarding Claim 12. The combination of Malhotra, Jabbour, and Wilson further discloses the method of claim 1, wherein the transfer request message is received from the first transfer application via the first transfer application server, and the code is transmitted to the second user device to the second transfer application via a second application server.
Malhotra - The payment account issuer server computer 110 may be operated by or on behalf of a financial institution (“FI”) that issues payment accounts to individual users such as the customer who presented or operated the customer device 102 referred to above. For example, the payment card issuer server computer 110 may perform such functions as (a) receiving and responding to requests for authorization of payment account transactions to be charged to payment accounts issued by the FI; and (b) tracking and storing transactions and maintaining account records (¶ 0018).
Regarding Claim 14. The combination of Malhotra, Jabbour, and Wilson further discloses the method of claim 1, wherein the first user device initiates the transfer transaction if the code received from the digital tag computer with the code received from the second user match, the first user device initiating the transfer transaction by initiating a push transfer message with a transport computer.
Malhotra - The process of FIG. 10 further assumes that the customer has registered for the program. This may involve downloading the mobile app for the program to the customer's smartphone (customer device 906, FIG. 9). Also, the customer may register himself/herself through the app by providing a delegation of user authentication to the app in order to initiate push transactions to credit business or other individual accounts (¶ 0100).
Regarding Claim 15. The combination of Malhotra, Jabbour, and Wilson further discloses the method of claim 14, wherein the push transfer message is an OCT message.
Malhotra - The process of FIG. 10 further assumes that the customer has registered for the program. This may involve downloading the mobile app for the program to the customer's smartphone (customer device 906, FIG. 9). Also, the customer may register himself/herself through the app by providing a delegation of user authentication to the app in order to initiate push transactions to credit business or other individual accounts (¶ 0100).
Regarding Claim 17. Malhotra teaches: A method comprising: entering, into a first transfer application on a first user device, a digital tag associated with a second user and a transaction amount;
Malhotra - receiving a funds transfer request…The request is for requesting a funds transfer (Abstract). The service provider (first user device) 320 may be in communication with the gateway computer (digital tag computer) 306 to allow the service provider 320 to benefit from alias translation services (¶ 0035). including the merchant's bank account details and the transaction amount. The acquirer computer 106 may receive a payment account system authorization request message for the transaction from the merchant device 104 (The acquirer computer 106 may receive a payment account system authorization request message for the transaction from the merchant device 104 (¶ 0016). For example, the payment card issuer server computer 110 may perform such functions as (a) receiving and responding to requests for authorization of payment account transactions to be charged to payment accounts issued by the FI (¶ 0018).
wherein the digital tag is recognized to represent the second user in a first transfer application server associated with the first transfer application whereas the digital tag is generated in a second transfer application server associated with a second transfer application;
Malhotra - The sender of the funds transfer will only need the recipient's unique alias to send funds (¶ 0033). The system 300 may also include an originator PSP 304 in communication with the originator 302. The description of the originator PSP 204 in regard to FIG. 2 may also be applicable to the originator PSP 304 shown in FIG. 3. The originator PSP 304 may also be in communication with a gateway computer 306. The gateway computer 306, in turn, is shown operatively connected between a payment card network 310 and a payment switch/network 308. Although the gateway computer 306 is shown separately from the payment card network 310, it may, in some embodiments, be a component or components associated with or provided by and/or operated by the operator of the payment card network 310 (¶ 0029).
transmitting, by the first transfer application to a digital tag computer, the digital tag associated with the second user and the transaction amount, wherein the digital tag computer generates a code and sends the code to a second transfer application on a second user device associated with the second user;
Malhotra - The gateway computer (digital tag) 306 is also shown connected to an alias directory 314. The purpose and functioning of the alias directory 314 will be described further below. The alias directory may translate a beneficiary/recipient's alias into destination account information (¶ 0032). the alias is translated (e.g., at the alias directory 314, FIG. 3; e.g., at the request of the gateway computer 306 (¶ 0073). ay transmit information to the service provider 320 based on the response received by the gateway computer 306 at 806 (¶ 0091).
receiving, by the first transfer application from the digital tag computer, the code;
Malhotra - The merchant may also receive other information such as billing address, shipping address, and loyalty account information in addition to a payment confirmation message (¶0083). At 1008, the customer's smartphone (via the app) prompts the customer to confirm that the customer is approving the transaction and the indicated payment to the merchant's account. Assuming the customer indicates confirmation/approval, then block 1010 follows block 1008 (¶ 0104).
wherein the second transfer application provided on a second user device is a different application than the first transfer application provided on the first user device, wherein the second transfer application retrieves the code, the digital tag, at least the portion of the credential, and the transaction amount from the encrypted payload using a public key of the digital tag computer;
Malhotra - The gateway computer (digital tag) 306 is also shown connected to an alias directory 314. The purpose and functioning of the alias directory 314 will be described further below. The alias directory may translate a beneficiary/recipient's alias into destination account information (¶ 0032). the alias is translated (e.g., at the alias directory 314, FIG. 3; e.g., at the request of the gateway computer 306 (¶ 0073). ay transmit information to the service provider 320 based on the response received by the gateway computer 306 at 806 (¶ 0091).
receiving, by the first transfer application, the code sent from the second user;
The merchant may also receive other information such as billing address, shipping address, and loyalty account information in addition to a payment confirmation message (¶0083). At 1008, the customer's smartphone (via the app) prompts the customer to confirm that the customer is approving the transaction and the indicated payment to the merchant's account. Assuming the customer indicates confirmation/approval, then block 1010 follows block 1008 (¶ 0104).
Malhotra does not teach, however, Jabbour discloses:
determining that the code received from the digital tag computer and the code received from the second user match; and
Jabbour - The check number and seat number for the user is retrieved from the PoS (812). Such retrieval may be performed periodically at predetermined time intervals, or in response to certain events such as a user requesting to view their bill, the user requesting to settle their bill, etc. A determination is made if the user's tag assigned to the check and seat number in the PoS matches the user tag assigned to the check and seat number in the backend (814). If there is a match (YES at 814), it may be determined that the user has not moved tables/seats, and returns to retrieving the check number and seat number for the user (812) at the next predetermined time or next event (¶ 0111). If the user's tag for the check and seat number in the PoS does not match the user's tag in the backend (NO at 814), the backend retrieves all application tags from PoS associated with each check and for each seat number (816). All application tags are updated in the backend with the most recently retrieved check and seat number (818). The updated check number and seat number associated with the user's application tag is retrieved from the PoS (820). A determination is made if the application tag for the user is found (822). If the application tag for the user is found (YES at 822), the check number and seat number for the user is retrieved from the PoS (812) to confirm that the user's tag assigned to the check and seat number in the PoS matches the user tag assigned to the check and seat number in the backend (814). If the application tag for the user is not found (NO at 822), this suggests that the user has paid with a separate payment and the bill has been closed at the PoS by the establishment staff (824), that the staff has void the items ordered by the user and closed the check (826), or that the staff has deleted the application tag at the PoS system (828) (¶ 0112).
responsive to the match, processing a transfer of the transaction amount to the second transfer application associated with the second user
Jabbour - The check number and seat number for the user is retrieved from the PoS (812). Such retrieval may be performed periodically at predetermined time intervals, or in response to certain events such as a user requesting to view their bill, the user requesting to settle their bill, etc. A determination is made if the user's tag assigned to the check and seat number in the PoS matches the user tag assigned to the check and seat number in the backend (814). If there is a match (YES at 814), it may be determined that the user has not moved tables/seats, and returns to retrieving the check number and seat number for the user (812) at the next predetermined time or next event (¶ 0111). If the user's tag for the check and seat number in the PoS does not match the user's tag in the backend (NO at 814), the backend retrieves all application tags from PoS associated with each check and for each seat number (816). All application tags are updated in the backend with the most recently retrieved check and seat number (818). The updated check number and seat number associated with the user's application tag is retrieved from the PoS (820). A determination is made if the application tag for the user is found (822). If the application tag for the user is found (YES at 822), the check number and seat number for the user is retrieved from the PoS (812) to confirm that the user's tag assigned to the check and seat number in the PoS matches the user tag assigned to the check and seat number in the backend (814). If the application tag for the user is not found (NO at 822), this suggests that the user has paid with a separate payment and the bill has been closed at the PoS by the establishment staff (824), that the staff has void the items ordered by the user and closed the check (826), or that the staff has deleted the application tag at the PoS system (828) (¶ 0112).
Therefore, , it would have been obvious to one of ordinary skill of the art before the effective filing date of the claimed invention to modify the system and method for interfacing with POS systems and customer devices at an establishment of Malhotra with the system and methods to retrieve and match associated information content of Jabbour in order to provide product or identifier bearing item related information to a consumer purchasing goods or services.
The combination of Malhorta and Jabbour does not disclose, however Wilson discloses:
identifies a credential associated with the digital tag, generates a code, generates an encrypted payload comprising at least the code, the digital tag, at least a portion of the credential, and the transaction amount using a private key of the digital tag computer
Wilson - In order to mitigate the possibility of replay attacks, payment switch module 102 may also establish a one-time use session token, or nonce (¶ 0097). both the payment switch module 102 and the Member FIs 104 may digitally sign message payloads using the sender's private certificate key. This layer of security may use a separate set of certificates from the ones used to establish the SSL connection, as understood by one of ordinary skill in the art (¶ 0095). the amount and destinations for money that is owed to other financial institutions 104 that are members and who are coupled to the payment switch module 102 (¶ 0137).
Regarding Claim 18. The combination of Malhotra, Jabbour, and Wilson discloses the method of claim 17, wherein the code is received by the first transfer application from the second user via the second user device associated with the second user, the second user device storing the second transfer application.
Wilson - All conversations between the Member FIs 104 and payment switch module usually employ encryption. For maximum security, payment switch module 102 and its partners will exchange public certificates through an out-of-band channel such as hand delivery or other secure transport. Using these certificates, payment switch module 102 and the Member FIs 104 may establish mutual SSL connections for all transactions as understood by one of ordinary skill in the art (¶ 0094). Additionally, both the payment switch module 102 and the Member FIs 104 may digitally sign message payloads using the sender's private certificate key. This layer of security may use a separate set of certificates from the ones used to establish the SSL connection, as understood by one of ordinary skill in the art (¶ 0095).
Therefore, it would have been obvious to one of ordinary skill of the art before the effective filing date of the claimed invention to modify the system and method for interfacing with POS systems and customer devices at an establishment of Malhotra with the system and methods to store and retrieve identifier associated information content of Jabbour and the signature of Wilson in order to provide product or identifier bearing item related information to a consumer purchasing goods or services and protect that information with a code.
Regarding Claim 19. The combination of Malhotra, Jabbour, and Wilson further discloses the method of claim 17, wherein the code is generated using a random number generated by the digital tag computer.
Wilson - The verification code request comprises requesting the payment switch module 102 to generate a verification code. A verification code typically comprises random alphanumeric characters which may be sent to the customer via e-mail or via a mobile phone number in order to verify that the customer owns the e-mail account or mobile phone number selected for the alias (¶ 0318).
Therefore, it would have been obvious to one of ordinary skill of the art before the effective filing date of the claimed invention to modify the system and method for interfacing with POS systems and customer devices at an establishment of Malhotra with the system and methods to store and retrieve identifier associated information content of Jabbour and the signature of Wilson in order to provide product or identifier bearing item related information to a consumer purchasing goods or services and protect that information with a code.
Regarding Claim 20. The combination of Malhotra, Jabbour, and Wilson further discloses the method of claim 17, wherein the code is derived from two or more of at least a portion of a credential, a device identifier for the second user device, the transaction amount, or a random number.
Wilson - Additionally, since the sender must sign the message using the W3C XML Signature WG standard, the SOAP message will include a Signature header using the sender's private key and only decrypt-able with the sender's public key. This usually guarantees that the message originated from the sender (¶ 0096). Once the financial institution 104 receives this account information for the third-party payment service provider 118, the financial institution 104 in block 1109 may launch a login webpage for the third-party payment service provider 118. Next, in block 1111 the third-party payment service provider 118 may display the login website page for the customer to enter his or her account credentials with the third-party financial service provider 118 (¶ 0286). In block 1115, the third-party payment service provider 118 verifies the login credentials from a customer. If the credentials are valid, then in block 1117, the third-party payment service provider 118 may provide options for the customer to select in order to authorize transfers to the payment switch module 102. These options are relayed to the portable computing device 101 via the financial institution 104 (¶ 0288).
Therefore, it would have been obvious to one of ordinary skill of the art before the effective filing date of the claimed invention to modify the system and method for interfacing with POS systems and customer devices at an establishment of Malhotra with the system and methods to store and retrieve identifier associated information content of Jabbour and the signature of Wilson in order to provide product or identifier bearing item related information to a consumer purchasing goods or services and protect that information with a code.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Lavender et al. (US20200336315A1) - A method for validating an interaction is disclosed. A first interaction cryptogram can be generated by a first device using information about a first party to the interaction and a second party to the interaction. A second interaction cryptogram can be generated by a second device also using information about the first party to the interaction and the second party to the interaction. Verifying each cryptogram can validate that the interaction details have not been changed, and that both the first party and second party legitimately authorized the interaction.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTINA C STEVENSON whose telephone number is (571)270-7280 and whose email address is christina.mention@uspto.gov. The examiner can normally be reached M-F 8am-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, Patrick McAtee can be reached on (571) 272-7575. 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.
/C.C.S./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698