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 12/16/2024.
Claims
Claims 1-20 have been presented and are currently pending in the application.
Information Disclosure Statements
The Information Disclosure Statements (IDS) that were filed on 2/13/2025 and 6/9/2025 have been considered.
Claim Objections
Claims 9 and 10 are objected to because of the following informalities:
In claim 9, “wherein the transaction dataset the first transaction dataset” should read “wherein the transaction dataset is the first transaction dataset” (emphasis added).
In claim 10, “wherein the transaction dataset the second transaction dataset” should read “wherein the transaction dataset is the second transaction dataset” (emphasis added).
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-16, 19, and 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 1-3 are directed to a first method, claims 4-18 are directed to a second method, and claims 19-20 are directed to a system. Therefore, these claims fall within the four statutory categories of invention.
Claim 1 recites adding payment card information to a list and selecting payment card information from the list to perform a transaction. Specifically, the claim recites “receiving… information associated with a first card; parsing the information… to identify a first transaction dataset associated with use of the first card; adding, to a user interface… a first representation of the first card, wherein the user interface… includes a second representation of a second card; adding… access to the first transaction dataset associated with use of the first card, wherein… has access to the second transaction dataset associated with use of the second card; receiving… an input indicating a selection of one 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; facilitating… a transaction using a transaction dataset corresponding to the one of the plurality of representations, wherein the transaction dataset is one of a plurality of transaction datasets that the… has access to, wherein the plurality of transaction datasets includes the first transaction dataset and the second transaction dataset”, which is grouped within the “Mental Processes” grouping of abstract ideas in prong one of step 2A of the Alice/Mayo test because the claims involve adding payment card information to a list and selecting payment card information from the list to perform a transaction which falls under the category of concepts performed in the human mind (pen and paper). Accordingly, the claims recite an abstract idea (See pages 7, 10, Alice Corporation Pty. Ltd. v. CLS Bank International, et al., US Supreme Court, No. 13-298, June 19, 2014; MPEP § 2106.04(a)). Claim 4 is directed to a second method that performs the same steps of claim 1 and claim 19 is directed to a system that performs the same functions of claim 1. Therefore Claims 4 and 19 are also directed to the abstract idea of adding payment card information to a list and selecting payment card information from the list to perform a transaction.
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test, the additional element(s) of claims 1, 4, and 19, such as the use of the at least one memory, at least one processor, device, and application, merely use(s) a computer as a tool to perform an abstract idea. Specifically, the at least one memory, at least one processor, device, and application perform(s) the steps or functions of adding payment card information to a list and selecting payment card information from the list to perform a transaction. The use of a processor/computer as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field (MPEP § 2106.05(a)), the claims do not apply the abstract idea with, or by use of, a particular machine (MPEP § 2106.05(b)), and the claims do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP § 2106.05(e) and Vanda Memo). Therefore, the claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea.
Claims 1, 4 and 19 do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B of the Alice/Mayo test (See MPEP § 2106.05), the additional element(s) of using a at least one memory, at least one processor, device, and application to perform the steps amounts to no more than using a computer or processor to automate and/or implement the abstract idea of adding payment card information to a list and selecting payment card information from the list to perform a transaction. As discussed above, taking the claim elements separately, the at least one memory, at least one processor, device, and application perform(s) the steps or functions of the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of adding payment card information to a list and selecting payment card information from the list to perform a transaction. Therefore, the use of these additional elements does no more than employ the computer as a tool to automate and/or implement the abstract idea. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claims are not patent eligible.
The dependent claims 2, 3, 5-16, and 20 further describe the abstract idea.
Claims 2, 6, and 20 describe the first card/transaction medium and do not include any additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Claims 3 and 8 recite the abstract idea of associating an image of the card/transaction medium with the card/transaction medium. The claims do not include any additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Claim 5 recites the abstract idea of parsing information associated with the first transaction medium to identify the first transaction dataset. . The claim does not include any additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Claim 7 describes the first transaction and does not include any additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Claims 9 and 10 recite that the list contains more than one card and card data. The claims do not include any additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Claim 11 recites the abstract idea of selecting a transaction medium to get access to the associated transaction dataset. The use of the user interface and selectable shortcut is generally linking the use of the judicial exception to the particular technological environment of computer interfaces.
Claim 12 describes the application and the device. The claim does not include any additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Claim 13 recites the abstract idea of facilitating a transaction by communicating the transaction dataset with a point of sale. The claim does not include any additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Claim 14 describes the transaction dataset and does not include any additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Claim 15 recites the abstract idea of verifying an identity of a user of the device based on biometric data received from a biometric sensor. This is recited at a high level and can be done by a user. For example, a human can check a user’s id to make sure that the user is who they say they are.
Claim 16 describes the biometric data and does not include any additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claims 17 and 18 contain subject matter that is eligible under 35 U.S.C. 101. Claims 17 and 18 recite the use of cameras to scan optical codes and transaction mediums to receive the transaction datasets. These additional elements are indicative of integration into a practical application and are indicative of an inventive concept (aka “significantly more”) than the abstract idea.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that
form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
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.
Claims 4, 6-13, 15-20 are rejected under 35 U.S.C. 102(a)(2) as disclosed by US 20120310826 A1 (“Chatterjee”).
Per claims 4 and 19, Chatterjee discloses:
receiving, at a device, a first transaction dataset associated with use of a first 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 [0106]);
adding, to a user interface of an application on the device, 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 one 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]);
facilitating, through the application, a transaction using a transaction dataset corresponding to the one of the plurality of representations, wherein the transaction dataset is one of a plurality of transaction datasets that the application has access to, wherein the plurality of transaction datasets includes the first transaction dataset and the second 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 [0035], [0036], [0117]-[0119]).
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]).
Per claims 6 and 20, Chatterjee 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 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 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 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 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 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 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 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 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 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 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 discloses all the limitations of claim 4 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 discloses all the limitations of claim 4 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]).
Per claim 18, Chatterjee discloses all the limitations of claim 4 above. Chatterjee further discloses:
wherein receiving the transaction dataset is associated with scanning the first transaction medium using a camera of the device (e.g. In one implementation, the code may be found on a face of the physical pay card) (Section [0106]).
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-3 and 5 are rejected under 35 U.S.C. 103 as being unpatentable over US 20120310826 A1 (“Chatterjee”) and US 20130024371 A1 (“Hariramani”).
Per claim 1, Chatterjee discloses:
receiving, at a device, information associated with a first 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 [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 one 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]);
facilitating, through the application, a transaction using a transaction dataset corresponding to the one of the plurality of representations, wherein the transaction dataset is one of a plurality of transaction datasets that the application has access to, wherein the plurality of transaction datasets includes the first transaction dataset and the second 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 [0035], [0036], [0117]-[0119]).
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.
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]).
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, as taught by Hariramani, in order to achieve the predictable result of memory efficiency by allowing the wallet to only store the relevant data needed to perform a transaction using the card.
Per claim 2, Chatterjee/Hariramani 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 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 claim 5, Chatterjee discloses all the limitations of claim 4 above. However Chatterjee does not specifically disclose:
wherein receiving the transaction dataset includes parsing information associated with the first transaction medium to identify the first transaction dataset.
Hariramani, in analogous art of Electronic Wallets, 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]).
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, as taught by Hariramani, in order to achieve the predictable result of memory efficiency by allowing the wallet to only store the relevant data needed to perform a transaction using the card.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Chatterjee, as applied to claim 4 above, in further view of US 20120191612 A1 (“Spodak”).
Per claim 14, although Chatterjee discloses an electronic wallet that allows a user to select a transaction dataset to perform a payment, Chatterjee 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 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.
/TS/
Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698