82DETAILED ACTION
This is the office action on the merits in response to Applicant arguments/Remarks filed on 7/1/2025.
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 .
Claims’ Status
Claims 1, 11, and 14 are amended. Claim 25 is a new claim. Claims 6-10, 21 and 22 have been canceled. Claims 1-5, 11-20 and 23-25 are pending and are considered in this action.
Response to Arguments
103 Rejection
Applicant’s argument is moot in light of new arts and new grounds of rejection due to amended claims.
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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-5, 11-20, and 23-24 are rejected under 35 U.S.C 103 as being obvious over Hammad et al. (US20120209749A1; hereinafter: “Hammad2”) in view of Laracey (US20110251892A1) in view of BLOMEYER et al. (US20130013386A1), and further in view of Campos (US20140344149A1).
With respect to claim 1
Hammad2 teaches the limitations of:
Displaying, at a display of a point of sale of a store, a first code for scanning by a mobile device operating a plurality of different mobile applications ([0021], the POS terminal may generate a Quick Response (“QR”) code, e.g., 105 a, including information on the scanned product items, as well as merchant information for processing the purchase transaction via a payment network. The user may capture an image of the QR code generated by the POS terminal using a user device, such as a smartphone. For example, the user device may have executing on it an app for snapping the merchant-product QR code……) wherein the first code includes encoded/encrypted information that is scannable by a first mobile application operating on the mobile device ([0036], In some implementations, the image may be encrypted by the SNAP before providing it to the trusted computing device.)
([0022], In some implementations, the user device may utilize methods alternative to capture of a QR code to obtain information from the POS terminal. For example, the POS terminal may communicate the information required for submitting a purchase transaction request to a payment network to user device via Bluetooth™, Wi-Fi, SMS, text message, electronic mail, and/or other communication methods.)
Hammad2 does not explicitly disclose, but BLOMEYER teaches:
establishing a communication link between the wallet broker and the point of sale (see fig.1 and [0046], Communication between the transaction server and the point of sale occurs by means of a first communications link (18) which may be a wired or wireless link and is preferably an encrypted synchronous communications link.) and establishing another communication link between the wallet broker and a first backend system associated with the first mobile application (fig.1 and [0049], The service provider may also return a confirmation message, such as an SMS or USSD message, to the mobile phone (28) of the customer as indicated by the arrow (30).)
automatically establishing, via the wallet broker, a communication link to the point of sale and to first backend system ([0046], The transaction server operates as a switch in that it is able to synchronously communicate with more than one service provider (20), automatically routing communication from the point of sale (14) to the correct service provider; see fig.1 and [0049], Using the customer identifier, the transaction server then looks up the account number of the customer account on the customer database (24), and communicates the customer account number, retailer identifier and requested value allocation to the correctly identified service provider (20) by means of the second communications link (22)……..The service provider may also return a confirmation message, such as an SMS or USSD message, to the mobile phone (28) of the customer as indicated by the arrow (30).)
Gathering, from the first backend system, customer payment profile information in the wallet broker for use to effect payment via the point of sale ([0012], receiving from a point of sale a request to allocate a specific value to the customer account with the service provider, the customer account being identified either by means of receiving an account number of the customer account from the point of sale, or by means of receiving a customer identifier where the customer identifier has previously been associated with the account number of the customer account by the transaction server;)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Hammad2 with the teaching of BLOMEYER as they relate to payment processing methods. One of ordinary skill in the art before effective filing date of the claimed invention was made would have recognized the use of a payment network to conduct a purchase transaction in Hammad2 to the methods of automatically establishing communication links among the various actors in a network taught in BLOMEYER for the predicated result of an improved and secure payment network system.
Hammad2 in view of BLOMEYER do not explicitly disclose, but Laracey teaches:
Receiving, from the mobile device of a customer, encoded/encrypted information from the first code at a wallet broker, the wallet broker comprising a processor; and a computer readable medium coupled to the processor, the computer readable medium comprising code executable to perform a method ([0055], the checkout token 210 is used by the transaction management system 230 to match a payment request from a mobile device 202 with a payment authorization request from the merchant 208 to complete a payment transaction using information stored at, or accessible to, the transaction management system 230; [0054], The checkout token 210 may be encoded or displayed as a bar code image)
sending, from the wallet broker, an authorization request to an authorizer for the payment; communicating, from the wallet broker to the point of sale, a first authorization status message in a standard message format based on communications with the authorizer to complete a first transaction ([0062], Once the final confirmation to proceed with the payment has been received from the customer's mobile device 202, the transaction management system 230 creates an authorization approval request message for transmission through one or more payment processing network(s) 232 to cause the authorization, clearing and settlement of funds for the transaction……. The authorization approval processing may be performed using standard financial authorization processing over one or more payment processing networks 232 (e.g., such as the VISANET® network operated by Visa, Inc., an Automated Clearing House system such as NACHA, or the like). Once the availability of funds is confirmed, the transaction management system then sends a merchant payment authorization response message to the merchant 208 so the transaction can be completed at the point of sale 212, and a customer payment authorization response message to the customer's mobile device 202.)
receiving at the wallet broker, a request for payment authorization from the point of sale after the point of sale has enforced tender-level rules to determine a payment according to the customer payment profile information, including the one or more membership (see [0049], the customer (26) hands the loyalty card (30) to a cashier who scans the card at the point of sale (14). The cashier asks the customer whether they wish to allocate value to the customer account linked to the loyalty card (e.g. the linked prepaid cell phone account). It is envisaged that more than one customer account may be linked to the loyalty card, in which case the cashier may enquire which account the customer wishes to allocate value to. If the customer wishes to allocate value to a customer account, the point of sale communicates the request to the transaction server. In this embodiment, at a minimum the point of sale only needs to communicate to the transaction server a retailer identifier (not shown) which identifies the retailer (16) to which the point of sale belongs, the customer identifier and the requested value allocation. Using the customer identifier, the transaction server then looks up the account number of the customer account on the customer database (24), and communicates the customer account number, retailer identifier and requested value allocation to the correctly identified service provider (20) by means of the second communications link (22). The service provider then attempts to credit the customer account with the value allocation and uses the retailer identifier to record which retailer must be billed for the allocation of value.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Laracey with the teaching of BLOMEYER/Hammad2 as they relate to payment processing methods. One of ordinary skill in the art before effective filing date of the claimed invention was made would have recognized the combine system of BLOMEYER/Hammad2, for example the use of a payment network to conduct a purchase transaction in Hammad2, to the methods of using authorization message taught in Laracey for the predicated result of an improved and secure payment network system.
Hammad2 in view of BLOMEYER in view of Laracey do not explicitly disclose, but Campos teaches:
pushing, from the wallet broker to the point of sale of the store and via the communication link established in response to receiving the system ([0099], As depicted in FIG. 2B, the E-Wallet Aggregator System 1000 is configured to: (a) form a secure connection with the retailer/merchant and/or vendor (e.g., via the point of sale device 111), the electronic value token transaction computer 150, and the issuers' authorization systems 160;…… (e) communicate to the retailer/merchant and/or vendor (e.g., via the POS unit 111) the redemption or addition of value tokens into electronic wallets and any information concomitant with the redemption or addition of value tokens into electronic wallets and/or sub-wallets; see also [0023], As used herein, a value token refers to an electronic identifier that may be used to transact business with a party willing to accept the electronic value token, for example as tender for a purchase. Examples of such value tokens include electronic representations of, or associated with,.….., membership cards, tickets or ticket cards, entertainment cards, sports cards,…; see also [0093], The electronic value token transaction computer 150, in block 318, then forwards the confirmation message to the point of sale device 111. The electronic value token transaction computer 150, prior to forwarding the confirmation message to the point of sale device 111, may modify the confirmation message, for example as necessary to include information that may be printed on a receipt for the customer and/or presented on a display to the store clerk operating the point of sale device 111..)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Campos with the teaching of BLOMEYER/Hammad2/ Laracey as they relate to payment processing methods. One of ordinary skill in the art before effective filing date of the claimed invention was made would have recognized the combine system of BLOMEYER/Hammad2/Laracey, for example the use of a payment network to conduct a purchase transaction in Hammad2, to the methods of pushing customer information, i.e., membership card, to the POS as taught in Campos for the predicated result of an improved and secure payment network system.
With respect to claim 11
Hammad2 teaches the limitations of:
displaying, at a display of the point of sale of a store, a code for scanning by a mobile application ([0021], the POS terminal may generate a Quick Response (“QR”) code, e.g., 105 a, including information on the scanned product items, as well as merchant information for processing the purchase transaction via a payment network. The user may capture an image of the QR code generated by the POS terminal using a user device, such as a smartphone. For example, the user device may have executing on it an app for snapping the merchant-product QR code……), wherein the code includes encoded/encrypted information that is detectable by the mobile application execute on a mobile device of a customer ([0036], In some implementations, the image may be encrypted by the SNAP before providing it to the trusted computing device.).
point of sale and to a backend system associated with the mobile application to retrieve a customer payment profile in response to receiving the encoded/encrypted information from the code detected by the mobile application ([0022], In some implementations, the user device may utilize methods alternative to capture of a QR code to obtain information from the POS terminal. For example, the POS terminal may communicate the information required for submitting a purchase transaction request to a payment network to user device via Bluetooth™, Wi-Fi, SMS, text message, electronic mail, and/or other communication methods.)
Hammad2 does not explicitly disclose, but Laracey teaches:
Receiving encoded/encrypted information from the code at a wallet broker ([0055], the checkout token 210 is used by the transaction management system 230 to match a payment request from a mobile device 202 with a payment authorization request from the merchant 208 to complete a payment transaction using information stored at, or accessible to, the transaction management system 230; [0054], The checkout token 210 may be encoded or displayed as a bar code image)
communicating, from the wallet broker to the point of sale, a authorization status message in a standard message format based on communications with the authorizer associated with the backend system to complete a transaction ([0062], Once the final confirmation to proceed with the payment has been received from the customer's mobile device 202, the transaction management system 230 creates an authorization approval request message for transmission through one or more payment processing network(s) 232 to cause the authorization, clearing and settlement of funds for the transaction……. The authorization approval processing may be performed using standard financial authorization processing over one or more payment processing networks 232 (e.g., such as the VISANET® network operated by Visa, Inc., an Automated Clearing House system such as NACHA, or the like). Once the availability of funds is confirmed, the transaction management system then sends a merchant payment authorization response message to the merchant 208 so the transaction can be completed at the point of sale 212, and a customer payment authorization response message to the customer's mobile device 202.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Laracey with the teaching of Hammad2 as they relate to payment processing methods. One of ordinary skill in the art before effective filing date of the claimed invention was made would have recognized the use of a payment network to conduct a purchase transaction disclosed by Hammad2, to the methods of using authorization message taught in Laracey for the predicated result of an improved and secure payment network system.
Hammad2 in view of Laracey do not explicitly disclose, but BLOMEYER teaches:
automatically establishing, by the wallet broker, a communication link to the point of sale and to a backend system associated with the mobile application ([0046], The transaction server operates as a switch in that it is able to synchronously communicate with more than one service provider (20), automatically routing communication from the point of sale (14) to the correct service provider; see fig.1 and [0049], Using the customer identifier, the transaction server then looks up the account number of the customer account on the customer database (24), and communicates the customer account number, retailer identifier and requested value allocation to the correctly identified service provider (20) by means of the second communications link (22)……..The service provider may also return a confirmation message, such as an SMS or USSD message, to the mobile phone (28) of the customer as indicated by the arrow (30).)
receiving at the wallet broker, a request for payment authorization from the point of sale after the point of sale has enforced tender-level rules to determine a payment according to the customer payment profile information including one or more membership (see [0049], the customer (26) hands the loyalty card (30) to a cashier who scans the card at the point of sale (14). The cashier asks the customer whether they wish to allocate value to the customer account linked to the loyalty card (e.g. the linked prepaid cell phone account). It is envisaged that more than one customer account may be linked to the loyalty card, in which case the cashier may enquire which account the customer wishes to allocate value to. If the customer wishes to allocate value to a customer account, the point of sale communicates the request to the transaction server. In this embodiment, at a minimum the point of sale only needs to communicate to the transaction server a retailer identifier (not shown) which identifies the retailer (16) to which the point of sale belongs, the customer identifier and the requested value allocation. Using the customer identifier, the transaction server then looks up the account number of the customer account on the customer database (24), and communicates the customer account number, retailer identifier and requested value allocation to the correctly identified service provider (20) by means of the second communications link (22). The service provider then attempts to credit the customer account with the value allocation and uses the retailer identifier to record which retailer must be billed for the allocation of value.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Hammad2/ Laracey with the teaching of BLOMEYER as they relate to payment processing methods. One of ordinary skill in the art before effective filing date of the claimed invention was made would have recognized the combined systems of Hammad2/ Laracey, for example the use of a payment network to conduct a purchase transaction in Hammad2, to the methods of automatically establishing communication links among the various actors in a network taught in BLOMEYER for the predicated result of an improved and secure payment network system.
Hammad2 in view of BLOMEYER in view of Laracey do not explicitly disclose, but Campos teaches:
pushing, from the wallet broker to the point of sale of the store and via the communication link established in response to receiving the encoded/encrypted information from the code, data comprising one or more memberships stored with the customer payment profile retrieved from the backend system ([0099], As depicted in FIG. 2B, the E-Wallet Aggregator System 1000 is configured to: (a) form a secure connection with the retailer/merchant and/or vendor (e.g., via the point of sale device 111), the electronic value token transaction computer 150, and the issuers' authorization systems 160;…… (e) communicate to the retailer/merchant and/or vendor (e.g., via the POS unit 111) the redemption or addition of value tokens into electronic wallets and any information concomitant with the redemption or addition of value tokens into electronic wallets and/or sub-wallets; see also [0023], As used herein, a value token refers to an electronic identifier that may be used to transact business with a party willing to accept the electronic value token, for example as tender for a purchase. Examples of such value tokens include electronic representations of, or associated with,.….., membership cards, tickets or ticket cards, entertainment cards, sports cards,…; see also [0093], The electronic value token transaction computer 150, in block 318, then forwards the confirmation message to the point of sale device 111. The electronic value token transaction computer 150, prior to forwarding the confirmation message to the point of sale device 111, may modify the confirmation message, for example as necessary to include information that may be printed on a receipt for the customer and/or presented on a display to the store clerk operating the point of sale device 111..)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Campos with the teaching of BLOMEYER/Hammad2/ Laracey as they relate to payment processing methods. One of ordinary skill in the art before effective filing date of the claimed invention was made would have recognized the combine system of BLOMEYER/Hammad2/Laracey, for example the use of a payment network to conduct a purchase transaction in Hammad2, to the methods of pushing customer information, i.e., membership card, to the POS as taught in Campos for the predicated result of an improved and secure payment network system.
With respect to claim 14
Hammad2 teaches the claim limitation of:
a point of sale of a store, the point of sale comprising a display, a scanning device, and a wireless transmitter (see fig.1B and fig.1E):
linking to a first transaction performed at the point of sale based on communication between a first mobile application executed on a mobile device of a consumer via one of the display, the scanning device, or the wireless transmitter of the point of sale (see [0022].);
Hammad2 does not explicitly disclose, but BLOMEYER teaches:
Determining, by the wallet broker, a first mobile backend system associated with the first mobile application (fig.1 and [0049], Using the customer identifier, the transaction server then looks up the account number of the customer account on the customer database (24), and communicates the customer account number, retailer identifier and requested value allocation to the correctly identified service provider (20) by means of the second communications link (22)……..The service provider may also return a confirmation message, such as an SMS or USSD message, to the mobile phone (28) of the customer as indicated by the arrow (30).)
automatically establishing a communication link between the wallet broker and the point of sale (see fig.1 & [0046], The transaction server operates as a switch in that it is able to synchronously communicate with more than one service provider (20), automatically routing communication from the point of sale (14) to the correct service provider.), and establishing another communication link, by the wallet broker, to the point of sale and to the first mobile backend system associated with the first mobile application (fig.1 and [0046], The transaction server operates as a switch in that it is able to synchronously communicate with more than one service provider (20), automatically routing communication from the point of sale (14) to the correct service provider.)
communicating with the first mobile backend system and receiving a customer payment profile sent from the first mobile backend system ([0012], receiving from a point of sale a request to allocate a specific value to the customer account with the service provider, the customer account being identified either by means of receiving an account number of the customer account from the point of sale, or by means of receiving a customer identifier where the customer identifier has previously been associated with the account number of the customer account by the transaction server;)
receiving at the wallet broker, a request for payment authorization from the point of sale after the point of sale has enforced tender-level rules to determine a payment according to the customer payment profile information including the one or more membership (see [0049], the customer (26) hands the loyalty card (30) to a cashier who scans the card at the point of sale (14). The cashier asks the customer whether they wish to allocate value to the customer account linked to the loyalty card (e.g. the linked prepaid cell phone account). It is envisaged that more than one customer account may be linked to the loyalty card, in which case the cashier may enquire which account the customer wishes to allocate value to. If the customer wishes to allocate value to a customer account, the point of sale communicates the request to the transaction server. In this embodiment, at a minimum the point of sale only needs to communicate to the transaction server a retailer identifier (not shown) which identifies the retailer (16) to which the point of sale belongs, the customer identifier and the requested value allocation. Using the customer identifier, the transaction server then looks up the account number of the customer account on the customer database (24), and communicates the customer account number, retailer identifier and requested value allocation to the correctly identified service provider (20) by means of the second communications link (22). The service provider then attempts to credit the customer account with the value allocation and uses the retailer identifier to record which retailer must be billed for the allocation of value.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Hammad2 with the teaching of BLOMEYER as they relate to payment processing methods. One of ordinary skill in the art before effective filing date of the claimed invention was made would have recognized the use of a payment network to conduct a purchase transaction disclosed by Hammad2, to the methods of automatically establishing communication links among the various actors in a network taught in BLOMEYER for the predicated result of an improved and secure payment network system.
Hammad2 in view of BLOMEYER do not explicitly disclose, but Laracey teaches:
a wallet broker comprising a processor; and a computer readable medium coupled to the processor, the computer readable medium comprising code executable to perform a method ([0055], the checkout token 210 is used by the transaction management system 230 to match a payment request from a mobile device 202 with a payment authorization request from the merchant 208 to complete a payment transaction using information stored at, or accessible to, the transaction management system 230; [0054], The checkout token 210 may be encoded or displayed as a bar code image)
sending a first authorization request message for the payment to an authorizer associated with the first mobile backend system for authorization in response to receiving a request for payment authorization from the point of sale; sending a first message in a standard message format to the point of sale reporting the state of the first authorization request ([0062], Once the final confirmation to proceed with the payment has been received from the customer's mobile device 202, the transaction management system 230 creates an authorization approval request message for transmission through one or more payment processing network(s) 232 to cause the authorization, clearing and settlement of funds for the transaction……. The authorization approval processing may be performed using standard financial authorization processing over one or more payment processing networks 232 (e.g., such as the VISANET® network operated by Visa, Inc., an Automated Clearing House system such as NACHA, or the like). Once the availability of funds is confirmed, the transaction management system then sends a merchant payment authorization response message to the merchant 208 so the transaction can be completed at the point of sale 212, and a customer payment authorization response message to the customer's mobile device 202.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Laracey with the teaching of BLOMEYER/Hammad2 as they relate to payment processing methods. One of ordinary skill in the art before effective filing date of the claimed invention was made would have recognized the combined system of BLOMEYER/Hammad2, for example, the use of a payment network to conduct a purchase transaction in Hammad2, to the methods of using authorization message taught in Laracey for the predicated result of an improved and secure payment network system.
Hammad2 in view of BLOMEYER in view of Laracey do not explicitly disclose, but Campos teaches:
pushing, from the wallet broker to the point of sale of the store and via the communication link established in response data comprising one or more membership information stored with the customer payment profile and received from the first backend system to the point of sale of the store to allow the point of sale to enforce tender-level rules ([0099], As depicted in FIG. 2B, the E-Wallet Aggregator System 1000 is configured to: (a) form a secure connection with the retailer/merchant and/or vendor (e.g., via the point of sale device 111), the electronic value token transaction computer 150, and the issuers' authorization systems 160;…… (e) communicate to the retailer/merchant and/or vendor (e.g., via the POS unit 111) the redemption or addition of value tokens into electronic wallets and any information concomitant with the redemption or addition of value tokens into electronic wallets and/or sub-wallets; see also [0023], As used herein, a value token refers to an electronic identifier that may be used to transact business with a party willing to accept the electronic value token, for example as tender for a purchase. Examples of such value tokens include electronic representations of, or associated with,.….., membership cards, tickets or ticket cards, entertainment cards, sports cards,…; see also [0093], The electronic value token transaction computer 150, in block 318, then forwards the confirmation message to the point of sale device 111. The electronic value token transaction computer 150, prior to forwarding the confirmation message to the point of sale device 111, may modify the confirmation message, for example as necessary to include information that may be printed on a receipt for the customer and/or presented on a display to the store clerk operating the point of sale device 111.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Campos with the teaching of BLOMEYER/Hammad2/ Laracey as they relate to payment processing methods. One of ordinary skill in the art before effective filing date of the claimed invention was made would have recognized the combine system of BLOMEYER/Hammad2/Laracey, for example the use of a payment network to conduct a purchase transaction in Hammad2, to the methods of pushing customer information, i.e., membership card, to the POS as taught in Campos for the predicated result of an improved and secure payment network system.
With respect to claim 2 and 12
The combination of Hammad2, BLOMEYER, Laracey, and Campos teaches the limitations of claim 1 and 11 respectively. Hammad2 further teaches: sending encoded/encrypted information from the first code to a wallet broker comprises sending from one of the first mobile application or the first mobile application through the first backend system ([0034], The virtual wallet app on the user's mobile device (or the client) may then generate a purchase transaction initiation message and provide it to the pay network server for processing the purchase transaction. Upon completion of transaction processing, the pay network server may provide a notification of payment completion to the client, e.g., FIG. 1F, 197, or to the user device.)
With respect to claim 3, 8, and 13
The combination of Hammad2, BLOMEYER, Laracey, and Campos teaches the limitations of claim 2, 7 and 12 respectively. Hammad2 further teaches: gathering customer payment profile comprises accessing the first backend system with the wallet broker in order to gather the customer payment profile ([0045] & fig. 3E, the SNAP may provide a web interface, e.g., 341. For example, the user may be able to modify security settings of the user's virtual wallet, e.g., 342, using the web interface. For example, the user may review a list of trusted device, e.g., 344, via which the user may access the user's virtual wallet; see [0044]))
With respect to claim 4 and 9
The combination of Hammad2, BLOMEYER, Laracey, and Campos teaches the limitations of claim 1 and 6 respectively. Hammad2 further teaches: sending customer payment profile information to a wallet broker ([0045] & fig. 3E, the SNAP may provide a web interface, e.g., 341. For example, the user may be able to modify security settings of the user's virtual wallet, e.g., 342, using the web interface. For example, the user may review a list of trusted device, e.g., 344, via which the user may access the user's virtual wallet.)
With respect to claim 5
The combination of Hammad2, BLOMEYER, Laracey, and Campos teaches the limitations of claim 1. Hammad2 further teaches: gathering customer payment profile information includes gathering customer payment profile information from the backend system through the wallet broker ([0045] & fig. 3E, the SNAP may provide a web interface, e.g., 341. For example, the user may be able to modify security settings of the user's virtual wallet, e.g., 342, using the web interface. For example, the user may review a list of trusted device, e.g., 344, via which the user may access the user's virtual wallet; see [0044]))
With respect to claim 15
The combination of Hammad2, BLOMEYER, Laracey, and Campos teaches the limitations of claim 14. Hammad2 further teaches: the wallet broker is linked to the first transaction in response to the mobile device operating the first mobile application scanning a code generated by the point of sale, wherein the code includes encoded/encrypted information ([0048], the merchant server may generate, e.g., 416 a, a QR pay code, and/or secure display element according to the security settings of the user (see, e.g., 358). The merchant server may provide the QR code to the client, so that the client may display the QR code, and the user may capture the QR code using the user's device to obtain merchant and/or product data for generating a purchase transaction processing request.)
With respect to claim 16
The combination of Hammad2, BLOMEYER, Laracey, and Campos teaches the limitations of claim 14. Hammad2 further teaches: the wallet broker is linked to the first transaction in response to the point of sale scanning a code generated by the first mobile application operating on the mobile device, wherein the code includes encoded/encrypted information ([0060], the user device may generate a QR payment code embedding the PAN and dCVV numbers, and the point of sale terminal may snap an image of the user device-generated QR payment code. The point of sale terminal may then generate and provide the card authorization request to the pay network server.)
With respect to claim 17
The combination of Hammad2, BLOMEYER, Laracey, and Campos teaches the limitations of claim 14. Hammad2 further teaches: the wallet broker is linked to the first transaction in response to the point of sale emitting a wireless signal containing encoded/encrypted information through a wireless transmitter, wherein wireless signal is detectable by the first mobile application operating on the mobile device ([0048], the merchant server may generate, e.g., 416 a, a QR pay code, and/or secure display element according to the security settings of the user (see, e.g., 358). The merchant server may provide the QR code to the client, so that the client may display the QR code, and the user may capture the QR code using the user's device to obtain merchant and/or product data for generating a purchase transaction processing request; [0105], the mode tab 1940 may facilitate selection of a payment mode accepted by the payee. A number of payment modes may be available for selection. Example modes include, blue tooth 941, wireless 942, snap mobile by user-obtained QR code 943, secure chip 944, TWITTER 945, near-field communication (NFC) 946, cellular 947, snap mobile by user-provided QR code 948, USB 949 and FACEBOOK 950, among others.)
With respect to claim 18
The combination of Hammad2, BLOMEYER, Laracey, and Campos teaches the limitations of claim 14. Hammad2 further teaches: the point of sale communicates with the wallet broker to notify the wallet broker that the sale is complete, wherein the link of the wallet broker to the transaction is closed ([0042], the SNAP may generate, e.g., in real-time, a one-time anonymous set of card details to securely complete the purchase transaction.)
With respect to claim 19
The combination of Hammad2, BLOMEYER, Laracey, and Campos teaches the limitations of claim 18. Hammad2 further teaches: the mobile application or mobile backend is notified of a completed transaction from the wallet broker in response to the wallet broker receiving a notification that the sale is complete ([0042], the SNAP may generate, e.g., in real-time, a one-time anonymous set of card details to securely complete the purchase transaction; [0118], upon completion of the transaction, a receipt may be automatically generated for proof of purchase. The user interface may also be updated to provide other options for handling a completed transaction.)
With respect to claim 20
The combination of Hammad2, BLOMEYER, Laracey, and Campos teaches the limitations of claim 14. Hammad2 further teaches: the customer payment profile includes one or more of customer profile/preferences, discount cards, membership cards, basket information, electronic receipts, and coupons/offers ([0031], the QR code may also include payment information (e.g., the user's pay account information, or the doctor's acquirer information) along with the information on controlled release of personal information; [0084], the QR code could include an invoice/bill, a coupon, a money order (e.g., in a P2P transfer), a new account information packet, product information, purchase commands, URL navigation instructions, browser automation scripts, combinations thereof, and/or the like.)
With respect to claim 23
The combination of Hammad2, BLOMEYER, Laracey, and Campos teaches the limitations of claim 14. Laracey further teaches: the point of sale communicates with the wallet broker requesting a payment authorization after the point of sale has enforced tender-level rules ([0092] & fig.2, if the mobile payment option is selected, processing continues at 408 where the merchant system 209 create and transmit a merchant payment authorization request, including a merchant checkout token.)
With respect to claim 24
The combination of Hammad2, BLOMEYER, Laracey, and Campos teaches the limitations of claim 23. Laracey further teaches: the wallet broker creates appropriate authorization message(s) and send one or more authorizations to either the appropriate authorizer, if payment credentials are available, or to the mobile application backend system, which will augment the authorization request and send to the appropriate authorizer ([0030] & fig.1, if the mobile payment option is selected, and once the purchase total has been generated, the merchant 108 transmits a merchant payment authorization request message to a transaction management system 130 (via path 116). The merchant payment authorization request message may include one or more pieces of data or information about the transaction. For example, the message may include one or more of a merchant identifier, the amount due, and a unique checkout token (“checkout token”) which, as will be described further herein, is used to identify the merchant and the transaction for further processing.)
Claim 25 is rejected under 35 U.S.C 103 as being obvious over Hammad et al. (US20120209749A1; hereinafter: “Hammad2”) in view of Laracey (US20110251892A1) in view of BLOMEYER et al. (US20130013386A1) in view of Campos (US20140344149A1), and further in view of White (US20130138516A1).
With respect to claim 25
The combination of Hammad2, BLOMEYER, Laracey, and Campos teaches the limitations of claim 1. Laracey further teaches: receiving, from the point of sale system and after a first authorization status message, a request for additional tender information to authorize multiple tenders from the wallet for payment (see [0059-0061].)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Campos with the teaching of BLOMEYER/Hammad2/ Laracey/Campos as they relate to payment processing methods. One of ordinary skill in the art before effective filing date of the claimed invention was made would have recognized the combine system of BLOMEYER/Hammad2/Laracey/Campos, for example the use of a payment network to conduct a purchase transaction in Hammad2, to the methods of requesting additional tender information as taught in White for the predicated result of an improved and secure payment network system.
Conclusion
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YIN Y CHOI whose telephone number is (571)272-1094 or yin.choi@uspto.gov. The examiner can normally be reached on M-F 7:30 - 5:30pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Neha Patel can be reached on 571-270-1492. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/YIN Y CHOI/Examiner, Art Unit 3699 9/6/2025
/NEHA PATEL/ Supervisory Patent Examiner, Art Unit 3699