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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 5/5/2026 has been entered.
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 is directed to a judicial exception (abstract idea) without significantly more.
Under the broadest reasonable interpretation, the following claim terms are presumed to have their plain meaning consistent with the specification as it would be interpreted by one of ordinary skill in the art. MPEP § 2111.
Step 1: Does the Claim Fall within a Statutory Category? (see MPEP 2106.03)
Claim 1 recites a process, which is a statutory category of invention (Step 1: YES). Claim 8 recites a product (apparatus), which is a statutory category of invention (Step 1: YES). Claim 15 recites a system, which is a statutory category of invention (Step 1: YES).
Step 2A, Prong One: Is a Judicial Exception Recited? (see MPEP 2106.04(a)). Yes.
The claims are analyzed to determine whether it is directed to a judicial exception. The following claims identify the limitations that recite additional elements in bold and the abstract idea without bold. Underlined claim limitations denote newly added claim limitations:
Claim 1, 18 and 15 recite a method for user authentication, the method comprising: receiving a selection to execute a first financial transaction on a first user account of a first user at a financial institution; dynamically determining an authentication level requirement of the first transaction based on one or more of a transaction type or a user behavioral profile; sending, via an authentication system, to a first computing device of the first user, a selectable menu of user authentication options to authorize the first financial transaction at the financial institution, the user authentication options being authentications executed via at least one third-party entity device; receiving a selected user authentication option of the user authentication options via the selectable menu at the first computing device; receiving, via the authentication system, an indication that the first user completed the selected user authentication option to authorize the first financial transaction at the financial institution; determining that completing the selected user authentication option to authorize the first financial-transaction-at the financial institution satisfies the authentication level requirement for the first financial transaction; and in response to the determination, executing the first financial transaction on the first user account at the financial institution. These limitations, as drafted, under its broadest reasonable interpretation, covers performance via certain methods of organizing human activity, but for the recitation of generic computer components. Under human activity, the limitations are commercial interactions (business relations), as well as managing interactions between people (following instructions). The claims are also a fundamental economic activity, such as mitigating risk (See Applicant specification discussing “trust” in Para. 33, 37, and 44). Accordingly, the claim recites an abstract idea. The mere recitation of generic computer components in the claims do not necessarily preclude that claim from reciting an abstract idea. (Step 2A-Prong 1: Yes. The claims recite an abstract idea).
This judicial exception is not integrated into a practical application. In particular, the claim recites the additional elements of a system, first computing device, non-transitory machine-readable medium, processing circuitry, processor, storage device, authentication system, first computing device, selectable menu, third-party entity device and user authentication options. The additional elements of a system, first computing device, non-transitory machine-readable medium, processing circuitry, processor, storage device, authentication system, third-party entity device and first computing device, are just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)). The additional elements of selectable menu, and user authentication options are generally linking the use of the judicial exception to a particular technological environment or field of use, for the particular technology of Graphical User Interfaces (MPEP 2106.05(h)). The computer components are recited at such a high-level of generality (i.e. as a generic computer components) such that it amounts to no more than mere instructions to apply the exception using generic computer components, and the claims fail to recite technological detail as to how the step of the judicial exception is accomplished. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea and are at a high level of generality. (Step 2A-Prong 2: NO. The judicial exception is not integrated into a practical application).
Next, the claims are analyzed to determine if there are additional claim limitations that individually, or as an ordered combination, ensure that the claim amounts to significantly more than the abstract ideas (whether claim provides inventive concept). As discussed with respect to Step 2A2 above, the additional elements of (a system, first computing device, non-transitory machine-readable medium, processing circuitry, processor, storage device, authentication system, first computing device, selectable menu, third-party entity device and user authentication options) in the claims amount to no more than mere instructions to apply the exception using a generic computer component and generally linking the use of GUI’s to judicial exception. The same analysis applies here in Step 2B, i.e., mere instructions to apply an exception using a generic computer component and generally linking the use of GUI’s to judicial exception cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Viewing the limitations as an ordered combination does not add anything further than looking at the 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 itself. Therefore, the claims do not amount to significantly more than the recited abstract idea (Step 2B: NO; The claims do not provide significantly more, and are not patent eligible).
Claims 2, 9 and 16 recite, wherein the selected user authentication option to authorize the first financial transaction at the financial institution includes a user login to an account of the first user at a third-party entity, and wherein determining that the first user completed the selected user authentication option to authorize the first financial transaction at includes receiving an user authentication confirmation from the third-party entity. These limitations are also part of the abstract idea identified in claim 1, and the additional elements of user login are generally linking the use of the judicial exception to a particular technological environment or field of use, for the particular technology of graphical user interface (MPEP 2106.05(h)), as in the claim 1, 8 and 15, analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 1, 8, and 15, supra.
Claims 3, 10 and 17 recite, wherein the selected user authentication option at a third-party entity to authorize the first financial transaction at the financial institution includes completing a second financial transaction at the third-party entity, the third-party entity including at least one of a second financial institution, a digital payment network, or a digital wallet. These limitations are also part of the abstract idea identified in claim 1, 8, and 15, and the additional elements of digital payment network and digital wallet are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1, 8 and 15 analyses above. Therefore, this claim is similarly rejected under the same rationale as claim 1, 8, and 15, supra.
Claims 4, 11, and 18 recite, further comprising: in response to receiving the selected user authentication option to authorize the first financial transaction at the financial institution, sending a second user authentication request to a third-party entity, the selected user authentication option including at least one of a transaction at the third-party entity by the first user, a verification at the third-party entity of an identity of the first user, a validation using a debit card of the first user at the third-party entity or a validation using a credit card of the first user at the third-party entity, the debit card and the credit card associated to the financial institution; and wherein determining that the first user completed the selected user authentication option includes receiving an authentication confirmation from the third-party entity. These limitations are also part of the abstract idea identified in claim 1, 8, and 15, and is similarly rejected under the same rationale as claim 1, 8, and 15, supra
Claim 5, 12 and 19 recite, wherein the third-party entity includes at least one of a physical store, an online store, a residential facility, or a care facility. These limitations are also part of the abstract idea identified in claim 1, 8, and 15, and is similarly rejected under the same rationale as claim 1, 8, and 15, supra.
Claim 6 recites, wherein the selected user authentication option at a third-party entity includes a transfer from an account of the first user at the third-party entity to authorize the first financial transaction at the financial institution to an account specified by the financial institution. These limitations are also part of the abstract idea identified in claim 1, 8, and 15, and is similarly rejected under the same rationale as claim 1, 8, and 15, supra.
Claim 7 recites, wherein the selected authentication option at a third-party entity includes a transfer from an account of the first user at the third-party entity to an account registered on the first user account at the financial institution. These limitations are also part of the abstract idea identified in claim 1, 8, and 15, and is similarly rejected under the same rationale as claim 1, 8, and 15, supra.
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.
Claim(s) 1, 2, 8, 9, 15 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Carter US 20090152343, in view of Golan US 20050097320 and Mueller US 20240202675.
Regarding claims 1, 8 and 15, Carter discloses a method for user authentication (Abstract, Authentication methods for use in financial transactions and information banking), the method comprising:
receiving a selection to execute a first financial transaction on a first user account of a first user at a financial institution, (User 172 selects to transact on 101 which communicates with financial institution 164; Fig. 3, 201 person initiates transaction; 204 authentication requirement, to 205 with several levels of authentication (205A to 205E).
Carter fails to disclose dynamically determining an authentication level requirement of the first financial transaction based on one or more of a transaction type or a user behavioral profile. However, Golan discloses a risk-based dynamic determination with flexible transaction processing (Fig. 3, Para. 43, decision engine 157, with administration utility 158 as a back-office application run through operator 159) that allows for flexible processing based on…the risk assessment of a transaction or user or party to the transaction (See abstract; Para. 36 and Fig. 3, information database 160 feeds into 157; Para. 36, “Other control aspects that a decision engine 157 may take part in can include, for example making an optional authentication step mandatory, or vice versa, adding an additional authentication step to one already performed, not to authenticate at all, possibly regardless or risk level, for example base on some override factor such as a user being in a VIP or other list, postponing authentication to a later time, disallowing self service profile change activities, such as password recovery, address change etc. For example, self service password recovery may be disallowed if the user is browsing from a “risky” location. A VIP or special user may be required to authenticate only if, for example, a risky operation is performed or the authentication is performed during off hours or not in the middle of the day”; Para. 43, “One or more authentication modules, servers or engines 156 may for example include the capability to communicate with users, for example using an infrastructure or capability for communication with a user's browser or other terminal software, instant messaging software, cellular device or telephone, etc., to support various levels of authentication, which are determined according to the risk score. The adaptive authentication module 156 may proactively ask a user to supply additional information that may be needed for future authentications. The decision engine 157 may for example receive a risk score, examine which authentication options are available, and decide what action to take”; Para. 92-93, “The decision engine may communicate with for example a risk module and request the event's risk score. In operation 305, the risk module may use for example risk models (e.g., generic and specific), run an analysis of the event, and may return a risk score…In operation 310, the decision engine may take the risk score, and may consult a user information database and the specific constraints to determine what are the available authentication methods. In operation 315, the decision engine may check the available authentication methods and the risk score against the configuration tables and decide what action to take.”)
It would have been considered obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Carter with the dynamic determination of an authentication level requirement based on transaction type of behavioral profile of Golan. Doing so increases security for user authentication and enhances the overall experience for the user.
Carter also discloses sending, via an authentication system (Fig. 2, 164 is an authentication system; Fig. 3, is a system as well that approves authentication; Fig. 2, Sent from 164 to 101, which includes a mobile device, laptop etc. associated with a user, 172)), to a first computing device of the first user (“Device 101 is configured for multi-factor authentication of transactions; Fig. 2, Sent from 164 to 101, which includes a mobile device, laptop etc. associated with a user, 172), a selectable menu of user authentication options to authorize the first financial transaction at the financial institution (Para. 5, Para. 33-35; Authentication levels, Level 1, 2, or 3; voice; User selects/provides via device interface, scan fingerprint, or enter PIN; Para. 39 & 49, “authentication is performed…with authentication methods…to complete the transaction”);
Carter also discloses a third-party entity (“Third party entity” - Applicant specification, Para. 49, “third party entity” includes online store, retail store, physical store, grocery store, etc.; Fig. 2, 174, Para. 26, 174 may include retail locations) but fails to disclose the user authentication options being authentications executed via at least one third-party entity device. However, Mueller discloses an authentication method with a dropdown menu (Fig. 2, 205; Para. 59, Drop down menu that may be individually selected by user where user can enter email address associated with digital wallet; See figure 3 as well, showing merchant site with digital wallet), that allows the user to input an email address for authentication purposes for a digital wallet (A “menu” can include one option, or several options; Applicant specification (Para. 49) defines “third-party entity” as a “digital wallet”) from a third-party computing system for purposes of facilitating the transaction (Para. 77, Block 504; Block 506, integration into the digital wallet of 3rd party; Para. 79 as well; Para. 59, “Once the authentication information is provided, the computing system may perform an authentication process 221 to authenticate the user and to determine which digital wallet is associated with that user”; Computing system 206 is a third party entity; Fig. 1, shows a server which is a “device”).
It would have been considered obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Carter with the third-party entity authentication method of Mueller. Doing so allows cross-platform communication o occur that integrates the website of a financial institution with the website of a digital wallet (Mueller, Para. 60), as well as enhances security for authentication of the user to prevent fraud.
receiving a selected user authentication option of the user authentication options at the first computing device (Fig. 2, 206, user selects different validation options 205A to 205E which are received at 162; Step 209 requires authentication, Para. 70);
receiving, via the authentication system, an indication that the first user completed the selected user authentication option to authorize the first financial transaction at the financial institution (Fig. 2, 211; Para. 70, then step 204, determine authentication level based on transaction criteria; “Such communication may include indications that certain steps of the method 200 have been performed, that the device 101 requires information to perform a step, or that the device requires the other device to wholly or partially perform a step, for example” Fig. 3, Element 205(A-E) different types of authentication);
determining that completing the selected user authentication option to authorize the first financial transaction at the financial institution satisfies the authentication level requirement for the first financial transaction (162 makes determination; Para. 71);
and in response to the determination, authorizing the first financial transaction to execute using the first user account at the financial institution (Fig. 2, 212 Transaction approved).
Regarding claims 2, 9, and 16, modified Carter discloses wherein the selected user authentication option to authorize the first financial transaction at the financial institution includes a user login to an account of the first user at a third-party entity, and wherein determining that the first user completed the selected user authentication option to authorize the first financial transaction at the financial institution includes receiving an user authentication confirmation from the third-party entity.
Claim(s) 4, 5, 11, 12, 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Carter US 20090152343, in view of Mueller US 20240202675 and Golan US 20050097320, as applied to claims 1, 8 and 15 above, further in view of Williams GB 2398159.
Regarding claim 4, 11 and 18, modified Carter discloses in response to receiving the selected authentication option to authorize the first financial transaction at the financial institution, the selected user authentication option to authorize the first financial transaction at the financial institution including at least one of a transaction at the third-party entity by the first user (Mueller, Fig. 3, transaction made at merchant site, 302), a validation using a credit card of the first user at the third-party entity, the debit card and the credit card associated to the financial institution (Digital wallet 302 is associated with a financial institution and associated with a credit card, Para. 62, Para. 63, New payment source 318; Para. 64, payment gateway to credit card; Para. 2, Para. 35).
Modified Carter fails to disclose wherein determining that the first user completed the selected user authentication option includes receiving an authentication confirmation from the third-party entity. However, Williams discloses the use of a phone phone in a transaction context (Phone 6) that receives a SMS message from an SMS communications transmitter (5) and displayed on the user screen (7) where merchant terminal (1) receives confirmation that user device (6) confirms authorization (Fig. 1).
it would have been considered obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Carter with the authorization confirmation of Williams. Doing so allows the merchant to proceed with the transaction, and creates greater security for the transaction prior to enactment.
Modified Carter discloses sending a first authentication request, but fails to discloses sending a second authentication request to a third-party entity.
However, it would have been considered obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Carter with second authentication request as it has been held that mere duplication of parts does not hold patentable weight. (In reHarza, 274 F.2d 669, 124 USPQ 378 (CCPA 1960) (Claims at issue were directed to a water-tight masonry structure wherein a water seal of flexible material fills the joints which form between adjacent pours of concrete. The claimed water seal has a “web” which lies in the joint, and a plurality of “ribs” projecting outwardly from each side of the web into one of the adjacent concrete slabs. The prior art disclosed a flexible water stop for preventing passage of water between masses of concrete in the shape of a plus sign (+). Although the reference did not disclose a plurality of ribs, the court held that mere duplication of parts has no patentable significance unless a new and unexpected result is produced.).
Regarding claims 5, 12, and 19, modified Carter discloses wherein the third-party entity includes at least one of a physical store, an online store, a residential facility, or a care facility (Mueller, Merchant site 302).
Claim(s) 3, 10 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Carter US 20090152343, in view of Mueller US 20240202675 and Golan US 20050097320, as applied to claims 1, 8, and 15 above, further in view of Zamer US 10223677.
Regarding claim 3, 10 and 17, modified Carter fails to disclose wherein the selected authentication option at a third-party entity to authorize the first financial transaction at the financial institution includes completing a second financial transaction at the third-party entity. However, Zamer discloses the ability to conduct recurring payments for multiple transactions after a user has been identified previously (Zamer, “Payment service provider may determine recurring payments to a particular merchant, such as monthly bills”; Claim 1, Claim 8).
It would have been considered obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Carter with the recurring payment structure of Zamer. Doing so allows the user to be pre-authenticated to make future purchases, making it easier for the user to make purchases in the future and increasing efficiency.
Modified Carter also fails to disclose third-party entity including at least one of a second financial institution, a digital payment network, or a digital wallet.
It would have been considered obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Carter with the second financial institution, a digital payment network, or a digital wallet as it has been held that mere duplication of parts does not hold patentable weight. (In reHarza, 274 F.2d 669, 124 USPQ 378 (CCPA 1960) (Claims at issue were directed to a water-tight masonry structure wherein a water seal of flexible material fills the joints which form between adjacent pours of concrete. The claimed water seal has a “web” which lies in the joint, and a plurality of “ribs” projecting outwardly from each side of the web into one of the adjacent concrete slabs. The prior art disclosed a flexible water stop for preventing passage of water between masses of concrete in the shape of a plus sign (+). Although the reference did not disclose a plurality of ribs, the court held that mere duplication of parts has no patentable significance unless a new and unexpected result is produced.).
Claim(s) 6, 7, 13, 14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Carter US 20090152343, in view of Mueller US 20240202675 and Golan US 20050097320, as applied to claims 1, 8 and 15 above, alone.
Regarding claim 6 and 13, modified Carter discloses a third party entity (Fig. 3, Merchant site 302) with user digital wallet and a financial institution (302/303) allowing the user to make a purchase, but fails to disclose where the selected user authentication option at a third-party entity to authorize the first financial transaction at the financial institution includes a transfer from an account of the first user at the third-party entity to an account specified by the financial institution.
It would have been considered obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Carter with the ability to transfer money from an account of the user while purchasing to an account of the financial institution. Doing so allows the user to transfer money accordingly for a purchase.
Regarding claim 7, 14, and 20, modified Carter discloses modified Carter discloses a third party entity (Fig. 3, Merchant site 302) with user digital wallet and a financial institution (302/303) allowing the user to make a purchase, but fails to disclose wherein the selected user authentication option at a third-party entity includes a transfer from an account of the first user at the third-party entity to an account registered on the first user account at the financial institution.
It would have been considered obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Carter with the ability to transfer money from an account of the user while purchasing to an account of the financial institution. Doing so allows the user to transfer money accordingly for a purchase.
Response to Arguments
Applicant's arguments filed 4/14//2026 have been fully considered but they are not persuasive.
Regarding the 101 rejection, Applicant argues that the currently recited claims are not abstract and deal with authentication. Examiner disagrees. The claims recite “authentication” for the purpose of “transaction.” The mere authentication of identity of transacting parties manages the contractual relationship of between the parties, so the claim limitations are a commercial interaction. Improvement to functioning of an authentication process applied to a system is not an improvement to technology, and is only an improvement to the judicial exception.
These limitations, as drafted, under its broadest reasonable interpretation, covers performance via certain methods of organizing human activity, but for the recitation of generic computer components. Under human activity, the limitations are commercial interactions (business relations), as well as managing interactions between people (following instructions). The claims are also a fundamental economic activity, such as mitigating risk (See Applicant specification discussing “trust” in Para. 33, 37, and 44). Accordingly, the claim recites an abstract idea.
Applicant also argues that the currently recited claim limitations are a practical application, and that the claims help overcome “barriers for users who lacked access to mobile device; granting more authentication options. For example, as opposed to only having a "one-time" password, the applicant can now have more options for authentication. Examiner disagrees. This usefulness should not be confused with practical application in subject matter eligibility. Providing an alternative form of authentication at best improves the judicial exception, and not to another technology.
In Enfish, the court evaluated the patent eligibility of claims related to a self-referential database. Id. The court concluded the claims were not directed to an abstract idea, but rather an improvement to computer functionality. In contrast, the current claims are not directed to an improvement to computer functionality and instead merely recite the computer elements at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer component.
In McRO, the Federal Circuit held the claimed methods of automatic lip synchronization and facial expression animation using computer-implemented rules patent eligible under 35 U.S.C. § 101, because they were not directed to an abstract idea. The basis for the McRO court's decision was that the claims were directed to an improvement in computer-related technology (allowing computers to produce "accurate and realistic lip synchronization and facial expressions in animated characters" that previously could only be produced by human animators), and thus did not recite a concept similar to previously identified abstract ideas. In contrast, the instant claims provide a generically computer-implemented solution to a business-related or economic problem and are thus incomparable to the claims at issue in McRO.
The currently recited claim limitations are directed to abstract idea of risk-calibrated selection of verification or authentication methods, which is a concept long practices by humans, and fails to integrate that idea into a practical application because the reconfiguration of authentication steps, even when performed dynamically by software, does not improve any technology, or solve a technical problem.
Bascom relates to translating multiple filters attached to client-side devices to a single filter on the server-side device to filter information request based on requestor’s profile. The steps in the current claims are purely business interaction (authentication steps for access for transacting) that can be achieved on a face-to-face level or over the telephone or over generic network environment. This is purely a commercial interaction under the certain methods of organizing human activity.
The currently recited claims merely automate a pre-existing business practice. For example, a wire transfer of higher amounts of money may require more verification than a $10 withdrawal from an ATM. Presenting a customer with authentication choices, for example, different passwords, or verification at the teller window, is an abstract idea that existed before the use of computers “(We must determine whether the claims do significantly more than simply describe these abstract methods. We conclude they do not.” Alice Corp, 573 U.S. at 225). Still further, risk scoring and behavioral profiling, absent a specific technical improvement to how the computer process the data, are abstract.
Regarding the 103 rejection, Applicant argues that Mueller fails to disclose user authentication options executed a third party entity device that serve to authorize a first financial transaction at the financial transaction. Examiner disagrees. The claim limitation in which Mueller is used for purposes of the 103 regards a third-party device with user authentication options executed via at least one third-arty device. Carter discloses a selectable menu of user authentication options, whereas Mueller is used for the purpose of the authentication options executed via at least one outside device. One of ordinary skill in the art, would understand that a “third party wallet” is used for transactional purposes. Further, 206 is a computing system which is a server, otherwise known as a device according to broadest reasonable interpretation (Mueller discloses an authentication method with a dropdown menu (Fig. 2, 205; Para. 59, Drop down menu that may be individually selected by user where user can enter email address associated with digital wallet; See figure 3 as well, showing merchant site with digital wallet), that allows the user to input an email address for authentication purposes for a digital wallet (A “menu” can include one option, or several options; Applicant specification (Para. 49) defines “third-party entity” as a “digital wallet”) from a third-party computing system for purposes of facilitating the transaction (Para. 77, Block 504; Block 506, integration into the digital wallet of 3rd party; Para. 79 as well; Para. 59, “Once the authentication information is provided, the computing system may perform an authentication process 221 to authenticate the user and to determine which digital wallet is associated with that user”; Computing system 206 is a third party entity; Fig. 1, shows a server which is a “device”)).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Eichner US 20130103584 4/25/2013 G06A20/40 discloses a third-party device (Fig. 1 and 2, “116, authentication service server”), that receives an authentication sequence (206) from a consumer computer (114) with a consumer prompt (Para. 44-46), that prompts the consumer 104 to select an external authentication service 106, such as a coail networking service, a social media service, or a webmail service (In the example, fig. 3, 104 selects facebook 306a, twitter 306b, or OpenID 306c, with payment page sent to consumer’s computing device containing a selectable menu (with radio button options) or external/third-party authentication providers, and the authentication executed on third party servers, which are “devices”).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRANDON M DUCK whose telephone number is (469)295-9049. The examiner can normally be reached 8am - 5pm.
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, Michael Anderson can be reached at 571-270-0508. 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.
/BRANDON M DUCK/Examiner, Art Unit 3693
Prosecution Insights