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 .
Status of the Claims
2. Applicant filed the amendment on 06/16/2026. Claims 1, 3, and 5-22 are pending. Claims 1 and 19-20 are amended.
Claim Rejections - 35 USC §101
3. 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.
4. 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.
5. 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”.
6. Claim 1 recites “processing a transaction using a shared payment instrument”. Specifically, claim 1 recites (abstract ideas emphasized in bold) “enrolling, by a system, a merchant for the system to provide wallet services to the merchant;
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;
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 during an online checkout process at 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, 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 launched by the merchant after the merchant displays the second user interface to the user;
verifying the authentication code;
determining, by the system, a shared wallet of the user in a wallet directory stored by the system based on the unique identifier of the user matching a registered identifier of the user that is associated with the shared wallet in the wallet directory, wherein the shared wallet is pre-populated, on an opt-out basis, before the merchant first offers the user an opportunity to use the wallet services, 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;
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;
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, wherein the card information is provided from the system to the merchant to populate one or more checkout pages of the second user interface with an indication of the selected card.” 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)).
7. 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”, “an online checkout process”, “a device of the user”, “a shared wallet”, “the shared wallet is pre-populated, on an opt-out basis”, 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”, “…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…”, 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)).
8. 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)).
9. Hence, claim 1 is not patent eligible.
10. 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)).
11. 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”, “an online checkout process”, “a device of the user”, “a shared wallet”, “the shared wallet is pre-populated, on an opt-out basis”, 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”, “…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…”, 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. The following dependent claims recent additional elements not addressed above:
claim 3 recites “one or more checkout pages”;
claim 7 recites “an email address”;
claim 11 recites “an opt out selector”;
claim 12 recites “multiple shared wallets”;
claim 16 recites “a token cryptogram”; and
claim 18 recites “a deep link”.
When considered individually, and as a whole, each of these additional elements amount to merely "apply it", as they are merely applying the abstract idea to the technical environment of the one or more checkout pages, the email address, the opt out selector, the multiple shared wallets, the token cryptogram, and the deep link.
19. Dependent claims 3, 5-18, and 21-22 merely expand upon the abstract ideas of the independent claims and are therefore rejected under the same rationale as claims 1 and 19 respectively.
Conclusion of 35 USC §101
20. 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.
21. 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
22. 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.
23. 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.
24. 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.
25. Claims 1, 3, 5-22 are rejected under 35 U.S.C. 103 as being unpatentable over US20170140356A1 to Desai et al. in view of US20170278089A1 to Kothari et al. and US9355393B2 to Purves et al.
26. As per claim 1:
Desai et al. discloses the following limitations:
A computer-implemented method comprising: ([0077] “A multi-domain ecosystem may be configured for secure personalized transactions via a multi-tiered secure mobile transactions enabling platform that may comprise an enabling tier, a service tier, a personalization tier, an expert tier, and an experience framework tier…”)
enrolling, by a system, a merchant for the system to provide wallet services to the merchant ([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.).”, [0190] “…In an example, at 1512, the service provider may enroll with the MTP server for providing one or more services to the end users…”, [0545] “…The SDP may aggregate and allow for the on boarding of multiple issuers 5610-5614, and may allow the merchants to define their payment facilitator compatible payment products and other value added services (VAS)…”)
providing, by the system, a software development kit (SDK) to the merchant ([0172] “… In an example, the MTP may offer a comprehensive Software Development Kit (SDK) to the service providers. The SDK may allow the service providers to quickly build their widgets for all MTP handsets without having to write phone-specific code…”, [0545] “…In an embodiment, the merchants may have an ability to create widgets using the MTP toolkit that may be specifically designed to provide a merchant centric user experience at the POS 5602. The widget creation may be at the merchant’s discretion and may be implemented or added at any time…”), wherein the SDK is configured to launch a first user interface that interfaces with the system to provide the wallet services ([0547] “…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…”, [0533] “…The mobile application may connect to the SDP 5508 to validate login and authenticate consumer and device…”)
receiving, by the system and through the first user interface displayed to the user, the authentication code ([0533] “…The consumer may then launch a mobile application on the mobile phone and may be required to enter login credential (for example, PIN, password, or passphrase and the like). The mobile application may connect to the SDP 5508 to validate login and authenticate consumer and device…”),
determining, by the system, a shared wallet of the user in a wallet directory stored by the system based on the unique identifier of the user matching a registered identifier of the user that is associated with the shared wallet in the wallet directory ([0204] “…The MTP may get the service product from the master records based on the identification parameters. In an example, 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), and the like. The platform may fetch wallet account information using the correlation identity…”), wherein the shared wallet is pre-populated, on an opt-out basis, before the merchant first offers the user an opportunity to use the wallet services, with cards issued to the user from multiple different issuers ([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…”, [0545] “…The wallet may get automatically populated from the SDP as consumers create their payment facilitator wallet… The SDP may aggregate and allow for the on boarding of multiple issuers 5610-5614…”, [0511] “…However, in some other cases such as merchant issued cards (e.g. gift cards), the payment accounts may be added automatically.”), 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 ([0207] “…In an example, the service account reference number can be a unique identifier shared by issuer system which may act as the correlation id within wallet platform and issuer system…”, [0204] “…a correlation identity (e.g., a mobile number)…”)
[after verifying] … wherein the shared wallet is accessible to multiple different merchants ([0543] “…In an example, multiple issuers 5610-5614 may be supported with diverse payment products and multiple POS 5602 channels giving consumers a choice of payment options that may fit their needs across multiple merchants…”, [0525] “…The wallet architecture may also enable a configurable rule-based filtering for filtering the reference stores 5514 for each child wallet thereby allowing a merchant to have an allowed subset of all the user’s payment cards…”)
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 [0533] “…The consumer may be required to choose a payment option (for example, a gift card) from the list provided to the consumer.”, [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…”)
sending by the system, card information for the selected card to the merchant to enable the merchant to process the transaction ([0534] “…The mobile application may send the data along with selected card OTA to SDP 5508. The SDP 5508 may request token, and send the token along with other information to POS through a back-end process.”, [0548] “…The SDP may transfer a transaction payload formatted for the merchant POS 5602…”, [0535] “… The payment facilitator may route the transaction to the issuer of the payment card at a next step. The issuer may authorize the transaction and approval may be delivered to the POS at a next step…”)
Desai et al. does not disclose, however, Kothari et al., as shown, discloses the following limitations:
obtaining, by the system and from the merchant, a unique identifier of a user ([0018] “…in the redirect from the merchant checkout 106 to the payment gateway 108, any phone number registered for mobile money (such as the user's mobile phone number) is included…”, [0033] “…such an embodiment includes using an assertion of a validated phone number from the merchant for identifying the user at the gateway and/or wallet service…”), wherein the unique identifier is provided from the user to the merchant through a second user interface displayed to the user during an online checkout process at the merchant ([0034] “…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…”, [0032] “…utilizing an association of a customer’s/user’s mobile phone number with one or more payment account numbers, and using the association to initiate checkouts via the user providing a mobile number at a merchant and/or gateway…”, [0018] “…the user 102 (via the user's mobile phone, for example) initiates the payment process (for example, by clicking a “pay” button on the merchant’s online checkout 106)…”)
sending, from the system, an authentication code to a device of the user ([0038] “… Also, 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.”, [0034] “…Such verification can be carried out, for example, by sending a one-time password (OTP) challenge to the device.”, [0014] “…the verification technique can include challenging the user to provide a one-time password sent to the (mobile) phone number.”)
verifying the authentication code ([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…”, [0017] “…the user 102 responding to the merchant 104 with the provided challenge code to verify possession of the user's phone.”)
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 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 the 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 obtaining the mobile phone number as the user’s identifier from the merchant while initiated a payment process, sending a one-time password (authentication code) to the user device linked to the user-selected user device identifier, and providing a challenge code to verify possession of the user’s phone (‘089, [0017], [0018], [0032]-[0034], [0038]).
Neither Desai et al. nor Kothari et al. disclose, however, Purvey et al., as shown, discloses the following limitations:
[receiving] … wherein the SDK is run by the merchant to launch the first user interface that interfaces with the system (col.23, lines 33-37 “The merchant web server then replies to client 1806 with a checkout page response 1804. The checkout page response 1804 is embedded with code that causes client to initiate a second request to a wallet server”, col.12, lines 28-32 “In one implementation, the customer sign in may be a trigger for the merchant to make an API/JAVASCRIPT call 855 to the wallet service 850 to obtain shipping details 825 b, payment method 825 c, and/or the like”), and the first user interface is launched by the merchant after the merchant displays the second user interface to the user (col.24, lines 12-16 “Client 1806 then renders the lightbox 1825. In some embodiments, the lightbox appears overlaid on the merchant’s web site. In other embodiments, the lightbox appears in a different window”, col/line 55/64-56/2 “In some embodiments, for the tablet checkout, the checkout widget should be displayed as a lightbox overlay on top of the merchant checkout. So both in portrait and landscape views, the lightbox should be overlain over the merchant’s site. The background should be greyed out in order to call attention to the checkout lightbox.”)
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 (col.55, lines 27-33 “When: the Wallet checkout lightbox is loaded. And: the consumer has either signed up or logged in successfully. Then: the consumer can click from the review page to the Payment Method page to select or make changes to their wallet. And: the consumer can add additional credit cards to their wallet from the Payment Method page.”; col.56, lines 62-65 “A visual call-out may be displayed to the consumer for cards that are expired in their wallet. The expired card may be greyed-out/disabled from being selectable.”)
[sending by the system] …wherein the card information is provided from the system to the merchant to populate one or more checkout pages of the second user interface with an indication of the selected card (col.12, lines 28-34 “In one implementation, the customer sign in may be a trigger for the merchant to make an API/JAVASCRIPT call 855 to the wallet service 850 to obtain shipping details 825 b, payment method 825 c, and/or the like. The merchant site page 825 may use the shipping detail obtained from the wallet to calculate and display shipping and tax information”, col.10, lines 60-67 “the merchant may obtain payment methods 530 a and 530 b from W-CONNECTOR and display them using their nicknames such as “My Business Credit Card PaymentCard Ending . . . 1234” (e.g., 530 a) and “My Personal Debit Card PaymentCard Ending . . . 1234” (e.g., 530 b). In this way, via API calls, the merchant may display rich, up to date account information including card art.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate to incorporate 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]) and a method 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 the 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 embedding by the merchant’s web server the code and launching the wallet lightbox that communicates with the wallet server, presenting the Payment Method page listing the cards in the user’s wallet and displaying populated with the indication of the card of the merchant’s checkout pages with an indication of the selected card (‘393, col.10, lines 60-67, col.23, lines 33-37, col/line 55/64-56/2, col.56, lines 62-65).
Claims 19 and 20 are rejected using the same rationale that was used for the rejection of claim 1.
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”)
27. As per claim 3:
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…”)
Neither Desai et al. nor Kothari et al. disclose, however, Purvey 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 to incorporate 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]) and a method 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 the 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).
Claim 21 is rejected using the same rationale that was used for the rejection of claim 3.
28. As per claim 5:
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…”)
Claim 22 is rejected using the same rationale that was used for the rejection of claim 5.
29. 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.”)
30. 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…”)
31. 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…”)
32. 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…”)
33. 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 to incorporate 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]) and a method 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 the 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 (‘089, [0014], [0017], [0037]).
34. 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.”)
35. 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…”)
36. As per claim 13:
Neither Desai et al. nor Kothari et al. disclose, however, Purvey 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 to incorporate 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]) and a method 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 the 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).
37. As per claim 14:
Neither Desai et al. nor Kothari et al. disclose, however, Purvey 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 to incorporate 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]) and a method 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 the 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).
38. As per claim 15:
Neither Desai et al. nor Kothari et al. disclose, however, Purvey 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 to incorporate 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]) and a method 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 the 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).
39. 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…”)
40. 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…”)
41. 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.”)
Response to Arguments
42. After careful consideration of applicant arguments, the examiner finds them to be not persuasive. Claims 1, 3, and 5-22 are rejected.
Rejection under 35 USC § 101
43. 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.
44. 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”. Applicant states that “amended independent claim 1 recites significant additional elements above and beyond what the Office Action identifies as the abstract idea” and lists amended claim 1 limitations.
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.
45. Applicant is of the opinion that “[the] amended claims recite a specific technical architecture that integrates the idea into a practical application, analogous to the claims found eligible in USPTO Example 37 (Relocation of Icons on GUI) and in DDR Holdings, LLC V. Hotels.com, L.P., 773 F.3d 1245 (Fed. Cir. 2014). In Example 37, the USPTO found that a claim reciting a method of rearranging icons on a GUI was eligible because the additional elements recited ‘a specific manner of automatically displaying icons to the user based on usage which provides a specific improvement over prior systems, resulting in an improved user interface for electronic devices.’ Similarly, as amended, claim 1 recites a specific manner of displaying checkout information to a user through a coordinated dual- user-interface architecture, not merely the abstract idea of processing a transaction.”
Examiner respectfully disagrees.
Unlike DDR, where the click of a hyperlink would cause an e-commerce website to lose a customer to a rival e-commerce website, there is no such business or technical problem confronting the user. Applicant’s invention does not set out to solve any specific business or technological challenges comparable to that in DDR. There is no risk of losing business to a rival because of a mouse click. The claimed invention does not involve internet browsing and its associated challenges. Nor do the claims describe any technical solutions to any problem. Providing a user interface for online checkout using a shared wallet across issuers is not comparable to navigating a merchant website. Hence, the DDR analogy does not apply here.
According to Example 37 claim 1 - the additional elements recite a specific manner of automatically displaying icons to the user based on usage which provides a specific improvement over prior systems, resulting in an improved user interface for electronic devices, and thus integrated into a practical application, and background of Example 37 states “rearranging icons on a graphical user interface (GUI), wherein the method moves the most used icons to a position on the GUI, specifically, closest to the ‘start’ icon of the computer system, based on a determined amount of use”. In current application, “automatically moving the most used payment instrument into the checkout system” would be similar to Example 37, but not “a specific manner of displaying checkout information”.
46. Applicant is of the opinion “that the ordered combination of limitations of 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 of 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”; (Specification, ¶ 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 not patent eligible.
Rejection under 35 USC § 103
47. Applicant is of the opinion that the prior art references Desai et al. in combination of Purves et al. and Kothari et al. do not teach or suggest every limitation of amended claims 1, 3, and 5-22.
Examiner respectfully disagrees.
Combined prior art references Desai et al., Kothari et al. and Purves et al. teach all amended claims 1, 19, and 20 limitations in revised mapping disclosure.
Conclusion
48. 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.
US20180189756A1 – Purves et al. – Discloses the MULTI-DIRECTIONAL WALLET CONNECTOR APPARATUSES, METHODS AND SYSTEMS (“W-CONNECTOR”) facilitates the enrollment of payment accounts in a consumer's virtual wallet. 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.
49. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
50. 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 /DAVID P SHARVIN/Primary Examiner, Art Unit 3692
