DETAILED ACTION
The present application is being examined under the first inventor to file provisions of the AIA . In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
This Office Action is in response Applicant communication filed on 8/5/2026.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 8/5/2026 has been entered.
Claims
Claims 1, 4, and 19 have been amended.
Claim 18 has been cancelled.
Claims 1-17, 19, and 20 are currently pending in the application.
Information Disclosure Statements
The Information Disclosure Statement (IDS) that was filed on 8/7/2026 has been considered.
Response to Arguments
103
The applicant argues that The combination of Chatterjee/Hariramani/Royyuru fails to disclose the amendments of claims 1, 4, and 19. Specifically the applicant argues that Chatterjee/Hariramani/Royyuru fail to disclose "determining that a user account exists with a payment service system and that the first transaction dataset is not linked to the user account, wherein the application is provided by the payment service system," "based on the determination, linking, by the application, the first transaction dataset to the user account," "adding, to the application, access to the first transaction dataset ... wherein the first transaction dataset and the second transaction dataset are linked to the user account," and "…wherein the transaction dataset is one of a plurality of transaction datasets that the application has access to via the user account and that is to be used in a transaction between a merchant and a user of the user device, and wherein the plurality of transaction datasets includes transaction datasets linked to the user account," (See applicant’s arguments pages 9-11).
However the examiner respectfully disagrees and believes Hariramani discloses the amended limitations. Hariramani in sections [0131]-[0133] discloses that a user can capture an image of a card to start a new card request. It is then verified whether the user has an account and the user’s account information is matched with a digital wallet profile. Once the user’s information has been verified, the pay network server may generate a card information data record which is then made available to the user for future payment transactions. Further Hariramani discloses in sections [0149] and [0150] that a new card alert can be displayed on the user interface of the digital wallet when an image of a card has been detected as is not already included in the digital wallet. The user can then add the card to their digital wallet for future use. Furthermore Hariramani discloses in sections [0228], [0391], and [0404] that a universal payment platform can be provided to the user and the user can associate one or more payment accounts with the universal payment platform to use when performing payments with an electronic wallet. A user’s account can be linked to one or more issuer financial institutions (“issuers”), such as banking institutions, which issued the accounts for the user. These accounts can include credit cards, debit cards prepaid cards, checking, savings, money market, etc.. Therefore Hariramani discloses "determining that a user account exists with a payment service system and that the first transaction dataset is not linked to the user account, wherein the application is provided by the payment service system," "based on the determination, linking, by the application, the first transaction dataset to the user account," "adding, to the application, access to the first transaction dataset ... wherein the first transaction dataset and the second transaction dataset are linked to the user account," and "…wherein the transaction dataset is one of a plurality of transaction datasets that the application has access to via the user account and that is to be used in a transaction between a merchant and a user of the user device, and wherein the plurality of transaction datasets includes transaction datasets linked to the user account,".
The examiner has considered all of the applicant’s arguments but maintains the 103 rejection in view of Chatterjee/Hariramani/Royyuru.
Rejections under 35 § U.S.C. 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-13, 15-17, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US 20120310826 A1 (“Chatterjee”) and US 20130024371 A1 (“Hariramani”) and US 20130097034 A1 (“Royyuru”).
Per claim 1, Chatterjee discloses:
receiving, at a user device, information associated with a first card by scanning the first card using a camera of the user device (e.g. A user, in one implementation, may snap a picture of the code. The wallet application may identify the pay card 1051 and may display the textual information 1052 encoded in the pay card. The user may then perform verification of the information 1052 by selecting the verify button 1053. In one implementation, the verification may include contacting the issuer of the pay card for confirmation of the decoded information 1052 and any other relevant information. In one implementation, the user may add the pay card to the wallet by selecting the `add to wallet` button 1054. The instruction to add the pay card to the wallet may cause the pay card to appear as one of the forms of payment under the funds tab 816 discussed in FIG. 8A.) (Section [0106]);
adding, to a user interface of the application, a first representation of the first card, wherein the user interface of the application includes a second representation of a second card (e.g. A user, in one implementation, may snap a picture of the code. The wallet application may identify the pay card 1051 and may display the textual information 1052 encoded in the pay card. The user may then perform verification of the information 1052 by selecting the verify button 1053. In one implementation, the verification may include contacting the issuer of the pay card for confirmation of the decoded information 1052 and any other relevant information. In one implementation, the user may add the pay card to the wallet by selecting the `add to wallet` button 1054. The instruction to add the pay card to the wallet may cause the pay card to appear as one of the forms of payment under the funds tab 816 discussed in FIG. 8A.) (Section [0035], [0036], [0106], and Fig. 1B);
adding, to the application, access to the first transaction dataset associated with use of the first card, wherein the application has access to second transaction dataset associated with use of the second card… (e.g. In one implementation, the user may add the pay card to the wallet by selecting the `add to wallet` button 1054. The instruction to add the pay card to the wallet may cause the pay card to appear as one of the forms of payment under the funds tab 816 discussed in FIG. 8A) (Section [0035], [0036], and [0106]);
receiving, through the user interface of the application, an input indicating a selection of a representation of a plurality of representations, wherein the plurality of representations includes the first representation of the first card and the second representation of the second card (e.g. In some implementations, upon obtaining the message, the device may provide the user with an interface to make a selection of a card from the user's virtual wallet to utilize to complete the purchase transaction. For example, the user's device may be executing an application module ("app"), via which the user's device may communicate with the pay network. The user's device may display the virtual wallet card selection options obtained from the pay network via the app to the user) (Sections [0035] and [0036]);
receiving, through the application, confirmation of completion of the transaction using the transaction dataset corresponding to the representation of the plurality of representations (e.g. In some implementations, the pay network (e.g., 113) may initiate the card-based purchase transaction, e.g., 114, and may generate a purchase confirmation receipt for the user. The VWCS server may provide the purchase confirmation receipt to the client device, e.g., 116a-b. In some implementations, the user may desire to exit the store after purchasing items via the app. In such implementations, the user may be required to provide proof of purchase of the product at the exit of the store, e.g., 115. The user may utilize the purchase confirmation receipt obtained from the VWCS via the app on the client device to provide such proof of product purchase, e.g., 116a) (Section [0038] and [0039]).
Although Chatterjee discloses receiving card information, adding the card information to a wallet application and using a representation of the card that can be selected for a payment transaction, Chatterjee does not specifically disclose
parsing the information by an application stored on the device to identify a first transaction dataset associated with use of the first card;
determining that a user account exists with a payment service system and that the first transaction dataset is not linked to the user account, wherein the application is provided by the payment service system;
based on the determination, linking, by the application, the first transaction dataset to the user account;
…wherein the first transaction dataset and the second transaction dataset are linked to the user account;
displaying, through the user interface of the application, optically encoded information including a transaction dataset corresponding to the representation of the plurality of representations, wherein the transaction dataset is one of a plurality of transaction datasets that the application has access to via the user account and that is to be used in a transaction between a merchant and a user of the user device, and wherein the plurality of transaction datasets includes transaction datasets linked to the user account.
However Hariramani, in analogous art of electronic wallets, discloses:
parsing the information by an application stored on the device to identify a first transaction dataset associated with use of the first card (e.g. automatically parsing the merchant-specific customer information shown on the customer card and adding the information to a secure virtual wallet profile for the customer stored in a payment network database) (Section [0698] and [0699]).
determining that a user account exists with a payment service system and that the first transaction dataset is not linked to the user account, wherein the application is provided by the payment service system (e.g. Once pay server 704 has received the data associated with new card request 710, pay server 704 verifies the user information, and processes the new card request, e.g., 711. Processing the new card request may include, among other things, verifying that the user has an account with the owner of the pay network, determining whether the card issuer is a participant in a loyalty program, determining whether an incentive applies, and matching the user's account information with a digital wallet profile) and (e.g. Screen 1004 shows a new card alert, and gives the user the option of adding the card's information to the information already included in the digital wallet. This alert will automatically appear after a user-captured image of the card has been transmitted to and processed by the payment network server) (Section [0107], [0130]-[0133], [0149], and [0150]);
based on the determination, linking, by the application, the first transaction dataset to the user account (e.g. Once pay server 704 has received the data associated with new card request 710, pay server 704 verifies the user information, and processes the new card request, e.g., 711. Processing the new card request may include, among other things, verifying that the user has an account with the owner of the pay network, determining whether the card issuer is a participant in a loyalty program, determining whether an incentive applies, and matching the user's account information with a digital wallet profile. Once the user's information has been verified, the pay network server may generate a card information data record) and (e.g. once the card information has been processed and stored in pay network database, the card information may then be made available to a user when making a purchase, either online or at the physical location of a merchant) and (e.g. In some embodiments, the pay network server may generate a query, e.g., 6724, for issuer server(s) corresponding to the user-selected payment options. For example, the user's account may be linked to one or more issuer financial institutions ("issuers"), such as banking institutions, which issued the account(s) for the user. For example, such accounts may include, but not be limited to: credit card, debit card, prepaid card, checking, savings, money market, certificates of deposit, stored (cash) value accounts and/or the like) (Section [0107], [0130]-[0133], [0149], [0150] and [0391]);
…wherein the first transaction dataset and the second transaction dataset are linked to the user account (e.g. In some embodiments, the pay network server may generate a query, e.g., 6724, for issuer server(s) corresponding to the user-selected payment options. For example, the user's account may be linked to one or more issuer financial institutions ("issuers"), such as banking institutions, which issued the account(s) for the user. For example, such accounts may include, but not be limited to: credit card, debit card, prepaid card, checking, savings, money market, certificates of deposit, stored (cash) value accounts and/or the like) (Section [0228] and [0391]);
…wherein the transaction dataset is one of a plurality of transaction datasets that the application has access to via the user account and that is to be used in a transaction between a merchant and a user of the user device, and wherein the plurality of transaction datasets includes transaction datasets linked to the user account (e.g. FIGS. 4A-4B show screen shot diagrams illustrating example user interface(s) of a EOOR card selector component. In some embodiments, the user may access the wallet account screen 401 to modify the card selector preference of each card or multiple cards. All of the payment cards stored in the wallet may be made available for the user 403) and (e.g. In some embodiments, the pay network server may generate a query, e.g., 6724, for issuer server(s) corresponding to the user-selected payment options. For example, the user's account may be linked to one or more issuer financial institutions ("issuers"), such as banking institutions, which issued the account(s) for the user. For example, such accounts may include, but not be limited to: credit card, debit card, prepaid card, checking, savings, money market, certificates of deposit, stored (cash) value accounts and/or the like) (Section [0110], [0228] and [0391]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the payment card data addition process of Chatterjee to include the use of parsing the card dataset, determining a user account exists, and determining the card is not already part of the account before linking the card to the account, as taught by Hariramani, in order to achieve the predictable result of memory efficiency by allowing the wallet to only store the relevant card data needed to perform a transaction and providing convenience to the user by allowing them to easily add cards to their account that have not yet been linked.
Although Chatterjee/Hariramani discloses linking multiple payment cards to a mobile wallet application service profile and selecting a payment card in the electronic wallet to perform a payment transaction with a merchant, Chatterjee/Hariramani does not specifically disclose
displaying, through the user interface of the application, optically encoded information including a transaction dataset corresponding to the representation of the plurality of representations….
However Royyuru, in analogous art of electronic wallets, discloses:
displaying, through the user interface of the application, optically encoded information including a transaction dataset corresponding to the representation of the plurality of representations… (e.g. Additionally, the wallet application 147 may generate and direct the output of a wide variety of different payment options for presentation to the user. In this regard, user input associated with a type of desired payment transaction and/or a desired payment account may be received and processed by the wallet application 147. For example, user input requesting a barcode (or other image-based transaction) may be received at block 320) and (e.g. At block 325, the wallet application 147 may access at least a portion of the stored payment information from the secure element(s). The wallet application 147 may then utilize the accessed information to generate one or more barcode, QR code, or other images for display by the mobile device. For example, accessed payment information may be incorporated into one or more generated images. As another example, accessed VAS-related information (e.g., coupon data, etc.) may be incorporated into one or more generated images. The generated images (e.g., a generated barcode or QR code with payment information) may then be output for display at block 335) (Section [0698] and [0699]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the selected card mobile wallet payment transaction of Chatterjee to include the use of optical codes that represent the cards to perform the transaction, as taught by Chatterjee/Hariramani, in order to achieve the predictable result of providing convenience to the user by allowing them to perform a contactless transaction even if the merchant does not have a contactless reader (see Royyuru section [0003] and [0004]).
Per claim 2, Chatterjee/Hariramani/Royyuru discloses all the limitations of claim 1 above. Chatterjee further discloses:
wherein the first card is one of a gift card, a credit card, or a debit card (e.g. In such implementations, the VWCS server may initiate a card-based purchase transaction using a "card" (e.g., checking account, savings account, Paypal.TM. account, Google Checkout.TM. account, credit card, debit card, prepaid card, etc.) selected from the user's virtual wallet) (Section [0038]).
Per claim 3, Chatterjee/Hariramani/Royyuru discloses all the limitations of claim 1 above. Chatterjee further discloses:
wherein the first representation of the first card includes a first image associated with the first card, and wherein the second representation of the second card includes a second image associated with the second car (e.g. requesting the user to select a payment option from the user's virtual wallet. Based on the message, a user interface rendered by the user's device may be populated with user card selection options, see 110) (Section [0035], [0036], and Fig. 1B).
Per claims 4 and 19, Chatterjee discloses:
receiving, at a user device, a first transaction dataset associated with use of a first transaction medium by scanning the first transaction medium using a camera of the user device (e.g. A user, in one implementation, may snap a picture of the code. The wallet application may identify the pay card 1051 and may display the textual information 1052 encoded in the pay card. The user may then perform verification of the information 1052 by selecting the verify button 1053. In one implementation, the verification may include contacting the issuer of the pay card for confirmation of the decoded information 1052 and any other relevant information. In one implementation, the user may add the pay card to the wallet by selecting the `add to wallet` button 1054. The instruction to add the pay card to the wallet may cause the pay card to appear as one of the forms of payment under the funds tab 816 discussed in FIG. 8A.) (Section [0106]);
adding, to a user interface of the application, a first representation of the first transaction medium, wherein the user interface of the application includes a second representation of a second transaction medium (e.g. A user, in one implementation, may snap a picture of the code. The wallet application may identify the pay card 1051 and may display the textual information 1052 encoded in the pay card. The user may then perform verification of the information 1052 by selecting the verify button 1053. In one implementation, the verification may include contacting the issuer of the pay card for confirmation of the decoded information 1052 and any other relevant information. In one implementation, the user may add the pay card to the wallet by selecting the `add to wallet` button 1054. The instruction to add the pay card to the wallet may cause the pay card to appear as one of the forms of payment under the funds tab 816 discussed in FIG. 8A.) (Section [0035], [0036], [0106], and Fig. 1B);
adding, to the application, access to the first transaction dataset associated with use of the first transaction medium, wherein the application has access to second transaction dataset associated with use of the second transaction medium… (e.g. In one implementation, the user may add the pay card to the wallet by selecting the `add to wallet` button 1054. The instruction to add the pay card to the wallet may cause the pay card to appear as one of the forms of payment under the funds tab 816 discussed in FIG. 8A) (Section [0035], [0036], and [0106]);
receiving, through the user interface of the application, an input indicating a selection of a representation of a plurality of representations, wherein the plurality of representations includes the first representation of the first transaction medium and the second representation of the second transaction medium (e.g. In some implementations, upon obtaining the message, the device may provide the user with an interface to make a selection of a card from the user's virtual wallet to utilize to complete the purchase transaction. For example, the user's device may be executing an application module ("app"), via which the user's device may communicate with the pay network. The user's device may display the virtual wallet card selection options obtained from the pay network via the app to the user) (Sections [0035] and [0036]);
receiving, through the application, confirmation of completion of the transaction using the transaction dataset corresponding to the representation of the plurality of representations (e.g. In some implementations, the pay network (e.g., 113) may initiate the card-based purchase transaction, e.g., 114, and may generate a purchase confirmation receipt for the user. The VWCS server may provide the purchase confirmation receipt to the client device, e.g., 116a-b. In some implementations, the user may desire to exit the store after purchasing items via the app. In such implementations, the user may be required to provide proof of purchase of the product at the exit of the store, e.g., 115. The user may utilize the purchase confirmation receipt obtained from the VWCS via the app on the client device to provide such proof of product purchase, e.g., 116a) (Section [0038] and [0039]).
Chatterjee further discloses at least one memory storing instructions (e.g. a memory) (Section [0156] and [0157]); at least one processor (e.g. CPUs and/or processors) (Section [0156] and [0157]).
Although Chatterjee discloses receiving transaction medium information, adding the transaction medium information to a wallet application and using the transaction medium that can be selected for a payment transaction, Chatterjee does not specifically disclose
determining that a user account exists with a payment service system and that the first transaction dataset is not linked to the user;
based on the determination, linking, by an application on the user device, the first transaction dataset to the user account, wherein the application is provided by the payment service system;
…wherein the first transaction dataset and the second transaction dataset are linked to the user account;
displaying, through the user interface of the application, optically encoded information including a transaction dataset corresponding to the representation of the plurality of representations, wherein the transaction dataset is one of a plurality of transaction datasets that the application has access to via the user account and that is to be used in a transaction between a merchant and a user of the user device, and wherein the plurality of transaction datasets includes transaction datasets linked to the user account.
However Hariramani, in analogous art of electronic wallets, discloses:
determining that a user account exists with a payment service system and that the first transaction dataset is not linked to the user (e.g. Once pay server 704 has received the data associated with new card request 710, pay server 704 verifies the user information, and processes the new card request, e.g., 711. Processing the new card request may include, among other things, verifying that the user has an account with the owner of the pay network, determining whether the card issuer is a participant in a loyalty program, determining whether an incentive applies, and matching the user's account information with a digital wallet profile) and (e.g. Screen 1004 shows a new card alert, and gives the user the option of adding the card's information to the information already included in the digital wallet. This alert will automatically appear after a user-captured image of the card has been transmitted to and processed by the payment network server) (Section [0107], [0130]-[0133], [0149], and [0150]);
based on the determination, linking, by an application on the user device, the first transaction dataset to the user account, wherein the application is provided by the payment service system (e.g. Once pay server 704 has received the data associated with new card request 710, pay server 704 verifies the user information, and processes the new card request, e.g., 711. Processing the new card request may include, among other things, verifying that the user has an account with the owner of the pay network, determining whether the card issuer is a participant in a loyalty program, determining whether an incentive applies, and matching the user's account information with a digital wallet profile. Once the user's information has been verified, the pay network server may generate a card information data record) and (e.g. once the card information has been processed and stored in pay network database, the card information may then be made available to a user when making a purchase, either online or at the physical location of a merchant) and (e.g. In some embodiments, the pay network server may generate a query, e.g., 6724, for issuer server(s) corresponding to the user-selected payment options. For example, the user's account may be linked to one or more issuer financial institutions ("issuers"), such as banking institutions, which issued the account(s) for the user. For example, such accounts may include, but not be limited to: credit card, debit card, prepaid card, checking, savings, money market, certificates of deposit, stored (cash) value accounts and/or the like) (Section [0107], [0130]-[0133], [0149], [0150] and [0391]);
…wherein the first transaction dataset and the second transaction dataset are linked to the user account (e.g. In some embodiments, the pay network server may generate a query, e.g., 6724, for issuer server(s) corresponding to the user-selected payment options. For example, the user's account may be linked to one or more issuer financial institutions ("issuers"), such as banking institutions, which issued the account(s) for the user. For example, such accounts may include, but not be limited to: credit card, debit card, prepaid card, checking, savings, money market, certificates of deposit, stored (cash) value accounts and/or the like) (Section [0228] and [0391]);
…wherein the transaction dataset is one of a plurality of transaction datasets that the application has access to via the user account and that is to be used in a transaction between a merchant and a user of the user device, and wherein the plurality of transaction datasets includes transaction datasets linked to the user account (e.g. FIGS. 4A-4B show screen shot diagrams illustrating example user interface(s) of a EOOR card selector component. In some embodiments, the user may access the wallet account screen 401 to modify the card selector preference of each card or multiple cards. All of the payment cards stored in the wallet may be made available for the user 403) and (e.g. In some embodiments, the pay network server may generate a query, e.g., 6724, for issuer server(s) corresponding to the user-selected payment options. For example, the user's account may be linked to one or more issuer financial institutions ("issuers"), such as banking institutions, which issued the account(s) for the user. For example, such accounts may include, but not be limited to: credit card, debit card, prepaid card, checking, savings, money market, certificates of deposit, stored (cash) value accounts and/or the like) (Section [0110], [0228] and [0391]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the payment card data addition process of Chatterjee to include the use of parsing the card dataset, determining a user account exists, and determining the card is not already part of the account before linking the card to the account, as taught by Hariramani, in order to achieve the predictable result of memory efficiency by allowing the wallet to only store the relevant card data needed to perform a transaction and providing convenience to the user by allowing them to easily add cards to their account that have not yet been linked.
Although Chatterjee/Hariramani discloses linking multiple payment cards to a mobile wallet application service profile and selecting a payment card in the electronic wallet to perform a payment transaction with a merchant, Chatterjee/Hariramani does not specifically disclose
displaying, through the user interface of the application, optically encoded information including a transaction dataset corresponding to the representation of the plurality of representations….
However Royyuru, in analogous art of electronic wallets, discloses:
displaying, through the user interface of the application, optically encoded information including a transaction dataset corresponding to the representation of the plurality of representations… (e.g. Additionally, the wallet application 147 may generate and direct the output of a wide variety of different payment options for presentation to the user. In this regard, user input associated with a type of desired payment transaction and/or a desired payment account may be received and processed by the wallet application 147. For example, user input requesting a barcode (or other image-based transaction) may be received at block 320) and (e.g. At block 325, the wallet application 147 may access at least a portion of the stored payment information from the secure element(s). The wallet application 147 may then utilize the accessed information to generate one or more barcode, QR code, or other images for display by the mobile device. For example, accessed payment information may be incorporated into one or more generated images. As another example, accessed VAS-related information (e.g., coupon data, etc.) may be incorporated into one or more generated images. The generated images (e.g., a generated barcode or QR code with payment information) may then be output for display at block 335) (Section [0698] and [0699]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the selected card mobile wallet payment transaction of Chatterjee to include the use of optical codes that represent the cards to perform the transaction, as taught by Chatterjee/Hariramani, in order to achieve the predictable result of providing convenience to the user by allowing them to perform a contactless transaction even if the merchant does not have a contactless reader (see Royyuru section [0003] and [0004]).
Per claim 5, Chatterjee/Hariramani/Royyuru discloses all the limitations of claim 4 above. Hariramani further discloses:
wherein receiving the transaction dataset includes parsing information associated with the first transaction medium to identify the first transaction dataset (e.g. automatically parsing the merchant-specific customer information shown on the customer card and adding the information to a secure virtual wallet profile for the customer stored in a payment network database) (Section [0698] and [0699]).
The motivation to combine Hariramani with Chatterjee/Royyuru is disclosed above with reference to claims 1, 4, and 19.
Per claims 6 and 20, Chatterjee/Hariramani/Royyuru discloses all the limitations of claims 4 and 19 above. Chatterjee further discloses:
wherein the first transaction medium is at least one of a gift card, a credit card, or a debit card (e.g. In such implementations, the VWCS server may initiate a card-based purchase transaction using a "card" (e.g., checking account, savings account, Paypal.TM. account, Google Checkout.TM. account, credit card, debit card, prepaid card, etc.) selected from the user's virtual wallet) (Section [0038]).
Per claim 7, Chatterjee/Hariramani/Royyuru discloses all the limitations of claim 4 above. Chatterjee further discloses:
wherein the first transaction medium is at least one of a coupon, a discount, or a promotion (e.g. In some implementations, the app may provide various alternate options for the user. For example, the app may provide the user with alternate merchants where the user may obtain the products and/or similar products, alternate products that may be comparable to the purchase products, competitive pricing information between merchants, discounts, coupons, and/or other offers for the user) (Section [0037], [0104], and [0105]).
Per claim 8, Chatterjee/Hariramani/Royyuru discloses all the limitations of claim 4 above. Chatterjee further discloses:
wherein the first representation of the first transaction medium includes a first image associated with the first transaction medium, and wherein the second representation of the second transaction medium includes a second image associated with the second transaction medium (e.g. requesting the user to select a payment option from the user's virtual wallet. Based on the message, a user interface rendered by the user's device may be populated with user card selection options, see 110) (Section [0035], [0036], and Fig. 1B).
Per claim 9, Chatterjee/Hariramani/Royyuru discloses all the limitations of claim 4 above. Chatterjee further discloses:
wherein the one of the plurality of representations is the first representation, and wherein the transaction dataset is the first transaction dataset (e.g. requesting the user to select a payment option from the user's virtual wallet. Based on the message, a user interface rendered by the user's device may be populated with user card selection options, see 110) (Section [0035], [0036], [0106], and Fig 1B).
Per claim 10, Chatterjee/Hariramani/Royyuru discloses all the limitations of claim 4 above. Chatterjee further discloses:
wherein the one of the plurality of representations is the second representation, and wherein the transaction dataset is the second transaction dataset (e.g. requesting the user to select a payment option from the user's virtual wallet. Based on the message, a user interface rendered by the user's device may be populated with user card selection options, see 110) (Section [0035], [0036], [0106], and Fig. 1B).
Per claim 11, Chatterjee/Hariramani/Royyuru discloses all the limitations of claim 4 above. Chatterjee further discloses:
wherein the first representation of the first transaction medium represents a selectable shortcut providing access to the first transaction dataset within the user interface, and wherein the second representation of the second transaction medium represents a selectable shortcut providing access to the second transaction dataset within the user interface (e.g. In such implementations, the VWCS server may initiate a card-based purchase transaction using a "card" (e.g., checking account, savings account, Paypal.TM. account, Google Checkout.TM. account, credit card, debit card, prepaid card, etc.) selected from the user's virtual wallet) (Section [0036], [0038], and Fig. 1B).
Per claim 12, Chatterjee/Hariramani/Royyuru discloses all the limitations of claim 4 above. Chatterjee further discloses:
wherein the application is a passbook application, and wherein the device is a mobile device (e.g. In some implementations, upon obtaining the message, the device may provide the user with an interface to make a selection of a card from the user's virtual wallet to utilize to complete the purchase transaction. For example, the user's device may be executing an application module ("app"), via which the user's device may communicate with the pay network. The user's device may display the virtual wallet card selection options obtained from the pay network via the app to the user) (Section [0036], [0037], [0040], Figs. 1B and 2).
Per claim 13, Chatterjee/Hariramani/Royyuru discloses all the limitations of claim 4 above. Chatterjee further discloses:
wherein facilitating the transaction using the transaction dataset includes communicating information from the device to a point of sale (POS) device, wherein the information is associated with the transaction dataset (e.g. In embodiments where the user utilizes a user wallet device, the user wallet device may provide payment information to the PoS client, formatted according to a data formatting protocol appropriate to the communication mechanism employed in the communication between the user wallet device and the PoS client) (Section [0117]-[0119]).
Per claim 15, Chatterjee/Hariramani/Royyuru discloses all the limitations of claim 4 above. Chatterjee further discloses:
verifying an identity of a user of the device based on biometric data received via a biometric sensor of the device to authorize the facilitating of the transaction using the transaction dataset (e.g. In some implementations, the VWCS may utilize face, biometric and/or like recognition (e.g., using pattern classification techniques) to determine the identity of the user, e.g., 304a) (Section [0042] and Fig. 3A).
Per claim 16, Chatterjee/Hariramani/Royyuru discloses all the limitations of claim 15 above. Chatterjee further discloses:
wherein the biometric data is associated with at least one of a fingerprint, a handscan, a retinal scan, an image, a video, or voice recognition (e.g. For example, the VWCS may initiate a video challenge for the user, e.g., 301. For example, the user may need to present him/her-self via a video chat, e.g., 302. In some implementations, a customer service representative, e.g., agent 304b, may manually determine the authenticity of the user using the video of the user. In some implementations, the VWCS may utilize face, biometric and/or like recognition (e.g., using pattern classification techniques) to determine the identity of the user, e.g., 304a) (Section [0042] and Fig. 3A).
Per claim 17, Chatterjee/Hariramani/Royyuru discloses all the limitations of claim 15 above. Chatterjee further discloses:
wherein receiving the transaction dataset is associated with scanning an optical code using a camera of the device (e.g. With reference to FIG. 10E, in one embodiment, the snap mode may also offer facilities for adding a funding source to the wallet application. In one implementation, a pay card such as a credit card, debit card, pre-paid card, smart card and other pay accounts may have an associated code such as a bar code or QR code. Such a code may have encoded therein pay card information including, but not limited to, name, address, pay card type, pay card account details, balance amount, spending limit, rewards balance, and/or the like) (Section [0106]).
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Chatterjee/Hariramani/Royyuru, as applied to claim 4 above, in further view of US 20120191612 A1 (“Spodak”).
Per claim 14, although Chatterjee/Hariramani/Royyuru discloses an electronic wallet that allows a user to select a transaction dataset to perform a payment, Chatterjee/Hariramani/Royyuru does not specifically disclose:
wherein the transaction dataset is specific to a merchant.
However Spodak, in analogous art of electronic wallets, discloses:
wherein the transaction dataset is specific to a merchant (e.g. The retailer may operate a website through which a user can purchase products and gift cards specific to the retailer. The retailer may allow a user to purchase a gift card with delivery being in electronic form to the computing device 1630. In this case, no physical card would be sent to the requester and/or the recipient; instead, card data would be delivered from computing device 1610 to computing device 1630 and the recipient would be able to program universal card 1640 to emulate a physical gift card) (Section [0108]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the payment card data of Chatterjee/Royyuru to include the use of payment card data that is specific to a merchant, as taught by Spodak, in order to achieve the predictable result of providing convenience to the user by allowing them to use the electronic wallet to also store gift cards that are specific to certain retailers.
Conclusion
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US Patent Number 5748737 to Daggar, US Patent Number 8285329 B1 to Zhu, US
Publication Number 20130152185 A1 to Singh, and US Publication Number 20130171929 A1 to
Adams all disclose systems and methods that allow users to store cards in an electronic wallet
and then use those cards to perform payment transactions.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TIMOTHY P SAX whose telephone number is (571) 272-2935. The examiner can normally be reached on M-F 8-4:30.
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 at (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.
/TIMOTHY PAUL SAX/Examiner, Art Unit 3698
Prosecution Insights