DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
• This action is in reply to the amendments filed on February 6, 2026.
• Claims 1, 6-8, 11, 16-18, and 20 have been amended and are hereby entered.
• Claims 1-20 are currently pending and have been examined.
• This action is made FINAL.
Response to Arguments
Applicant’s arguments filed February 6, 2026 have been fully considered but they are not persuasive.
The Examiner is withdrawing the 35 USC § 112 rejections due to Applicant’s amendments.
Applicant’s arguments with respect to 35 USC § 103 have been fully considered and are not persuasive.
Regarding Applicant’s argument on pages 12-13, that the cited art of record does not teach OAuth tokens, the argument has been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Regarding Applicant’s arguments on pages 12-13, that the cited art of record does not teach “providing, in response to authenticating the credential, a graphical authorization interface prompting for an indication of consent to provide access to information regarding one or more accounts corresponding to the particular profile,” the argument has been considered and is not persuasive. As discussed in the 103 rejection below, Purves teaches “in response to authenticating the credential, provide to the first system a graphical authorization interface prompting for an indication of consent to provide access to information regarding one or more accounts corresponding to the particular profile” at least at FIG. 7a-7b, and col. 12, lines 30-52, describing and depicting a login process where a user enters a username and password to login to the wallet account, and describing depicting a V.me interface which allows a user to select which cards and addresses to connect to the account. The cited art of record therefore teaches this limitation.
Regarding Applicant’s arguments on pages 12-13, that the cited art of record does not teach “a separate authorization or consent interface presented after authentication,” the argument has been considered and is not persuasive. As discussed in the 103 rejection below, Purves teaches this limitation at least at FIG. 7a-7b, and col. 12, lines 30-52, describing and depicting a login process where a user enters a username and password to login to the wallet account, and describing depicting a V.me interface which allows a user to select which cards and addresses to connect to the account. The cited art of record therefore teaches this limitation.
Regarding Applicant’s arguments on pages 12-13, that the cited art of record does not teach “obtaining an explicit user indication of consent to grant access to account information,” the argument has been considered and is not persuasive. As discussed in the 103 rejection below, Purves teaches the limitation of “receiving the indication of consent” at least at col. 15, line 44 to col. 16, line 37 and FIG. 9a, steps 934-936, describing the information consented to be shared (e.g., user information including card details including card nickname, card brand, last 4 digits of the card, and the user information details ) being sent to the client device, see at least col. 15, line 44 to col. 16, line 37 and FIG. 9a, steps 934-936, depicting user information sent to the client device. The cited art of record therefore teaches this limitation.
Regarding Applicant’s arguments on pages 12-13, that Purves is directed to a fundamentally different technical problem, the argument has been considered and is not persuasive. The Examiner respectfully contends that Purves’ disclosure pertaining to a digital wallet does not wholly disqualify all possible combinations with references disclosing the claimed method. It is noted that "[t]he use of patents as references is not limited to what the patentees describe as their own inventions or to the problems with which they are concerned. They are part of the literature of the art, relevant for all they contain.” In re Heck, 699 F.2d 1331, 1332-33, 216 USPQ 1038, 1039 (Fed. Cir. 1983) (quoting In re Lemelson, 397 F.2d 1006, 1009, 158 USPQ 275, 277 (CCPA 1968))." MPEP §2123.
Applicant’s arguments with respect to 35 USC § 101 have been fully considered and are not persuasive.
Regarding Applicant’s argument on pages 13-15, that the claims are integrated into a practical application, the Examiner respectfully disagrees. Under the Patent Subject Matter Eligibility analysis, Step 2A, prong two, integration into a practical application requires an additional element(s) or a combination of additional elements in the claim to apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the exception. Limitations that are not indicative of integration into a practical application are those that generally link the use of the judicial exception into a particular technological environment or field of use-see MPEP 2106.05(h). Here the claims recite a transfer processing computer system comprising: a communications module; one or more processors coupled to the communications module; and a memory coupled to the one or more processors and storing instructions; a non-transitory computer-readable storage medium comprising processor-executable instructions; a first system executing a first software application; a graphical authentication interface; a second system executing a second software application; and an OAuth token such that they amount to no more than generally linking the use of the judicial exception to a particular technological environment or field of use (e.g., a computer network) (see MPEP 2106.05(h)).
Furthermore, and in response to Applicant’s arguments on page 13-15, where Applicant argues that the claims improve technology, in determining whether a claim integrates a judicial exception into a practical application, a determination is made of whether the claimed invention pertains to an improvement in the functioning of the computer itself or any other technology or technical field (i.e., a technological solution to a technological problem). Here, the claims recite generic computer components, i.e., a generic processor, a memory storing a computer program executable by the processor to perform the claimed method steps and system functions. The processor, memory and system are recited at a high level of generality and are recited as performing generic computer functions customarily used in computer applications.
Furthermore, the Specification describes a problem and improvement to a business or commercial process at least at [0002]-[0004], describing improving authentication frameworks. The Examiner notes that improving security of a financial transaction describes an improvement to a business or commercial process, not an improvement in the functioning of the computer itself or any other technology or technical field.
Regarding Applicant’s arguments on page 15, that the claims apply the judicial exception in a meaningful way beyond the generally linking use of the exception to a particular technology such that the claims are more than a drafting exercise aimed at monopolizing the exception, the argument has been considered and is not persuasive. Applicants contend that the claims do not seek to preempt or monopolize a fundamental economic practice. “While preemption may signal patent ineligible subject matter, the absence of complete preemption does not demonstrate patent eligibility.” Ariosa Diagnostics, Inc. v. Sequenom, Inc., 788 F.3d 1371, 1379 (Fed. Cir. 2015). The instant application is reviewed within the framework of the Revised Guidance which specifies and particularizes the Mayo/Alice framework.
Furthermore regarding this argument, the Examiner notes that the limitations are directed to an abstract idea and when determining if the claims are directed to significantly more, the additional limitations of the claims in addition to the abstract idea are analyzed In the claims of the instant application, the additional elements of the claim include a transfer processing computer system comprising: a communications module; one or more processors coupled to the communications module; and a memory coupled to the one or more processors and storing instructions; a non-transitory computer-readable storage medium comprising processor-executable instructions; a first system executing a first software application; a graphical authentication interface; a second system executing a second software application; and an OAuth token. For example, computer system is recited as performing the steps of receiving a request, providing a user interface, authenticating a credential, identifying accounts associated with the credential, transmitting an access token, receiving a request for configuring a payment in an e-commerce checkout, executing authentication, authenticating credentials, and obtaining consent to perform the transaction. These are merely generic computer components performing customary and generic steps. The Applicant fails to demonstrate, and the Specification fails to show, how these steps are unconventional steps that confine the claims to a particular useful application
Regarding Applicant’s arguments on pages 15-16, that the additional elements of the claims amount to significantly more than the abstract idea, the Examiner respectfully disagrees. The limitations are directed to an abstract idea and when determining if the claims are directed to significantly more, the additional limitations of the claims in addition to the abstract idea are analyzed. In the instant application, the additional elements of the claim include a transfer processing computer system comprising: a communications module; one or more processors coupled to the communications module; and a memory coupled to the one or more processors and storing instructions; a non-transitory computer-readable storage medium comprising processor-executable instructions; a first system executing a first software application; a graphical authentication interface; a second system executing a second software application; and an OAuth token. The additional limitations, when considered both individually and in combination, do not affect an improvement to another technology or technological field; the claims do not amount to an improvement to the functioning of the computer itself; and the claims do not move beyond a general link of use of an abstract idea to a particular technological environment. Therefore, the claims merely amount to merely generally linking the use of the abstract idea to a particular technological environment or field of use (e.g., a computer network), and is considered to amount to nothing more than requiring a generic computer network to carry out the abstract idea itself. The specifics about the abstract idea do not overcome the rejection.
Regarding Applicant’s arguments on page 16, that the claims cannot be characterized as “well-understood, routine, conventional activity in the field,” the Examiner respectfully disagrees. In the claims of the instant application, the additional elements of the claim include a transfer processing computer system comprising: a communications module; one or more processors coupled to the communications module; and a memory coupled to the one or more processors and storing instructions; a non-transitory computer-readable storage medium comprising processor-executable instructions; a first system executing a first software application; a graphical authentication interface; a second system executing a second software application; and an OAuth token. For example, computer system is recited as performing the steps of receiving a request, providing a user interface, authenticating a credential, identifying accounts associated with the credential, transmitting an access token, receiving a request for configuring a payment in an e-commerce checkout, executing authentication, authenticating credentials, and obtaining consent to perform the transaction. These are merely generic computer components performing customary and generic steps that implement the abstract idea of authenticating a user for a transaction, and obtaining consent to perform the transaction. Therefore, the claims merely amount to the application or instructions to apply the abstract idea (i.e., authenticating a user for a transaction, and obtaining consent to perform the transaction) using a generally linked computer network, and is considered to amount to nothing more than requiring a generic computer merely to carry out the abstract idea itself. The specifics about the abstract idea do not overcome the rejection.
Applicant further argues that the Office must provide factual evidence to a determination that the combination of features are well-understood, routine, or conventional. In response to this argument, the Examiner respectfully points out that the additional elements amount to mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea.-see MPEP 2106.05(f). This consideration is different than the Well Understood, Routine, and Conventional Consideration –See MPEP 2106.05(d).
The claims are not patent eligible.
For the reasons above, Applicant’s arguments are not persuasive.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention recites an abstract idea without significantly more. Independent claims 1, 11, and 20 are directed to a system (claim 1), a method (claim 11), and an apparatus (claim 20). Therefore, on its face, each independent claim 1, 11, and 20 are directed to a statutory category of invention under Step 1 of the Patent Subject Matter Eligibility analysis (see MPEP 2106.03).
Under Step 2A, Prong One of the Patent Subject Matter Eligibility analysis (see MPEP 2106.04), claims 1, 11, and 20 recite, in part, a system, a method, and an apparatus of organizing human activity. Using the limitations of claim 1 to illustrate, the recites receive a first request, the first request triggered and representing a data sharing request; in response to receiving the first request, execute an authentication module; wherein executing the authentication module configures the authentication module to: provide prompting for input of a credential and in response receive input indicating the credential; authenticate the credential as being associated with a particular profile; in response to authenticating the credential, provide prompting for an indication of consent to provide access to information regarding one or more accounts corresponding to the particular profile; and in response to receiving input including the indication of consent, automatically issue and transmit a token for accessing the information regarding the one or more accounts; receive a second request, the second request triggered and representing a request for configuring a payment in an e-commerce checkout; and in response to receiving the second request, execute the authentication module, wherein executing the authentication module configures the authentication module to: authenticate a credential received as being associated with the particular profile; identify one or more accounts to be used in fulfilling an associated request, the one or more accounts corresponding to the particular profile; and obtain an indication of consent to perform an operation associated with the associated request.
The limitations, as drafted, is a process that, under its broadest reasonable interpretation, covers commercial and legal interactions (certain methods of organizing human activity), but for the recitation of generic computer components. The claims as a whole recite a method of organizing human activity. The claimed inventions allows for receiving a request for transaction, authenticating a user for a transaction, and obtaining consent to perform the transaction, which is a fundamental economic principle or practice of mitigating risk and a commercial and legal interaction of sales activities or behaviors. The mere nominal recitation of a communications module; one or more processors coupled to the communications module; and a memory coupled to the one or more processors and storing instructions do not take the claim out of the methods of organizing human activity grouping. Thus, the claims recite an abstract idea.
Under Step 2A, Prong Two of the Patent Subject Matter Eligibility analysis (see MPEP 2106.04), the judicial exception is not integrated into a practical application. In particular, the additional elements of a transfer processing computer system comprising: a communications module; one or more processors coupled to the communications module; and a memory coupled to the one or more processors and storing instructions; a non-transitory computer-readable storage medium comprising processor-executable instructions; a first system executing a first software application; a graphical authentication interface; a second system executing a second software application; an OAuth token are recited at a high-level of generality (i.e., as a generic computer components performing generic computer functions of receiving requests, executing authentication, authenticating a credential, identifying accounts to be used, and obtaining indication of consent to perform a transaction) such that it amounts to no more than generally linking the use of the judicial exception to a particular technological environment or field of use (e.g., a computer network).-see MPEP 2106.05(h).
Accordingly, the combination of the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
Under Step 2B of the Patent Subject Matter Eligibility analysis (see MPEP 2106.05), the claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements in the claims amount to no more than generally linking the use of the judicial exception to a particular technological environment or field of use (see MPEP 2106.05(h)). Generally linking the use of the judicial exception to a particular technological environment or field of use using generic computer components cannot provide an inventive concept.
The claims are not patent eligible.
The dependent claims have been given the full two part analysis including analyzing the additional limitations both individually and in combination. The dependent claim(s) when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. Dependent 2, 6-8, 12, and 16-18 simply further describes the technological environment. Dependent claims 3-6, 9-10, 13-16, and 19 simply help to define the abstract idea. The additional limitations of the dependent claim(s) when considered individually and as an ordered combination do not amount to significantly more than the abstract idea.
Viewing the claim limitations as an ordered combination does not add anything further than looking at the claim limitations individually. When viewed either individually, or as an ordered combination, the additional limitations do not amount to a claim as a whole that is significantly more than the abstract idea. Accordingly, claims 1-20 are ineligible.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 11803825 B2 (“Purves”) in view of US 20170262832 A1 (“Deshpande”), and in further view of US 20140143136 A1 (“Dhar”).
Regarding claim 1, Purves discloses a transferring computer system comprising: a communications module; one or more processors coupled to the communications module; and a memory coupled to the one or more processors and storing instructions that, when executed by the transfer processing computer system, cause the transfer processing computer system to (See at least col. 69, line 36 to col. 70, line 8, and see at least FIG. 9a, Wallet Server 908. And see at least at col. 45, line 52 to col 46, line 30, describing transferring of funds via a purchase transaction using a payment method.):
receive a first request from a first system executing a first software application, the first request triggered by the first software application and representing a data sharing request (A user may input login credentials (e.g., merchant account or wallet account username and password) at the merchant site or application on their client device. See at least col. 13, lines 42-56. The user may select sign in with wallet button and may input wallet credentials in the wallet widget launched. The client may generate an authentication request using the user provided login credentials. An example wallet authentication request, substantially in the form of a HTTP(S) POST message including XML-formatted data. See at least col. 14, lines 21-62 and see at least FIG. 9a, step 2b/918, sending Authentication Request from client to Wallet Server. The Examiner interprets the Merchant Site as the first software application.);
in response to receiving the first request, execute an authentication module, wherein executing the authentication module configures the authentication module to: provide to the first system a graphical authentication interface prompting for input of a credential and in response receive from the first system input indicating the credential (The user may select sign in with wallet button and may input wallet credentials in the wallet widget launched. See at least col. 14, lines 12-28. Wallet widget selected and user presented with wallet widget popup window to enter user and password, see at least col. 11, line 57 to col. 12, line 52 and FIG. 6-7a.);
authenticate the credential as being associated with a particular profile (The wallet server may authenticate the user. In one implementation, OAuth protocol may be utilized to authenticate the user on behalf of the merchant. In one implementation, the wallet server may use the username and/or password, one or more widget parameters such as API key in the authorization request, and/or the like to obtain a customer ID associated with the user/customer and the merchant. The wallet server may send the customer ID in an authorization response to the merchant. In one implementation, the authorization response may be a back-end notification message sent from the wallet server to the merchant. An example notification message in POST method in XML format. See at least col. 14, line 50 to col. 15, line 5, and see at least FIG. 9a, step 3a/920, Performing authentication.);
in response to authenticating the credential, provide to the first system a graphical authorization interface prompting for an indication of consent to provide access to information regarding one or more accounts corresponding to the particular profile (See FIG. 7a, describing a login process where a user enters a username and password to login to the wallet account, and see FIG. 7b, depicting a V.me interface which allows a user to select which cards and addresses to connect to the account. See also col. 12, lines 30-52.); and
in response to receiving the indication of consent from the first system via the graphical authorization interface input including the indication of consent, automatically issue and transmit to the first system a token for accessing the information regarding the one or more accounts (The wallet server may generate user information including card details including card nickname, card brand, last 4 digits of the card, and the user information details may be sent to the client device, see at least col. 15, line 44 to col. 16, line 37 and FIG. 9a, steps 934-936, depicting user information sent to the client device.);
receive a second request from a second system, the second request triggered and representing a request for configuring a payment in an e-commerce checkout (The merchant server may use the user sign as a trigger to request current user information from the wallet server. The merchant server may generate and send a user information request message to the wallet server. See at least col. 15, lines 16-37 and FIG. 9a, step 5/926.); and
in response to receiving the second request, execute the authentication module, wherein executing the authentication module configures the authentication module to: authenticate a credential received from the second system as being associated with the particular profile (The merchant server may generate and send a user information request message to the wallet server. The user information request message may include, without limitation, the customer ID that is unique to the customer and the merchant relationship, a token, an API key, a digital certificate, and/or the like. In one implementation, the token may be generated using one or more parameters such as the merchant's API key, customer ID, merchant ID, merchant name, customer name, and/or the like. See at least col. 15, lines 16-37 and FIG. 9a, step 5/926. The wallet server may obtain the request and may parse the request at. In one implementation, the wallet server may validate the request by confirming the customer ID, API key and/or the token are correct. The wallet server may use the customer ID, for example, to query one or more databases (e.g., customer profile database) for user records. The wallet server may retrieve the user record, preferences, and/or permissions from the customer profile database. In one implementation, the wallet server may use the associated preferences and permissions specified by the user to determine payment methods that the user has approved for sharing with the merchant. See at least col. 15, lines 44-60 and FIG. 9a, step 6-8/928-932.);
identify one or more accounts to be used in fulfilling an associated request, the one or more accounts corresponding to the particular profile (The wallet server may use the customer ID, for example, to query one or more databases (e.g., customer profile database) for user records. The wallet server may retrieve the user record, preferences, and/or permissions from the customer profile database. In one implementation, the wallet server may use the associated preferences and permissions specified by the user to determine payment methods that the user has approved for sharing with the merchant. See at least col. 15, lines 44-60 and FIG. 9a, step 6-8/928-932.); and
obtain an indication of consent to perform an operation associated with the associated request (The wallet server may retrieve the user record, preferences, and/or permissions 932 from the customer profile database. In one implementation, the wallet server may use the associated preferences and permissions specified by the user to determine payment methods that the user has approved for sharing with the merchant. See at least col. 15, lines 44-60 and FIG. 9a, step 6-8/928-932.).
While Purves discloses a token, Purves does not expressly disclose an OAuth token. Furthermore, while Purves discloses a second system and while Purves discloses multiple software systems (see Purves at least at col. 13, lines 4-41 and FIG. 8a-8b, multiple software applications), Purves does not expressly disclose the second system executing a second software application; nor does Purves expressly disclose the second request triggered by the second software application.
However, Deshpande discloses an OAuth token (see at least [0060].).
From the teaching of Deshpande, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the token of Purves to be an OAuth token, as taught by Deshpande, in order to improve efficiency and security of the payment account transactions (se Deshpande at least at [0013]).
While Purves discloses a second system and while Purves discloses multiple software systems (see Purves at least at col. 13, lines 4-41 and FIG. 8a-8b, multiple software applications), Purves does not expressly disclose the second system executing a second software application; nor does Purves expressly disclose the second request triggered by the second software application.
However, Dhar discloses the second system executing a second software application; the second request triggered by the second software application (Multiple software applications, see at least [0017]. Marketplace application, checkout application, see at least [0019]. Payment and transaction application, see at least [0024]. Request triggered from the second application, see at least [0036] and FIG. 3B-3C, and see also [0035].).
From the teaching of Dhar, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the second system of Purves to be executing a second software application, as taught by Dhar, and to modify the triggering of Purves to be triggered by the second software application, as taught by Dhar, in order to improve ease and convenience of payment systems for customers and improve ease and convenience of transferring funds for purchases (see Dhar at least at [0003]), and in order to improve security (see Dhar at least at [0030], [0035], and [0038]).
Regarding claim 2, the combination of Purves, Deshpande, and Dhar discloses the limitations of claim 1, as discussed above, and Purves further discloses the first and second software applications are third-party applications (see Purves at least at col. 13, lines 4-41 and FIG. 8a-8b, multiple software applications),
the authentication module is included in a web application that is separate from the first and second software applications (Web App on client device of merchant.com, see at least col. 13, lines 42 to col. 14, line 9. Web app for wallet.com, see at least col. 14, lines 31-62. Web App for server1.vwallet.com, see at least col. 15, lines 16-43.), and
the first and second systems are client devices (A user may input login credentials (e.g., merchant account or wallet account username and password) at the merchant site or application on their client device. See at least col. 13, lines 42-56. The merchant server may use the user sign as a trigger to request current user information from the wallet server. The merchant server may generate and send a user information request message to the wallet server. See at least col. 15, lines 16-37 and FIG. 9a, step 5/926. See also Purves at least at col. 13, lines 4-41 and FIG. 8a-8b, disclosing and depicting multiple software application. In view of the Specification at [0107], the Examiner interprets the client device of the first and second system as the same client device.).
Regarding claim 3, the combination of Purves, Deshpande, and Dhar discloses the limitations of claim 1, as discussed above, and Purves further discloses the request for configuring the payment in the e-commerce checkout is a pay-by-bank request and the one or more accounts are one or more bank accounts (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. See at least col. 20, lines 56-63.).
Regarding claim 4, the combination of Purves, Deshpande, and Dhar disclose the limitations of claim 1, as discussed above, and Purves further discloses receive the second request triggered (The merchant server may use the user sign as a trigger to request current user information from the wallet server. The merchant server may generate and send a user information request message to the wallet server. See at least col. 15, lines 16-37 and FIG. 9a, step 5/926.) and
execute the authentication module in response to receiving the second request during an authenticated session associated with the second software application (The merchant server may generate and send a user information request message to the wallet server. The user information request message may include, without limitation, the customer ID that is unique to the customer and the merchant relationship, a token, an API key, a digital certificate, and/or the like. In one implementation, the token may be generated using one or more parameters such as the merchant's API key, customer ID, merchant ID, merchant name, customer name, and/or the like. See at least col. 15, lines 16-37 and FIG. 9a, step 5/926. The wallet server may obtain the request and may parse the request at. In one implementation, the wallet server may validate the request by confirming the customer ID, API key and/or the token are correct. The wallet server may use the customer ID, for example, to query one or more databases (e.g., customer profile database) for user records. The wallet server may retrieve the user record, preferences, and/or permissions from the customer profile database. In one implementation, the wallet server may use the associated preferences and permissions specified by the user to determine payment methods that the user has approved for sharing with the merchant. See at least col. 15, lines 44-60 and FIG. 9a, step 6-8/928-932. See Purves at least at col. 13, lines 4-41 and FIG. 8a-8b, multiple software applications. Web App on client device of merchant.com, see at least col. 13, lines 42 to col. 14, line 9. Web app for wallet.com, see at least col. 14, lines 31-62. Web App for server1.vwallet.com, see at least col. 15, lines 16-43. Under broadest reasonable interpretation, the Examiner interprets the authenticated session as being associated with the second software application.).
While Purves discloses the second request triggered, Purves does not expressly disclose the second request triggered by the second software application.
However, Dhar discloses the second request triggered by the second software application (Multiple software applications, see at least [0017]. Marketplace application, checkout application, see at least [0019]. Payment and transaction application, see at least [0024]. Request triggered from the second application, see at least [0036] and FIG. 3B-3C, and see also [0035].).
From the teaching of Dhar, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the triggering of Purves to be triggered by the second software application, as taught by Dhar, in order to improve ease and convenience of payment systems for customers and improve ease and convenience of transferring funds for purchases (see Dhar at least at [0003]), and in order to improve security (see Dhar at least at [0030], [0035], and [0038]).
Regarding claim 5, the combination of Purves, Deshpande, and Dhar disclose the limitations of claim 1, as discussed above, and Purves further discloses the second request includes an identifier associated with the second software application (The merchant server may generate and send a user information request message to the wallet server. The user information request message may include, without limitation, the customer ID that is unique to the customer and the merchant relationship, a token, an API key, a digital certificate, and/or the like. In one implementation, the token may be generated using one or more parameters such as the merchant's API key, customer ID, merchant ID, merchant name, customer name, and/or the like. See at least col. 15, lines 16-37 and FIG. 9a, step 5/926. See Purves at least at col. 13, lines 4-41 and FIG. 8a-8b, multiple software applications. Web App on client device of merchant.com, see at least col. 13, lines 42 to col. 14, line 9. Web app for wallet.com, see at least col. 14, lines 31-62. Web App for server1.vwallet.com, see at least col. 15, lines 16-43. Under broadest reasonable interpretation, the Examiner interprets the identifier as being associated with the second software application.)
Regarding claim 6, the combination of Purves, Deshpande, and Dhar disclose the limitations of claim 5, as discussed above, and Purves further discloses execute the authentication module in response to receiving the second request further cause the computer system to map the identifier to data to be used in one or more graphical elements of the graphical authorization interface (The merchant server may generate and send a user information request message to the wallet server. The user information request message may include, without limitation, the customer ID that is unique to the customer and the merchant relationship, a token, an API key, a digital certificate, and/or the like. In one implementation, the token may be generated using one or more parameters such as the merchant's API key, customer ID, merchant ID, merchant name, customer name, and/or the like. See at least col. 15, lines 16-37 and FIG. 9a, step 5/926. The wallet server may obtain the request and may parse the request at. In one implementation, the wallet server may validate the request by confirming the customer ID, API key and/or the token are correct. The wallet server may use the customer ID, for example, to query one or more databases (e.g., customer profile database) for user records. The wallet server may retrieve the user record, preferences, and/or permissions from the customer profile database. In one implementation, the wallet server may use the associated preferences and permissions specified by the user to determine payment methods that the user has approved for sharing with the merchant. See at least col. 15, lines 44-60. Displaying the current user information to the user, see at least col. 16, lines 17-37 and see also FIG. 5.).
Regarding claim 7, the combination of Purves, Deshpande, and Dhar disclose the limitations of claim 6, as discussed above, and Purves further discloses execute the authentication module in response to receiving the first request further cause the computer system to configure a first instance of the graphical authorization interface to include one or more interface elements associated with the first software application (User requests to login, and after logging in, interface displays Merchant website information and Wallet information. See at least and col. 13, lines 4-41 and FIG. 8a-8b.).
Regarding claim 8, the combination of Purves, Deshpande, and Dhar disclose the limitations of claim 7, as discussed above, and Purves further discloses execute the authentication module in response to receiving the second request further cause the computer system to configure a second instance of the graphical authorization interface to include one or more interface elements associated with the second software application instead of the one or more interface elements associated with the first software application (V.Me Widget displaying to allow user to login and select preferences and select payment card, see at least col. 12, line 30 to col. 13, line 3 and FIG. 7a, screen (3) and FIG. 7b, screen (4)-(5).).
Regarding claim 9, the combination of Purves, Deshpande, and Dhar disclose the limitations of claim 7, as discussed above, and Purves further discloses the one or more interface elements associated with the first software application include a representation of branding associated with the first software application (Representation of branding on the merchant site, see at least col. 12, line 30 to col. 13, line 3 and FIG. 7a, Merchant Site at screen (1), and see also FIG. 5, “Nordstrom” merchant branding.).
Regarding claim 10, the combination of Purves, Deshpande, and Dhar disclose the limitations of claim 1, as discussed above, and Purves further discloses provide a historical list defining entities corresponding to a plurality of software (See at least col. 23, line 62 to col. 24, line 27 and FIG. 16 listing merchants of past transactions including Nordstrom and Amazon.com).
Claim 11 has similar limitations found in claim 1 above, and therefore is rejected by the same art and rationale.
Claim 12 has similar limitations found in claim 2 above, and therefore is rejected by the same art and rationale.
Claim 13 has similar limitations found in claim 3 above, and therefore is rejected by the same art and rationale.
Claim 14 has similar limitations found in claim 4 above, and therefore is rejected by the same art and rationale.
Claim 15 has similar limitations found in claim 5 above, and therefore is rejected by the same art and rationale.
Claim 16 has similar limitations found in claim 6 above, and therefore is rejected by the same art and rationale.
Claim 17 has similar limitations found in claim 7 above, and therefore is rejected by the same art and rationale.
Claim 18 has similar limitations found in claim 8 above, and therefore is rejected by the same art and rationale.
Claim 19 has similar limitations found in claim 9 above, and therefore is rejected by the same art and rationale.
Claim 20 has similar limitations found in claim 1 above, and therefore is rejected by the same art and rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20170270515 A1 (“McCullagh”) discloses enabling merchants to pass payment tokens, instead of actual payment information, to third party HOPs and SOPs. This, for example, enables a merchant to charge a consumer, such as on a recurring basis or for a one-off purchase, without having the consumer enter payment information each time and without the merchant actually having to handle payment information. As such, merchants can avoid costs and responsibilities associated with handling and storing consumer payment data, while at the same time it also gives merchants the benefit of engaging in purchase transactions with consumers without requiring that the consumers reenter payment data each time they want to make a purchase.
US 20170357957 A1 (“Mehta”) discloses facilitating authentication includes providing a first page to a user interface based on an order received from a merchant page. Payment details are received from the first page for a first level of authentication and a second page is provided to the user interface for a second level of authentication. The second page is provided while keeping the first page open in the user interface with the payment details populated therein. A transaction result status is received from a payment-processing infrastructure based on the first and second level of authentication. When the transaction result status indicates failure, a modified first page is created to include the payment details previously populated for an online payment and at least one of a retry button and a field indicating a reason for transaction failure.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RAVEN E YONO whose telephone number is (313)446-6606. The examiner can normally be reached Monday - Friday 8-5PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bennett M Sigmond can be reached on (303) 297-4411. 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.
/RAVEN E YONO/Primary Examiner, Art Unit 3694