DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
2. The information disclosure statement (IDS) submitted on 12/29/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments
3. Applicant filed the Request for Continued Examination on 12/26/2025. Claims 1, 3, and 5-22 are pending. Claims 1, 3, 5, 11, and 19-20 are amended. Claims 21-22 are newly added. Claims 1, 3, and 5-22 are rejected. After careful consideration of applicant arguments, the examiner finds them to be not persuasive.
Rejection under 35 USC § 101
4. Applicant’s arguments toward 35 U.S.C. § 101 rejection are not persuasive. Amended independent claims 1, 19, and 20 do not have additional elements that could lead to an improvement in the functioning of a computer, or an improvement to other technology or technical field.
5. Applicant is of the opinion “that the claims recite an improvement to other technology or technical field, and also recite use of the ideas in a meaningful way beyond generally linking to a particular technological environment”, and lists amended claim 1 limitations. And Applicant concludes that “The specific, concrete approach in these additional elements provides a combination of steps that improves the technical field, by providing low-friction authentication security, interfacing between merchants and a system that provides wallet services through a user interface provided by an SDK, and a unique arrangement of multiple user interfaces, which individually and collectively use the ideas in meaningful ways that are not generally linking to a technological environment. Indeed, the particular limitations of the claims integrates the ideas into a practical application.”.
Examiner respectfully disagrees.
Mentioned above the claim features performed by using the computer components. 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 steps of – determining a shared wallet based on user identifier and displaying a list of cards associated with multiple merchants, and providing a selected card information to a merchant – may facilitate commerce but does not improve computers or technology. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claim is directed to the abstract idea.
6. Applicant is of the opinion that “amended independent claims 1, 19, and 20 add specific limitations that are improvements beyond what is well-understood, routine, or conventional in the field. Specifically, as quoted above, amended independent claims 1, 19, and 20 recite a non-conventional and non-routine arrangement systems and ordered combination of limitations above and beyond any alleged abstract idea.”
Examiner respectfully disagrees.
The rejection was not based on well-understood, routine, or conventional activity. To the contrary, the claim 1 is directed to the abstract idea of processing a transaction using a shared payment instrument (e.g., (claim 1) “sending … card information … to enable the merchant to process the transaction”; (PGPub, para 63) “… displaying, to the user … a list of cards in a shared wallet for the user… receiving … a selection from the user of a selected card from the list of the cards for processing a transaction…” – is part of the abstract idea. The steps of – providing … a software development kit (SDK) to the merchant, wherein the SDK is configured to launch a first user interface that interfaces with the system to provide the wallet services; obtaining … a unique identifier of a user, wherein the unique identifier is provided from the user to the merchant through a second user interface displayed to the user – may facilitate commerce but does not improve computers or technology. The additional elements merely implement the abstract idea and does not improve functioning of a computer or computer technology. For the above reasons, the claims are directed to an abstract idea without significantly more.
The claims are therefore not patent eligible.
Claim Rejections - 35 USC §101
7. 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.
8. Claims 1, 3, and 5-22 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
9. In the instant case, claims 1, 19, and 20 are directed to a “method, system, and one or more non-transitory computer-readable media for providing a user interface for online checkout using a shared wallet across issuers”.
10. Claim 1 recites “processing a transaction using a shared payment instrument”. Specifically, claim 1 recites “enrolling …a merchant … to provide wallet services to the merchant; providing … to the merchant, wherein … is configured to launch … that interfaces with … to provide the wallet services; obtaining … and from the merchant, a unique identifier of a user, wherein the unique identifier is provided from the user to the merchant through … displayed to the user; sending … an authentication code … of the user; receiving … displayed to the user, the authentication code, wherein … is run by the merchant to launch … that interfaces with … and … is launch by the merchant after the merchant displays … to the user; verifying the authentication code; determining … of the user based on the unique identifier of the user matching a registered identifier of the user that is associated with … wherein … with cards issued to the user from multiple different issuers, and the registered identifier is associated with … based on the registered identifier having been registered for the user at one or more of the multiple different issuers; after verifying the authentication code, sending … instructions… wherein… is accessible to multiple different merchants; receiving … displayed to the user, a selection from the user of a selected card from the list of the cards for processing a transaction; and sending … card information for the selected card to the merchant to enable the merchant to process the transaction”. Subject matter grouped under “Certain methods of organizing human activity (e.g., commercial or legal interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
11. This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of claim 1 such
as “a system”, “a software development kit (SDK)”, “a first user interface”, “a second user interface”, “a device of the user”, “a shared wallet”, “the shared wallet is pre-populated, on an opt-out basis”, “displaying, to the user through the first user interface”, and “display, to the user through the first user interface, a list of the cards in the shared wallet of the user” represent the use of a computer as a tool to perform an abstract idea and/or does no more than generally link the abstract idea to a particular field of use. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to (i.e., automate) the acts of processing a transaction using a shared payment instrument (“… the additional elements to be mere instructions to apply an exception, because they recite no more than an idea of a solution or outcome…”, MPEP 2106.05(f)(1)). With respect to “providing, by the system, a software development kit (SDK) to the merchant…”, “sending, from the system, an authentication code to a device of the user”, “receiving, by the system and through the first user interface displayed to the user, the authentication code…”, “…sending, by the system, instructions to display, to the user through the first user interface, a list of the cards in the shared wallet of the user…”, “receiving, by the system and through the first user interface displayed to the user, a selection from the user of a selected card from the list of the cards for processing a transaction”, and “sending by the system, card information for the selected card to the merchant to enable the merchant to process the transaction” is simply transmitting data “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice) does not integrate a judicial exception into a practical application or provide significantly more”, (MPEP 2106.05(f)(2)).
12. When analyzed under step 2B (MPEP 2106.04 II), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claim merely describes the concept of processing a transaction using a shared payment instrument using computer technology (e.g., the processor). Therefore, the use of these additional elements does no more than employ a computer as a tool to automate and/or implement the abstract idea, which cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)).
13. Hence, claim 1 is not patent eligible.
14. Claims 19 and 20 also recite “processing a transaction using a shared payment instrument”. Subject matter grouped under “Certain methods of organizing human activity (e.g., commercial or legal interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
15. As in the case of claim 1, the judicial exception is not integrated into a practical application because when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of claims 19 and 20 such as “a system”, “one or more processors”, “one or more non-transitory computer-readable media”, “a software development kit (SDK)”, “a first user interface”, “a second user interface”, “a device of the user”, “a shared wallet”, “the shared wallet is pre-populated, on an opt-out basis”, “displaying, to the user through the first user interface”, and “display, to the user through the first user interface, a list of the cards in the shared wallet of the user” represent the use of a computer as a tool to perform an abstract idea and/or does no more than generally link the abstract idea to a particular field of use. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to (i.e., automate) the acts of processing a transaction using a shared payment instrument (“… the additional elements to be mere instructions to apply an exception, because they recite no more than an idea of a solution or outcome…”, MPEP 2106.05(f)(1)). With respect to “providing, by the system, a software development kit (SDK) to the merchant…”, “sending, from the system, an authentication code to a device of the user”, “receiving, by the system and through the first user interface displayed to the user, the authentication code…”, “…sending, by the system, instructions to display, to the user through the first user interface, a list of the cards in the shared wallet of the user…”, “receiving, by the system and through the first user interface displayed to the user, a selection from the user of a selected card from the list of the cards for processing a transaction”, and “sending by the system, card information for the selected card to the merchant to enable the merchant to process the transaction” is simply transmitting data “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more”, (MPEP 2106.05(f)(2)).
16. When analyzed under step 2B (MPEP 2106.04 II), the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claims merely describes the concept of processing a transaction using a shared payment instrument using computer technology (e.g., the processor). Therefore, the use of these additional elements does no more than employ a computer as a tool to automate and/or implement the abstract idea, which cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)).
17. Hence, claims 19 and 20 are not patent eligible.
18. Dependent claim 3 further describes the abstract idea of processing a transaction using a shared payment instrument, as recites “the merchant displays … to the user through … wherein … comprise an indication of the selected card and a selector to allow the user to request processing of the transaction; and … further comprise an indication of a shipping address to be used for the transaction”. The additional elements such as “one or more checkout pages” and “the second user interface” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 5 further describes the abstract idea of processing a transaction using a shared payment instrument, as recites “wherein the unique identifier is provided from the user to the merchant through … after the user starts a checkout process at the merchant”. The additional element such as “the second user interface” represents the use of a computer as a tool to perform an abstract idea and does no more than generally link the abstract idea to a particular field of use. And, therefore, does not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 6 further describes the abstract idea of processing a transaction using a shared payment instrument, as recites “wherein obtaining the unique identifier comprises: receiving the unique identifier from the merchant based on the unique identifier being provided to the merchant from the user”.
Dependent claim 7 further describes the abstract idea of processing a transaction using a shared payment instrument, as recites “wherein the registered identifier comprises … that is registered for the user with the one or more of the multiple different issuers”. The additional element such as “an email address” represents the use of a computer as a tool to perform an abstract idea and does no more than generally link the abstract idea to a particular field of use. And, therefore, does not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 8 further describes the abstract idea of processing a transaction using a shared payment instrument, as recites “… a request for a phone number of the user; and receiving, through … the phone number of the user”. The additional element such as “displaying, through the first user interface” represents the use of a computer as a tool to perform an abstract idea and does no more than generally link the abstract idea to a particular field of use. And, therefore, does not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 9 further describe the abstract idea of processing a transaction using a shared payment instrument, as recites “wherein … the user using the phone number based on the phone number of the user being registered for the user with the one or more of the multiple different issuers”. The additional element such as “the authentication code is sent to the device” represent the use of a computer as a tool to perform an abstract idea and does no more than generally link the abstract idea to a particular field of use. And, therefore, does not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 10 further describes the abstract idea of processing a transaction using a shared payment instrument, as recites “displaying, through … for selection by the user, one or more other phone numbers that are registered for the user with the multiple different issuers based on the phone number for the user not being registered for the user with one or more of the multiple different issuers; and receiving, through … a selection from the user of one of the one or more other phone numbers, wherein: authentication code is sent to the device of the user using the one of the one or more other phone numbers”. The additional elements such as “displaying, through the first user interface”, “receiving, through the first user interface, a selection”, and “the authentication code is sent to the device” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, does not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 11 further describes the abstract idea of processing a transaction using a shared payment instrument, as recites “displaying, through … to enable the user to request deactivating the shared … of the user”. The additional elements such as “displaying, through the first user interface, an opt out selector” and “the shared wallet” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, does not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 12 further describes the abstract idea of processing a transaction using a shared payment instrument, as recites “displaying, through … for selection by the user, one or more phone numbers that are registered for multiple shared … based on the unique identifier being associated with multiple shared …; and receiving, through … a selection from the user of one of the one or more phone numbers, wherein: the authentication code is sent … the user using the one of the one or more phone numbers”. The additional elements such as “displaying, through the first user interface for selection”, “multiple shared wallets”, “receiving, through the first user interface, a selection”, and “the authentication code is sent to the device” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, does not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 13 further describes the abstract idea of processing a transaction using a shared payment instrument, as recites “wherein the authentication code is verified before the list of the cards is displayed to the user”.
Dependent claim 14 further describes the abstract idea of processing a transaction using a shared payment instrument, as recites “wherein … further comprises a respective card image associated with each of the cards”. The additional element such as “the list of the cards displayed on the first user interface” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, does not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 15 further describes the abstract idea of processing a transaction using a shared payment instrument, as recites “after receiving the selection from the user of the selected card, displaying, to the user through … a request for a card authentication code for the selected card; receiving, through… the card authentication code for the selected card; and verifying the card authentication code for the selected card before providing the card information for the selected card to the merchant for processing the transaction”. The additional elements such as “displaying, to the user through the first user interface” and “receiving, through the first user interface, the card authentication code” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, does not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 16 further describes the abstract idea of processing a transaction using a shared payment instrument, as recites “wherein the card information for the selected card comprises … for processing the transaction”. The additional element such as “a token cryptogram” represents the use of a computer as a tool to perform an abstract idea and does no more than generally link the abstract idea to a particular field of use. And, therefore, does not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 17 further describes the abstract idea of processing a transaction using a shared payment instrument, as recites “receiving a request from the user to add a new card to the shared …”. The additional element such as “the shared wallet” represents the use of a computer as a tool to perform an abstract idea and does no more than generally link the abstract idea to a particular field of use. And, therefore, does not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 18 further describes the abstract idea of processing a transaction using a shared payment instrument, as recites “displaying … for an issuer of at least one of the cards in the shared …”. The additional elements such as “displaying to the user a deep link” and “the shared wallet” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, does not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 21 further describes the abstract idea of processing a transaction using a shared payment instrument, as recites “the merchant displays … to the user through …; … pages comprise an indication of the selected card and a selector to allow the user to request processing of the transaction; and … pages further comprise an indication of a shipping address to be used for the transaction”. The additional elements such as “displays one or more checkout pages to the user through the second user interface” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, does not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 22 further describes the abstract idea of processing a transaction using a shared payment instrument, as recites “wherein the unique identifier is provided from the user to the merchant through … after the user starts a checkout process at the merchant”. The additional element such as “the second user interface” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, does not improve the functioning of a computer, or to any other technology or technical field.
Conclusion
19. The claims as a whole do not amount to significantly more than the abstract idea itself. This is because the claims do not effect an improvement to another technology or technical field; the claims do not amount to an improvement to the functioning of a computer system itself; and the claims do not move beyond a general link of the use of an abstract idea to a particular technological environment.
20. Accordingly, there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself.
Claim Rejections - 35 USC § 103
21. 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.
22. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
23. 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.
24. Claims 1, 3, 5-9, and 11-22 are rejected under 35 U.S.C. 103 as being unpatentable over US20170140356A1 to Desai et al. in view of US9355393B2 to Purves et al.
25. As per claims 1, 19, and 20:
Desai et al. discloses the following limitations:
enrolling, by a system, a merchant for the system to provide wallet services to the merchant ([0379] “…The publish widget use case may allow the ecosystem provider to publish an approved widget…Before publishing a widget, the wallet administrator may have to be registered, the service provider may have to be registered, the wallet administrator may have to be logged into the wallet management console, and the widget may have to be validated and approved”, fig.55, item 5508; [0526] “…The SDP 5508 may be configured to onboard individual service providers, aggregate disparate service hosts, enforce service implementation standards, and manage overall growth of the ecosystem…”, [0527] “…Each partner service provider may be on-boarded through a series of steps that are modeled in the SDP 5508. These steps may be defined by the payment facilitator and be governed by the nature of the service offering (e.g. payment, offers, loyalty, etc.)”, [0530] “…a first step may include registration and KYC. At this step, the consumer may request a service (wallet, payment account, etc.) and provide the required personal information in order to perform relevant KYC steps…A next step may be service provisioning. At this step a service may be provisioned to the user…”)
providing, by the system, a software development kit (SDK) to the merchant, wherein the SDK is configured to launch a first user interface that interfaces with the system to provide the wallet services (Fig.2, item 212; [0081] “…service providers may use the MTP SDK to build widgets that may be loaded into the wallet. These widgets may provide incremental, functionality that may enhance the overall appeal of the mobile application. The wallet and the widgets may provide the users with OTA value added services (VAS) and proximity NFC services. The container … may provide the wallet and the widgets a secure runtime environment and the services to communicate OTA with the server…”, [0086] “…A MTP 212 may be a client server platform… The distinct components may include a mobile enabling tier, a service tier and a software development kit (SDK)…”, [0451] “…The set of tools may include a software development kit for constructing a mobile transaction ecosystem…”, [0452] “…The MTP SDK may provide service provider programmers and the like with tools for implementing and configuring transaction workflows, service provider-specific widgets for use on client devices, wallets that include device specific and device agnostic capabilities that may be accessed through APIs…”, [0456]-[0457] “…the application for in-situ customizing of a portion of a widget…a user interface template for receiving widget functional code and descriptors from a widget development process performed on a networked server, a user interface for facilitating access to widget features and functions via icons defined by a widget descriptor…”)
obtaining, by the system and from the merchant, a unique identifier of a user, wherein the unique identifier is provided from the user to the merchant through a second user interface displayed to the user (Fig.41, items 4104, 4106; [0399] “A point of sale device 4104 may be activated by near-by presence of a mobile phone that incorporates a mobile wallet 4106 requesting to perform an electronic transaction such as a purchase. The POS device 4104 and mobile wallet 4106 may exchange non-personal information … along with a unique identifier generated by the mobile wallet 4106…”, fig.48, items 4802, 4804, 4806, 4808; [0426] “… a user may present an NFC-enabled smartphone 4802 to a merchant's NFC reader 4804 at a point-of-sale system 4806. The NFC-enabled smartphone 4802 dynamically generates a token that contains the credit card number and expiration date of the user and passes the token through the NFC reader 4804 to the point-of-sale system 4806. The point-of-sale system 4806 passes the token to the mobile transaction platform server 4808…”, [0534] “…The consumer may be required to tap the phone at the NFC enabled POS to transmit token… [0535] “A next step after initiating the checkout process may require the POS to processes the transaction and route the process to the payment facilitator…”)
[receiving] …wherein the SDK is run by the merchant to launch the first user interface that interfaces with the system, and the first user interface is launch by the merchant after the merchant displays the second user interface to the user (Fig.23, items 2308, 2310; [0354] “… the service providers may use an MTP software development kit to build widgets that may run within a MTP wallet container.…”, [0374] “…the user to select a widget … the mobile wallet to load the widget … onto the service screens. The user may browse the service screens and selects product/service to pay…The user may select a payment card and provides the payment info…”)
determining a shared wallet of the user based on the unique identifier of the user matching a registered identifier of the user that is associated with the shared wallet ([0522] “… The SDPs 5508 may be configured to maintain a parent-child hierarchy with multiple wallets. Each of the applications such as mobile applications may be linked to an independent wallet instance. The SDPs 5508 may be configured to maintain a parent-child relationship between such as a parent payment facilitator wallet and child application wallets…”, [0538] “…The consumers may be required to pay at a POS using their existing, in-market merchant mobile applications linked to their primary payment facilitator wallet through direct child wallets that are provisioned and managed by the SDP 5508 wallet platform…”), wherein the shared wallet is pre-populated ([0525] “…The wallet architecture may also enable automatic population of the consumer's branded container of the payment facilitator with payment credentials in the consumer's master wallet. This may facilitate management of all accounts from a single location…”, [0545] “…The wallet may get automatically populated from the SDP as consumers create their payment facilitator wallet…”), on an opt-out basis ([0377] “…The terminate wallet use case may allow a wallet administrator to terminate a wallet account. The terminate wallet use case may include a mobile wallet, a wallet server, a TSM, a TSM proxy client…”, [0525] “… each wallet may be … managed or activated or locked or suspended and the like independently…”), with cards issued to the user from multiple different issuers, and the registered identifier is associated with the shared wallet based on the registered identifier having been registered for the user at one or more of the multiple different issuers (fig.6, items 610a, 610n; [0118] “The ecosystem 600 may further include a plurality of issuers of transaction instruments 610. The issuer 610 may provide various transaction instruments such as a virtual credit card, a gift card, a loyalty card, tickets and the like…”, [0204] “…The platform may create the instrument (i.e., service account reference) record that may be associated with the wallet account. The platform may mark the instrument record status as REGISTERED, which may be updated by the issuer system…”, fig.31, items 3100, 3102; [0366] “FIG. 31 illustrates a method 3100 for wallet activation by the user. The method 3100 includes the mobile wallet showing a registration & activation screen to the user that includes an email address and a personal identification number (PIN) at step 3102…”)
after verifying the authentication code, sending, by the system, instructions to display, to the user through the first user interface, a list of the cards in the shared wallet of the user, wherein the shared wallet is accessible to multiple different merchants ([0533] “… The mobile application may connect to the SDP 5508 to validate login and authenticate consumer and device. The mobile application may present a list of payment options that may be stored in the consumer's mobile wallet upon successful authentication of the service and device…”, [0547] “…The consumer may then be required to select a merchant from the dashboard of pay-enabled merchants. The merchant widget may be launched in a “Pay” mode and present a list of payment options accepted at the merchant POS 5602. The list of payment options may be a filtered view on the locally stored options in the consumer's wallet as a part of the payment facilitator container…”, [0538] “…The consumers may be required to pay at a POS using their existing, in-market merchant mobile applications linked to their primary payment facilitator wallet…The SDP 5508 may provide authenticated, controlled, and filtered access to the consumer's payment facilitator wallet and the merchant application may be used for transaction at the POS…”, [0540] “…the payment facilitator mobile application may interact with merchant POS to perform transactions without any additional development by merchants…”)
receiving, by the system and through the first user interface displayed to the user, a selection from the user of a selected card from the list of the cards for processing a transaction ([0374] “… The user may select a payment card and provides the payment info… user may select a payment method available on wallet …”, [0510] “…the wallet may … provide options for selection of a specific account for a transaction, execute the transaction with the POS 5402 or payment gateway with the selected account…”, [0533] “…The consumer may be required to choose a payment option (for example, a gift card) from the list provided to the consumer.”)
sending by the system, card information for the selected card to the merchant to enable the merchant to process the transaction ([0374] “…The step … may require the wallet server to provide the payment information to the service provider…”, [0524] “… The mobile application may request a token from the SDP 5508 at the time of payment. The SDP 5508 may be configured to use an enterprise service bus (ESB) to retrieve a token for the payment account. The token may be a one-time token such as generated by the issuer system… The token may then be used at the POS through one of the available channels…”, [0534] “…The mobile application may request the SDP 5508 for a token for the selected payment card. The SDP 5508 may authenticate the mobile application and may route the request to corresponding token generator for a concerned issuer…”, [0548] “The merchant widget may request a transaction payload from the SDP that may be sent to the merchant POS … for the corresponding channel supported by the merchant POS … The SDP may transfer a transaction payload formatted for the merchant POS…”)
Desai et al. does not disclose, however, Purves et al., as shown, discloses the following limitations:
sending, from the system, an authentication code to a device of the user (Fig.20a, item 2009; col.25, lines 36-38; “the consumer may indicate that the virtual wallet account is to be set up with the requirement for two factor authentication 2009.”, col.25, lines 41-43 “a user may be required to provide a user name/password combination and a one-time code generated by their mobile device.”, col.20, lines 5-7 “a tiered authentication may be employed to more rigorously authenticate the merchant/customer…”, col.20, lines 12-13 “get customer confirmation, request digital certification, etc.”, col.20, lines 21-24 “a secure key from a issuer is passed to put on a phone or other client device, , so that the wallet knows a secure key from the issuer was present during the transaction”)
receiving, by the system and through the first user interface displayed to the user, the authentication code… (Fig.18a, items 1806, 1821, 1825; col.24, lines 12-21 “Client 1806 then renders the lightbox 1825… Upon rendering of the lightbox, user 1821 is then presented with reference links that have already been created… the user may re-use a previously created reference payment, persona, address, or other link by selecting its alias from the lightbox… the user can create a new reference link from within the lightbox.”)
verifying the authentication code (Col.20, lines 5-14 “depending on the merchant request, a tiered authentication may be employed to more rigorously authenticate the merchant/customer. …a merchant that usually transacts against the primary card and primary shipping address may request to execute a transaction against another shipping address… Such a request may then cause the wallet to step up the authentication protocol (e.g., get customer confirmation, request digital certification, etc.) to ensure that the transaction being executed is not a fraudulent transaction.”, fig.20a, item 2009; col.25, lines 36-38; “the consumer may indicate that the virtual wallet account is to be set up with the requirement for two factor authentication 2009.”, col.25, lines 41-43 “a user may be required to provide a user name/password combination and a one-time code generated by their mobile device.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method and system for facilitating the creation of a virtual wallet account that a financial institution may already have information in their records such as payment accounts, billing address, credit history reports of Purves et al. (‘393, col.3, lines 34-37) with teaching of Desai et al. for providing a secure and safe electronic business operations among users, payment facilities, and merchants through the use of dynamic authentication of each user (‘356, [0012]) for setting up with the requirement for two factor authentication that the wallet knows a secure key from the issuer was present during the transaction, reusing a previously created credentials such as a payment info, persona, address, and providing a user name/password combination and a one-time code generated by their mobile device (‘393, col.25, lines 37-38, col.24, lines 18-19, col.25, lines 41-43).
As per claim 19 Desai et al. additionally discloses the following limitations:
A system comprising one or more processors and one or more non-transitory computer-readable media storing computing instructions that, when executed on the one or more processors, cause the one or more processors to perform operations ([0158] “… systems described herein of multi-domain ecosystem secure personalized transactions includes a computer readable medium containing program instructions. The execution of the program instructions by one or more processors of a computer system may cause the one or more processors to carry out the steps”)
As per claim 20 Desai et al. additionally discloses the following limitations:
One or more non-transitory computer-readable media storing computing instructions that, when executed on one or more processors, cause the one or more processors to perform operations ([0158] “…a computer readable medium containing program instructions. The execution of the program instructions by one or more processors of a computer system may cause the one or more processors to carry out the steps”)
26. As per claims 3 and 21:
Desai et al. discloses the following limitations:
the merchant displays one or more checkout pages to the user through the second user interface (Fig.33, items 3300, 3304, 3308; [0374] “…At step 3304 the method 3300 may require the mobile wallet to load the widget at step 3304 onto the service screens. The user may browse the service screens and selects product/service to pay at step 3308…”, [0547] “…The consumer may then launch a payment facilitator mobile application 5604 on the mobile phone and may be required to enter a payment facilitator managed login credential…”)
the one or more checkout pages comprise an indication of the selected card and a selector to enable the user to request processing of the transaction ([0533] “…The mobile application may present a list of payment options that may be stored in the consumer's mobile wallet upon successful authentication of the service and device. The consumer may be required to choose a payment option … from the list provided to the consumer.”, [0547] “… The merchant widget may be launched in a “Pay” mode and present a list of payment options accepted at the merchant POS. The list of payment options may be a filtered view on the locally stored options in the consumer's wallet as a part of the payment facilitator container…”)
Desai et al. does not disclose, however, Purves et al., as shown, discloses the following limitations:
the one or more checkout pages further comprise an indication of a shipping address to be used for the transaction (Fig. 14, item 1403; col.21, lines 15-17 “the merchant may place a button 1403 on their web page that may facilitate the creation of a reference account link”, col.21, lines 22-24 “the button may designate a reference for a shipping address to be used for the transaction or a persona that the user may wish to engage in the transaction using.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method and system for facilitating the creation of a virtual wallet account that a financial institution may already have information in their records such as payment accounts, billing address, credit history reports of Purves et al. (‘393, col.3, lines 34-37) with teaching of Desai et al. for providing a secure and safe electronic business operations among users, payment facilities, and merchants through the use of dynamic authentication of each user (‘356, [0012]) for presenting a web page that may facilitate the creation of a reference account link that may designate multiple options including a shipping address as well (‘393, col.21, lines 15-17; col.21, lines 22-24).
27. As per claims 5 and 22:
Desai et al. discloses the following limitations:
wherein the unique identifier is provided from the user to the merchant through the second user interface after the user starts a checkout process at the merchant (Fig.41, items 4104, 4106; [0399] “A point of sale device 4104 may be activated by near-by presence of a mobile phone that incorporates a mobile wallet 4106 requesting to perform an electronic transaction such as a purchase. The POS device 4104 and mobile wallet 4106 may exchange non-personal information that describes the requested transaction (item, cost, date/time, POS identity, POS service provider identity, and the like) along with a unique identifier generated by the mobile wallet 4106…”)
28. As per claim 6:
Desai et al. discloses the following limitations:
receiving the unique identifier from the merchant based on the unique identifier being provided to the merchant from the user ([0399] “…The POS device and mobile wallet may exchange … with a unique identifier generated by the mobile wallet. The POS may issue a token that incorporates this information in a secure encoding to the mobile wallet and may also submit a version of the issued token to a payment authority, such as an issuing bank that may have been specified by the mobile wallet.”)
29. As per claim 7:
Desai et al. discloses the following limitations:
wherein the registered identifier comprises an email address that is registered for the user with the one or more of the multiple different issuers (Fig.31A, item 3102, 3112; [0366] “…the mobile wallet showing a registration & activation screen to the user that includes an email address and a personal identification number (PIN) at step 3102…”, [0367] “…the mobile wallet fetching a secure element ID (CIN), a device ID (IMEI), and a SIM ID (ICCID) from the mobile phone and sends the information (including E-mail ID, PIN and T&C version and a time stamp) to the wallet server at step 3112…”, [0376] “…The method 3400 may require the issuer to approve a payment account (for example, a credit card) at step 3402. The issuer may personalize the secure element with the help of the TSM at step 3404…”, [0508] “The payment facilitator 5400 may provide consumers a choice with multiple payment products across several issuers like issuers…”)
30. As per claim 8:
Desai et al. discloses the following limitations:
displaying, through the first user interface, a request for a phone number of the user ([0365] “… a wallet activation use case process may enable the user to activate the mobile wallet and establish secure linkages between user & ecosystem actors such as mobile wallet, mobile phone, mobile phone, secure element, wallet server, TSM, and wallet provider. In an example, the wallet activation use case actors like mobile handset, TSM, the user, the mobile wallet, the wallet provider, the wallet server. The wallet activation may take place only when the user may have successfully installed the mobile wallet on the mobile handset…”, [0366] “…The method 3100 includes the mobile wallet showing a registration & activation screen to the user that includes an email address and a personal identification number (PIN)…”)
receiving, through the first user interface, the phone number of the user ([0204] “…the identification parameter may include provider ID, type of the service product, a network provider type, and a correlation identity (e.g., a mobile number) …”, [0208] “…the system may include one or more attributes that may be stored in the form of a key value pair (e.g., contact number) and may be used to introduce any custom attributes to the service provider.”, Fig.31B, items 3124, 3128, 3130; [0368]-[0369] “…At step 3124, the mobile wallet may show a message to the user that wallet may be in process of being personalized for the user. At step 3128, the wallet server may send a request to TSM through ESB with user information (the mobile number, the SE ID, the device ID, the WALLET ID… the ESB configured for sending the information to TSM at step 3130…”)
31. As per claim 9:
Desai et al. discloses the following limitations:
wherein the authentication code is sent to the device of the user using the phone number based on the phone number of the user being registered for the user with the one or more of the multiple different issuers ([0363] “…the SMS may be sent by the user to the Telco or wallet provider, also referred to as an SMS push. In an alternative embodiment, the user may receive an SMS from telco or wallet provider, also referred to as an SMS pull. In an alternative embodiment, the user may initiate SMS from a Website…”, [0367] “…the mobile wallet fetching a secure element ID (CIN), a device ID (IMEI), and a SIM ID (ICCID) from the mobile phone and sends the information (including E-mail ID, PIN and T&C version and a time stamp) to the wallet server… The method may require mobile number and SIM information from Telco before proceeding further in wallet activation…”, [0118] “The ecosystem 600 may further include a plurality of issuers of transaction instruments 610. The issuer 610 may provide various transaction instruments such as a virtual credit card, a gift card, a loyalty card, tickets and the like. The user of the client 602 may select these instruments using one or more wallets and widgets to perform a transaction…”, [0233] “… In cases where hash verification is successful, the mClient may retrieve the widget descriptor for the selected widget from the secure element… The method 2000 may require the widget descriptor verification of the step 2020 for further execution of the widget…The mClient may communicate widget execution to the user and the mClient may prompt the user to exit the widget after execution…”)
32. As per claim 11:
Desai et al. discloses the following limitations:
displaying, through the first user interface, an opt out selector to enable the user to request deactivating the shared wallet of the user (Fig.35, items 3502, 3504, 3512, 3514, 3518, 3524, 3528; [0378] “…The method 3500 may require the wallet administrator to initiates a suspend wallet activity at step 3502. The wallet server may update the wallet state as “termination pending” at step 3504 after the suspension activity may be initiated. The wallet server may send a request to ESB at step 3508… The ESB may send request to the issuers to terminate the service accounts at step 3512 … The ESB may send a request to TSM to remove the wallet companion applet at step 3518…The TSM may send a notification to ESB once the update may be done at step 3524. The wallet server may receive the update and may change the wallet status to “terminated” at step 3528 of the method 3500. The wallet may be successfully terminated after step 3528.”)
33. As per claim 12:
Desai et al. discloses the following limitations:
displaying, through the first user interface for selection by the user, one or more phone numbers that are registered for multiple shared wallets based on the unique identifier being associated with the multiple shared wallets (Fig.30, items 3012, 3014; [0364] “…The wallet server may be further configured to for providing the wallet software to the mobile phone at step 3012 of the method 3000. The mobile phone may be configured for downloading the application on the mobile phone and prompting user for installation of the application at step 3014…”, [0367] “…The method may require mobile number and SIM information from Telco before proceeding further in wallet activation…”, [0522] “…the SDP 5508 architecture may include several SDPs 5508 and SDP wallets with such as a hierarchical parent child relationship among them. The SDPs 5508 may be configured to maintain a parent-child hierarchy with multiple wallets. Each of the applications such as mobile applications may be linked to an independent wallet instance…”, [0525] “…The wallet architecture may also provide wallet accessibility from multiple mobile applications such as from the multiple wallet views 5520. Also, during authentication, each wallet may be authenticated independently with such as independent passcodes and may be managed or activated or locked or suspended and the like independently while still providing a user with a consistent user experience…”)
receiving, through the first user interface, a selection from the user of one of the one or more phone numbers [0364] “…The wallet server may be further configured to for providing the wallet software to the mobile phone at step 3012 of the method 3000. The mobile phone may be configured for downloading the application on the mobile phone and prompting user for installation of the application at step 3014…”, [0367] “…if a mobile number may not be available from the SIM or device APIs, it may be captured from HTTP Header coming from the device if a Telco provides it. The method may require mobile number and SIM information from Telco before proceeding further in wallet activation…”)
the authentication code is sent to the device of the user using the one of the one or more phone numbers (Fig.30, item 3002; [0363] “FIG. 30 illustrates a flow chart describing a method 3000 of installing the mobile wallet on the mobile phone of the user using SMS with Download URL (Push or Pull). The method 3000 includes initiating the SMS by sending a SMS to a short code at step 3002. In an example, the SMS may be sent by the user to the Telco or wallet provider…”)
34. As per claim 13:
Desai et al. does not disclose, however, Purves et al., as shown, discloses the following limitations:
wherein the authentication code is verified before the list of the cards is displayed to the user (Col.14, lines 16-26 “The merchant server may receive the customer ID in the authorization response message, and query their database to confirm that the customer ID matches a customer record in their customer database. Upon verification or successful authentication, the merchant server may send an authentication response to the client. The authentication response, in one implementation, may be the requested web page that is rendered by the client and displayed to the user.”, col.19, lines 40-46 “The payment methods panel 1210 may list one or more payment methods 1210 a-d that are present in the wallet. The panel 1210 may display an image of the card (e.g., from the issuer), a nickname for the card, card identifier, card brand, and/or the like. The payment methods may also include bank or other financial accounts, debit cards, credit cards, prepaid cards, gift cards, and/or the like.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method and system for facilitating the creation of a virtual wallet account that a financial institution may already have information in their records such as payment accounts, billing address, credit history reports of Purves et al. (‘393, col.3, lines 34-37) with teaching of Desai et al. for providing a secure and safe electronic business operations among users, payment facilities, and merchants through the use of dynamic authentication of each user (‘356, [0012]) for receiving the customer ID in the authorization response message, and query their database to confirm that the customer ID matches a customer record in their customer database and then displaying images of the cards from the issuer that include the card details (‘393, col.14, lines 16-20; col.19, lines 40-43).
35. As per claim 14:
Desai et al. does not disclose, however, Purves et al., as shown, discloses the following limitations:
wherein the list of the cards displayed on the first user interface further comprises a respective card image associated with each of the cards (Fig.12, items 1210, 1210a, 1210b, 1210c, 1210d; col.19, lines 40-44 “The payment methods panel 1210 may list one or more payment methods 1210 a-d that are present in the wallet. The panel 1210 may display an image of the card (e.g., from the issuer), a nickname for the card, card identifier, card brand, and/or the like.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method and system for facilitating the creation of a virtual wallet account that a financial institution may already have information in their records such as payment accounts, billing address, credit history reports of Purves et al. (‘393, col.3, lines 34-37) with teaching of Desai et al. for providing a secure and safe electronic business operations among users, payment facilities, and merchants through the use of dynamic authentication of each user (‘356, [0012]) for displaying images of the cards that presented from the issuer, and each card details such as card identifier, card brand, and the like (‘393, col.19, lines 40-44).
36. As per claim 15:
Desai et al. does not disclose, however, Purves et al., as shown, discloses the following limitations:
after receiving the selection from the user of the selected card, displaying, to the user through the first user interface, a request for a card authentication code for the selected card (Col.24, lines 64-67 “FIG. 20a illustrates a lightbox window 2001 for linking payment accounts to a virtual wallet, creating a virtual wallet, and/or simultaneously creating a virtual wallet and linking payment accounts to the newly created wallet account.”, col.25, lines 51-53 “if a consumer chooses to create a pre-paid account they may be prompted to select a payment account from which to fund the pre-paid account.”, col.26, lines 53-56 “the user may be presented to a card management screen (e.g., from an issuer, merchant, and/or like source) that allows the user to select bank credit cards and/or debit cards to be used in the user's virtual wallet.”, col.27, lines 10-13 “the W-CONNECTOR, before submitting the card selections, may present the user with lightbox 2018, which may indicate which cards have been selected.”, col.27, lines 19-32 “only the accounts checked or otherwise selected by the user may be passed to the virtual server and added to the user's virtual wallet. Once the user has clicked the complete button, the bank issuer may package the information received from the user, and may send it to the W-CONNECTOR. The W-CONNECTOR may then send a request to a virtual wallet server, authenticating the user's account via the submitted login data, and requesting that the virtual wallet server associate the specified cards with the user's virtual wallet.)
receiving, through the first user interface, the card authentication code for the selected card (Figs.24b-c, items 2403 “…card addition”, 2404 “Security Questions”; col.42, lines 58-60 “the wallet and card enrollment may occur on a normal web interface, a mobile web interface, a voice-controlled interface, and/or other interfaces”, col/line 42/67-43/5 “the user may be presented a number of options in enrolling in the wallet service 2403 (including an express enrollment or card addition option, a standard enrollment or card addition option, and/or the like)”. The user may then be presented with wallet-implemented overlays 2404”)
verifying the card authentication code for the selected card before providing the card information for the selected card to the merchant for processing the transaction (Figs.24i-j, items 2412, 2413, 2414; col.43, lines 29-33 “the issuer may request that the user provide a set of security questions and answers 2412, as well as security codes 2413. The issuer may provide the user with a confirmation screen 2414 once the process has been completed.”, fig.25, items 2503, 2505, 2535; col.43, lines 44-48 “a consumer may request his bank issuer 2505 to update, through the W-CONNECTOR, the newly issued credit card number with all merchants 2535 on the W-CONNECTOR consumer profile.”, fig.26, item 2605; col.43, lines 65-66 “The user may provide payment methods 2605 and choose default payment method to use for purchases.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method and system for facilitating the creation of a virtual wallet account that a financial institution may already have information in their records such as payment accounts, billing address, credit history reports of Purves et al. (‘393, col.3, lines 34-37) with teaching of Desai et al. for providing a secure and safe electronic business operations among users, payment facilities, and merchants through the use of dynamic authentication of each user (‘356, [0012]) for presenting the user to a card management screen that allows the user to select bank credit cards and/or debit cards to be used in the user's virtual wallet, presenting the user to card addition option that includes verification such as answering to security questions, providing by the user answers to a set of security questions and as well as security codes, that resulted in a confirmation once the process has been completed, and the user directed to marketplace for purchasing goods (‘393, col.26, lines 53-56; col.42, lines 58-60; col.43, lines 29-33, col.43, lines 65-66).
37. As per claim 16:
Desai et al. discloses the following limitations:
wherein the card information for the selected card comprises a token cryptogram for processing the transaction ([0386] “…The tokenization capability may take private information and replace it with a token. The private information may include a pin number, a credit card number, primary account number, other personally identifiable information, and the like. The token may consistent of numeric characters, alphabetic characters, a combination of alphabetical and numeric characters, a truncated primary account number with alphabetic and numeric characters replacing the middle digits of the primary account number…The token may be a one-time use token. The token may be issued by a trusted entity in the dynamic ecosystem for secure commerce and payment transactions…”, [0400] “…The transaction information of the token received from the POS terminal and from the issuing bank may be compared and presented to the user of the mobile device for authentication. In this way the transaction may be executed without requiring the POS…”)
38. As per claim 17:
Desai et al. discloses the following limitations:
receiving a request from the user to add a new card to the shared wallet ([0225] “…the widget download and installation may be triggered due to various events. The events may include a new card provisioning event by the issuer.”, [0376] “…The method may require the issuer to approve a payment account (for example, a credit card). The issuer may personalize the secure element with the help of the TSM … the TSM may install the payment applet and may personalize with the track data. The card issuance use case may depend upon the payment card and the applet issuance on the SE & the type of applet …card data may contain images, balance, card nick name, and AID to be used for transaction.”, [0510] “…Each of the wallets may be configured to hold a subset of a consumer's transacting instruments. In accordance with various embodiments, the wallet may securely store and protect consumer payment account information, organizing and managing lifecycle of consumer payment accounts, implement strong authentication as required to access the accounts, provide options for selection of a specific account for a transaction…”)
39. As per claim 18:
Desai et al. discloses the following limitations:
displaying to the user a deep link for an issuer of at least one of the cards in the shared wallet ([0362] “…the widget download may be in form of a SMS with Download URL (Push or Pull) use case. In an example, the SMS with Download URL (Push or Pull) use case may allow wallet provider to distribute application over the air using SMS push/pull without publishing the application on the application store…”, [0364] “The method … includes receiving the URL with a welcome text by the user… The user may select the URL provided in the SMS. The completion … may be dependent on URL descriptor and welcome message. The method … includes the mobile phone sending the request to wallet server to provide the downloadable file … The wallet server may be further configured to for providing the wallet software to the mobile phone…The mobile phone may be configured for downloading the application on the mobile phone and prompting user for installation of the application…[0375] “…For the card issuance to take place, the user may have to activate the mobile wallet, the user may have to log in to the mobile wallet, the service provider may have to create an updated widget…”, [0462]-[0463] “…system may receive a hyperlink as user input associated with a desired ecosystem configuration…the hyperlink may be a link to a website of a service provider operating the wizard.”)
40. Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over US20170140356A1 to Desai et al. in view of US9355393B2 to Purves et al. and US20170278089A1 to Kothari et al.
41. As per claim 10:
Neither Desai et al., nor Purves et al. disclose, however, Kothari et al., as shown, discloses the following limitations:
displaying, through the first user interface for selection by the user, one or more other phone numbers that are registered for the user (Fig.3, item 302; [0037] “…Step 302 includes displaying, to a user, a collection of one or more user device identifiers. The user device identifiers can include, for example, one or more telephone numbers…) with the multiple different issuers based on the phone number of the user not being registered for the user with one or more of the multiple different issuers ([0013] “…implementing a mobile-friendly payment scheme that works across multiple banks without the requirement of an additional identifier…”, [0023] “the gateway provides an option of checking out using a mobile number … Upon selecting… the option, the user is presented with a list of possible bank accounts identified by names chosen by the user…”, [0034] “…a set of online retailers using such a feature through the gateway can be referred to as participating retailers. As such, a participating retailer can allow customers to choose one or more mobile numbers in a related customer profile to utilize for mobile money checkout purposes…”, [claim 3] “wherein the collection of one or more user device identifiers is stored in a user profile arising from one of a set of multiple merchants”
receiving, through the first user interface, a selection from the user of one of the one or more other phone numbers ([0014] “…enabling a user (for example, via a participating retailer) to identify one of the user's (mobile) phone numbers to be used in connection with checkouts and payments…”, [0025] “…after the user 102 chooses to pay using a mobile money checkout option and selects a particular bank and account number with which to carry out that mobile money transaction…”, fig.3, item 304; [0038] “Step 304 includes verifying that a user-selected one of the user device identifiers is linked to a user device that is in the possession of the user…”)
the authentication code is sent to the device of the user using the one of the one or more other phone numbers ([0014] “…A verification technique can subsequently be implemented (for example, via the retailer) to verify that the phone is indeed in the possession of the user. By way of example, the verification technique can include challenging the user to provide a one-time password sent to the (mobile) phone number.”, [0017] “…such a verification process can be performed by the merchant 104 sending a challenge code to the user's phone, and thereafter the user 102 responding to the merchant 104 with the provided challenge code to verify possession of the user's phone.”, [0038] “…verifying can include (i) sending a one-time password to the user device linked to the user-selected user device identifier and (ii) querying the user to return the one-time password.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method and system for facilitating the creation of a virtual wallet account that a financial institution may already have information in their records such as payment accounts, billing address, credit history reports of Purves et al. (‘393, col.3, lines 34-37) and a method for presenting to a user, a collection of one or more stored user device identifiers, and verifying that a user-selected one of the user device identifiers is linked to a user device that is in the possession of the user of Kothari et al.(‘089, [0005]) with teaching of Desai et al. for providing a secure and safe electronic business operations among users, payment facilities, and merchants through the use of dynamic authentication of each user (‘356, [0012]) for displaying a collection of one or more user device identifiers that include one or more telephone numbers, enabling a user to identify one of the user's phone numbers to be used in connection with checkouts and payments, and performing a verification by sending a challenge code to the user's phone, and thereafter the user responding with the provided challenge code to verify possession of the user's phone (‘393, [0014], [0017], [0037]).
Conclusion
42. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US20210042726A1 – Purves et al. – Discloses the system that facilitates the enrollment of payment accounts in a consumer's virtual wallet, wherein the consumer may be logged into their payment account issuer's web site and designate one or more payment accounts for enrollment in a virtual wallet.
US20200065800A1 – Kusnanto et al. – Discloses a system and method for allowing a contact such as a mobile phone number to be associated with a specific mobile wallet account and by submitting a mobile phone number to an ecommerce site, a URL will be communicated to the contact which opens the payment wallet with the relevant information from the ecommerce transaction.
US20160078428A1 – Moser et al. – Discloses a system and method for facilitating use of a digital electronic wallet by a cardholder for cashless transactions, wherein the method comprises receiving a selection by a first cardholder to pair a first digital wallet held by a first wallet holder with a first merchant, the first digital wallet having therein an electronic representation of at least one payment device usable to fund a cashless transaction, and verifying the cardholder's identity.
US20210272101A1 – Kalgi – Discloses the electronic wallet checkout platform (EWCP) to transform customer purchase requests triggering electronic wallet applications via EWCP components into electronic purchase confirmation and receipts.
US20200349536A1 – Hertel et al. – Discloses a system and method of a unified and integrated configuration that is composed of a payment system, an advertising system, and an identity management system such that the unified system has all of the benefits of the individual systems as well as several additional synergistic benefits.
43. Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMANULLA ABDULLAEV whose telephone number is (571)272-4367. The examiner can normally be reached Monday-Friday 9:30AM -4:30PM ET.
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, Ryan D Donlon can be reached at 571-270-3602. 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.
/AMANULLA ABDULLAEV/Examiner, Art Unit 3692
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692