DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, 18/585,877, was filed on 02/23/2024, and does not claim foreign priority or domestic benefit to any other application.
The effective filing date is after the AIA date of March 16, 2013, and so the application is being examined under the “first inventor to file” provisions of the AIA .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Status of the Application
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 01/29/2026 has been entered.
This Non-Final Office Action is in response to Applicant’s communication of 01/29/2026.
Claims 1-20 are pending, of which claims 1, 8, and 15 are independent.
In the most recent amendment, independent claims 1, 8, and 15 and dependent claims 5, 12, and 19 have been amended.
All pending claims have been examined on the merits.
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 non-statutory subject matter. The claimed invention is directed to an abstract idea, without “significantly more”.
Based on the flowchart in MPEP § 2106, Step 1 of the Alice/Mayo analysis is: “Is the claim to a process, machine, manufacture or composition of matter?”
In regards to Step 1 of the Alice/Mayo analysis, independent claim 1 is a method claim, claim 8 is an article of manufacture claim or product by process claim (“non-transitory computer readable medium”), and claim 15 is an apparatus claim.
For the sake of compact prosecution, we continue with the Alice/Mayo “abstract idea” analysis.
Step 2A, prong 1 of the Alice/Mayo analysis is: “Does the claim recite a law of nature, a natural phenomenon (product of nature), or an abstract idea?”
In regards to Step 2A, prongs 1 and 2 of the Alice/Mayo analysis, the abstract idea elements recited in independent claim 15 are shown in italic font. (The “additional elements” and “extra solution steps” are shown in italic and underlined font):
15. (Currently Amended) A system comprising:
at least one processor; and
memory including instructions, which when executed by the at least one processor, configure the at least one processor to perform operations comprising:
linking, using processing circuitry, a first user account of a first user to a second user account of a second user at a financial institution, linking including registering a first computing device of the second user for authorizing authentication of the first user at the first computing device of the second user by the second user;
receiving an authorization request to complete a first financial transaction on the first user account from the first user, the first financial transaction having an authentication level requirement;
determining that the first user is not authenticated to complete the first financial transaction on the first user account based on the authentication level requirement;
in response to determining that the first user is not authenticated, displaying a user interface including a push notification on the first computing device of the second user the push notification requesting a first authentication confirmation for the first user through an application on the first computing device of the second user, the application used to access the second user account of the second user on the first computing device of the second user;
receiving, using the processing circuitry, the first authentication confirmation for the first user from the first computing device of the second user at the application via the second user account of the second user;
determining that the first authentication confirmation meets the authentication level requirement of the first financial transaction; and
in response to determining that the first authentication confirmation meets the authentication level requirement, authorizing the first financial transaction on the first user account by the first user.
More specifically, claims 1-20 recite an abstract idea: “Certain Methods of Organizing Human Activity", specifically “Commercial or Legal Interactions (Including Agreements in the form of Contracts; Legal Obligations; Advertising, Marketing, or Sales Activities or Behaviors; Business Relations)”, as discussed in MPEP §2106(a)(2) Parts (I) and (II), and in the 2019 Revised Patent Subject Matter Eligibility Guidance.
The “Commercial or Legal Interactions” elements include:
“linking, using processing circuitry, a first user account of a first user to a second user account of a second user at a financial institution, linking including registering a first computing device of the second user for authorizing authentication of the first user at the first computing device of the second user by the second user”.
“determining that the first user is not authenticated to complete the first financial transaction on the first user account based on the authentication level requirement”.
“determining that the first authentication confirmation meets the authentication level requirement of the first financial transaction”.
“in response to determining that the first authentication confirmation meets the authentication level requirement, authorizing the first financial transaction on the first user account by the first user”.
The “additional elements” include: “at least one processor”, “memory including instructions” and “at least one processor”.
Moreover, “additional extra-solution elements” include:
“receiving an authorization request to complete a first financial transaction on the first user account from the first user, the first financial transaction having an authentication level requirement”,
“in response to determining that the first user is not authenticated, displaying a user interface including a push notification on the first computing device of the second user the push notification requesting a first authentication confirmation for the first user through an application on the first computing device of the second user, the application used to access the second user account of the second user on the first computing device of the second user”, and
“receiving, using the processing circuitry, the first authentication confirmation for the first user from the first computing device of the second user at the application via the second user account of the second user”.
Step 2A, prong 2 of the Alice/Mayo analysis is “Does the claim recite additional elements that integrate elements that integrate the judicial exception into a practical application?”
In regards to Step 2A, prong 2 of the Alice/Mayo analysis, this abstract idea is not integrated into a practical application, because:
The claim is directed to an abstract idea with additional generic computer elements. The generically recited computer elements (“at least one processor”, “memory including instructions” and “at least one processor”) do not add a meaningful limitation to the abstract idea, because they amount to simply implementing the abstract idea on a computer. The claim amounts to adding the words "apply it" (or an equivalent) with the abstract idea, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea.
The extra-solution activities (“receiving [data]”) do not add a meaningful limitation to the method, as they are insignificant extra-solution activity;
The combination of the abstract idea with the additional elements (generically recited computer elements), and/or with the extra-solution activities, does not integrate the abstract idea into a practical application.
Step 2B of the Alice/Mayo analysis is: “Does the claim recite additional elements that amount to significantly more than the judicial exception?”
In regards to Step 2B of the Alice/Mayo analysis, the claims do not include additional elements that are sufficient to amount to significantly more than the abstract idea, because:
When considering the elements "alone and in combination" (“at least one processor”, “memory including instructions” and “at least one processor”), they do not add significantly more (also known as an "inventive concept") to the exception, because they amount to simply implementing the abstract idea on a computer. Instead, they merely add the words "apply it" (or an equivalent) with the abstract idea, or mere instructions to implement an abstract idea on a computer, or merely use a computer as a tool to perform an abstract idea.
In regards to the extra solution activities (“receiving [data]”), these are recognized as such by the court decisions listed in MPEP § 2106.05(d).
More specifically, in regards to the “storing [instructions]” step (“memory including instructions”), see the court cases Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015) (storing and retrieving information in memory); and OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1092-93 (Fed. Cir. 2015) (storing and retrieving information in memory).
More specifically, in regards to the “receiving” steps, see the court cases OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network) and (presenting offers and gathering statistics), OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93; buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network).
Moreover, in regards to the “displaying” step (“displaying a user interface including a push notification on the first computing device of the second user”), see Apple, Inc. v. Ameranth, Inc., 842 F.3d 1229, 120 U.S.P.Q.2d 1844 (Fed. Cir. 2016) (Holding that the claimed menu graphic user interface is an abstract idea under 35 USC §101, because claimant "[did] not claim a particular way of programming or designing the software to create menus that have these features, but instead merely claims the resulting systems").
Moreover, in regards to “apply it”, according to MPEP § 2106.05(f)(2):
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 general purpose 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. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone); TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit). Similarly, "claiming the improved speed or efficiency inherent with applying the abstract idea on a computer" does not integrate a judicial exception into a practical application or provide an inventive concept. Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1367, 115 USPQ2d 1636, 1639 (Fed. Cir. 2015).
In contrast, a claim that purports to improve computer capabilities or to improve an existing technology may integrate a judicial exception into a practical application or provide significantly more. McRO, Inc. v. Bandai Namco Games Am. Inc., 837 F.3d 1299, 1314-15, 120 USPQ2d 1091, 1101-02 (Fed. Cir. 2016); Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1335-36, 118 USPQ2d 1684, 1688-89 (Fed. Cir. 2016). See MPEP §§ 2106.04(d)(1) and 2106.05(a) for a discussion of improvements to the functioning of a computer or to another technology or technical field.
The Examiner holds that the independent claims “use a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data)” or “simply add a general purpose computer or computer components after the fact to an abstract idea”.
Independent method claim 1 and independent “non-transitory computer readable medium” claim 8 are rejected on the same grounds as independent apparatus claim 15. Independent claim 8 is also rejected on the grounds that it recites a computer-readable medium, which is merely another generic computer component.
All dependent claims are also rejected, because they merely further define the abstract idea.
Claim Rejections - 35 USC § 103
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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 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.
Claim 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 2022/0046009 A1 to Bronstein (“Bronstein”. Eff. Filed on Aug. 5, 2020. Published on Feb. 10, 2022) in view of US 2019/0372959 A1 to Pattar et al. (“Pattar”. Filed on May 30, 2018. Published on Dec. 5, 2019).
In regards to claim 1,
1. (Currently Amended) A method for user authentication, the method comprising:
linking, using processing circuitry, a first user account of a first user to a second user account of a second user at a financial institution, linking including registering a first computing device of the second user for authorizing authentication of the first user at the first computing device of the second user by the second user;
(See Bronstein, para. [0025]: “The user devices 102 a,b are generally any computing devices operable to provide a request 106 for access to the secure server 108, capture an image of the requesting user 104, receive a challenge-response message 130, and/or generate a corresponding verification response 138. In some embodiments, the requesting user 104 (e.g., the individual requesting access to the secure server 108) may operate more than one user device 102 a,b to request and gain access to the secure server 108. For example, the user 104 may initially request access to the secure server 108 from a first user device 102 a, such as a personal computer. Meanwhile, multi-person authentication may be performed through a second user device 102 b, such as a smartphone, as illustrated in the example of FIG. 1.”)
(See Bronstein, para. [0003]: “In an embodiment, a system includes a multi-person authentication server which receives an authentication request corresponding to a request to provide a first user access to a secure server. In response to the authentication request, a challenge-response message is provided to the first user device. The challenge-response message indicates authentication of the first user of the first user device is needed and directs the first user device to capture a first image of a face of the first user. A push notification is also provided to a second user device. The push notification indicates confirmation of the authentication of the first user of the first user device is needed and directs the second user device to capture a second image of a face of the second user and provide an authentication result to the first user device. A response to the challenge-response message is received from the first user device. The response indicates the first user is authorized to access the secure server if the first image is an image of an authorized user of the secure server and the second image is an image of an administrator of the secure server. The response indicates the first user is not authorized to access the secure server if one or both of the following are true: (1) the first image is not the image of the authorized user of the secure server and (2) the second image is not the image of the administrator of the secure server. If the received response indicates the first user is authenticated, the first user is allowed to access the secure server. If the received response indicates the first user is not authenticated, the first user is prevented from accessing the secure server.”)
in response to determining that the first user is not authenticated,
(See Bronstein, para. [0027]: “The authentication server 116 is a device or collection of devices operable to perform an initial authorization of the requesting user 104 using single-user authentication (e.g., based on a security credential or the like provided with the user's request 106 to access the secure server 108). The authentication server 116 includes authentication instructions 118 which include any instructions, code, or rules for determining whether the requesting user 104 is initially authorized to request access to the secure server 108. For example, the authorization instructions 118 may include code for implementing a comparison of security credentials, such as a username and password combination, provided by the user 104 to a set of combinations of usernames and passwords that are associated with authorized users of the secure server 108. If the user 104 fails to pass this initial authentication (e.g., if the username and password do not match a predetermined username and password), then the user 104 may be denied access to the secure server 108. Otherwise, if the user 104 passes this initial authentication (e.g., if the username and password match a predetermined username and password), then further authentication tasks are performed by the multi-person authentication server 124 and user devices 102 a,b, 134 a,b. For example, a multi-person authentication request 122 may be directed to the multi-person authentication server 124, and user access may only be provided based on the confirmation/denial 140 of this access from the multi-person authentication server 124. The authentication server 116 may be implemented using the processor, memory, and interface of the device 1000 described below with respect to FIG. 10.”)
displaying a user interface including a push notification on the first computing device of the second user the push notification requesting a first authentication confirmation for the first user through an application on the first computing device of the second user, the application used to access the second user account of the second user on the first computing device of the second user;
(See Bronstein, Claim 1: “A system, comprising: a secure server configured to host one or more secure applications; and a multi-person authentication server comprising: a network interface configured to communicate with the secure server, a first user device associated with a first user, and a second user device associated with a second user; and a processor configured to: receive an authentication request corresponding to a request to provide the first user access to the secure server; in response to receiving the authentication request: provide a challenge-response message to the first user device, wherein the challenge-response message indicates authentication of the first user of the first user device is needed and directs the first user device to capture a first image of a face of the first user; provide a push notification to the second user device, wherein the push notification indicates confirmation of the authentication of the first user of the first user device is needed and directs the second user device to capture a second image of a face of the second user and provide the second image to the first user device; receive a response to the challenge-response message from the first user device, wherein: the response indicates the first user is authorized to access the secure server if the first image is an image of an authorized user of the secure server and the second image is an image of an administrator or user of the secure server, and the response indicates the first user is not authorized to access the secure server if one or both of: the first image is not the image of the authorized user of the secure server and the second image is not the image of the administrator of the secure server; if the received response indicates the first user is authenticated, allow the first user to access the secure server; and if the received response indicates the first user is not authenticated, prevent the first user from accessing the secure server.”)
receiving, using the processing circuitry, the first authentication confirmation for the first user from the first computing device of the second user at the application via the second user account of the second user;
determining that the first authentication confirmation meets the authentication level requirement of the first financial transaction; and
in response to determining that the first authentication confirmation meets the authentication level requirement, authorizing the first financial transaction on the first user account by the first user.
(See Bronstein, para. [0004]: “In another embodiment, a system includes a secure server and a first user device. The first user device includes a camera operable to capture a first image of a first user of the user device. The first user device receives a challenge-response message following a request for access to the secure server by the first user. Following receipt of the challenge-response message, the first user of the first user device is prompted to operate the camera to capture the first image of the first user. The first image includes an image of at least a portion of a face of the first user. A second image of a second user is received that includes an image of at least a portion of a face of the second user. Facial recognition is used to determine that the face of the first user included in the first image corresponds to a face of an authorized user of the secure server. Facial recognition is used to determine that the face of the second user included in the second image corresponds to a face of an authorized administrator of the secure server. The first user device generates a response to the challenge-response message. If both the face of the first user corresponds to the face of the authorized user of the secure server and the face of the second user corresponds to the face of the authorized administrator of the secure server, the response indicates the first user is authorized to access the secure server. If one or both of the face of the first user does not correspond to the face of the authorized user of the secure server and the face of the second user does not correspond to the face of the authorized administrator of the secure server, the response indicates the first user is not authorized to access the secure server.”)
However, under a conservative interpretation of Bronstein, it could be argued that Bronstein does not explicitly teach the italicized features below, which are taught by Pattar:
receiving an authorization request to complete a first financial transaction on the first user account from the first user, the first financial transaction having an authentication level requirement;
(See Pattar, para. [0002]: “A use of a single specific authentication method such as a password authentication or the digital certificate authentication at a level of authentication is known as single-factor authentication that identifies the user requesting access through only one category of credentials. Single-factor authentication for a system typically only requires a user to create an account by providing a username and associated password (e.g., a knowledge factor only authentication). Since passwords can easily end up in the wrong hands, this approach is not very secure. Therefore, enterprises and high-value web service providers such as banks often require alternative single factor authentication techniques or multi-factor authentication, e.g., at least a second factor, specifically for higher sensitive resources (e.g., higher level authentication applications). The multi-factor approach requires a user to present at least two factors of identification from a set of factors potentially including: (1) a knowledge factor; (2) a possession factor; and (3) an inherence factor. The knowledge factor refers to something the user knows, for instance a password, pin code or passphrase; the possession factor refers to something the user owns, for instance a security fob, a magnetic card, a cell phone, or a tablet computer; and the inherence factor refers to something the user is. The inherence factor could be determined using biometrics such as fingerprint, iris or voice analysis.”)
(See Patter, para. [0003]: “Single factor and multi-factor authentication techniques that include use of a username and associated password have proven to be cumbersome and bad security practice. In fact, many users and enterprises are looking at password-free technologies as their preferred method of authentication, both from a security and ease-of-use perspective. Among the most prominent password-free authentication methods are push notifications. Many enterprises have already provided push notification authentication alternatives for their consumer-facing products. Push notification authentication validates login attempts by sending access requests to an associated device (a possession factor). When a user registers their account, the user links the account to a device they possess. Afterwards, whenever the user tries to log in to their account, the user submits their username or ID. In addition to (multi-factor authentication) or instead of entering their password (single factor authentication), the user receives an access request notification on their device, which the user can approve or decline. The benefits of push notification authentication is that user does not need to memorize and manage passwords, and the notification provides a seamless and user-friendly experience. Additionally, validating an authentication request is often quicker using push notifications than entering a complex user name and password.”)
(See Pattar, para. [0046]: “FIG. 1B further illustrates an example of a push notification authentication session managed within a distributed environment implementing an access management system and push notification service 170. For example, a user may operate client device 105 to request access to resource 120 controlled by a distributed environment server 115. At step 171, the first application 130 (e.g., a web application) may be used by a user of the client device 105 to make an authentication request to a resource server such as the distributed environment server 115 for access to the resource 120. The distributed environment server 115 may call a login service (e.g., authentication service 155) of the identity management system 145 to evaluate an authentication policy for the requested resource 120. The login service returns the authentication policy based on the type of resource requested by the user. The policy indicates the resource requested and the level of authentication required for accessing the resource. In various embodiments, the level of authentication required includes use of a push notification as a part of a single or multi-factor authentication, and thus the authentication service 155 and the distributed environment server 115 realize that a push notification needs to be sent to a registered authentication application (e.g., the second application 180) for approval.”)
determining that the first user is not authenticated to complete the first financial transaction on the first user account based on the authentication level requirement;
(See Pattar, para. [0002]: “A use of a single specific authentication method such as a password authentication or the digital certificate authentication at a level of authentication is known as single-factor authentication that identifies the user requesting access through only one category of credentials. Single-factor authentication for a system typically only requires a user to create an account by providing a username and associated password (e.g., a knowledge factor only authentication). Since passwords can easily end up in the wrong hands, this approach is not very secure. Therefore, enterprises and high-value web service providers such as banks often require alternative single factor authentication techniques or multi-factor authentication, e.g., at least a second factor, specifically for higher sensitive resources (e.g., higher level authentication applications).”)
It would have been obvious to a person having ordinary skill in the art (PHOSITA), before the effective filing date of the claimed invention, to include in the method for “Multi-Person Authentication”, as taught by Bronstein above, with “Techniques for authentication using push notifications”, as further taught by Pattar above, because Bronstein para. [0027] teaches:
If the user 104 fails to pass this initial authentication (e.g., if the username and password do not match a predetermined username and password), then the user 104 may be denied access to the secure server 108. Otherwise, if the user 104 passes this initial authentication (e.g., if the username and password match a predetermined username and password), then further authentication tasks are performed by the multi-person authentication server 124 and user devices 102 a,b, 134 a,b.
Also, Pattar para. [0002] teaches:
Single-factor authentication for a system typically only requires a user to create an account by providing a username and associated password (e.g., a knowledge factor only authentication). Since passwords can easily end up in the wrong hands, this approach is not very secure. Therefore, enterprises and high-value web service providers such as banks often require alternative single factor authentication techniques or multi-factor authentication, e.g., at least a second factor, specifically for higher sensitive resources (e.g., higher level authentication applications).
In regards to claim 2,
2. (Original) The method of claim 1,
wherein linking the first user account to the second user account includes at least one of adding the second user account to a first profile of the first user, or adding the first user account to a second profile of the second user.
(See Bronstein, para. [0003]: “In an embodiment, a system includes a multi-person authentication server which receives an authentication request corresponding to a request to provide a first user access to a secure server. In response to the authentication request, a challenge-response message is provided to the first user device. The challenge-response message indicates authentication of the first user of the first user device is needed and directs the first user device to capture a first image of a face of the first user. A push notification is also provided to a second user device. The push notification indicates confirmation of the authentication of the first user of the first user device is needed and directs the second user device to capture a second image of a face of the second user and provide an authentication result to the first user device. A response to the challenge-response message is received from the first user device. The response indicates the first user is authorized to access the secure server if the first image is an image of an authorized user of the secure server and the second image is an image of an administrator of the secure server. The response indicates the first user is not authorized to access the secure server if one or both of the following are true: (1) the first image is not the image of the authorized user of the secure server and (2) the second image is not the image of the administrator of the secure server. If the received response indicates the first user is authenticated, the first user is allowed to access the secure server. If the received response indicates the first user is not authenticated, the first user is prevented from accessing the secure server.”)
The Examiner interprets that Bronstein inherently has the claimed features, otherwise it is impossible to implement Bronstein’s features of “A push notification is also provided to a second user device. The push notification indicates confirmation of the authentication of the first user of the first user device is needed and directs the second user device to capture a second image of a face of the second user and provide an authentication result to the first user device”.
In regards to claim 3,
3. (Original) The method of claim 1, further comprising:
adding a contact information of a third party to a first profile of the first user,
receiving a second authorization request to complete a second financial transaction on the first user account, the second financial transaction having a second authentication level requirement;
sending to a second computing device of the first user a second authentication request for the first user;
in response to receiving an indication from the first user, sending an authentication confirmation check to the contact information of the third party;
receiving, using the processing circuitry, a second authentication confirmation;
determining that the second authentication confirmation meets the second authentication level requirement of the second financial transaction; and
in response to the determination, authorizing the second financial transaction on the first user account.
(See Pattar, para. [0049]: “At step 174, the push notification service 170 forwards the first push notification to the second application 180 on the client device 105 or another client device based on the unique identifiers for the second application 180 and/or the client device 105 or another client device. In various embodiments, the push notification service 170 unpacks the notification data from the first push notification and uses the unique identifiers for the second application 180 and/or the client device 105 or another client device to look up registration data for the client device 105 or another client device. The registration data includes information on how to contact the client device 105 or another client device such as an IP address. Thereafter, the second application 180 receives the first push notification, and parses the first push notification to obtain the notification data and the message. One of the benefits of push notifications is that they can be interactive and users can take action on messages in the notification by responding to the push notification. For example, the push notification may include a code or question that the user of the client device 105 or another client device can read, interpret and respond to via the second application 180 and/or the client device 105 or another client device. In its simplest form, the reply by the user may be acceptance or denial that the user did generate the request for access to resource 120 on the first application 130.”)
In regards to claim 4,
4. (Original) The method of claim 3, wherein adding the contact information of the third party to the first profile of the first user includes registering the third party at the financial institution.
(See Pattar, para. [0003]: “Single factor and multi-factor authentication techniques that include use of a username and associated password have proven to be cumbersome and bad security practice. In fact, many users and enterprises are looking at password-free technologies as their preferred method of authentication, both from a security and ease-of-use perspective. Among the most prominent password-free authentication methods are push notifications. Many enterprises have already provided push notification authentication alternatives for their consumer-facing products. Push notification authentication validates login attempts by sending access requests to an associated device (a possession factor). When a user registers their account, the user links the account to a device they possess. Afterwards, whenever the user tries to log in to their account, the user submits their username or ID. In addition to (multi-factor authentication) or instead of entering their password (single factor authentication), the user receives an access request notification on their device, which the user can approve or decline. The benefits of push notification authentication is that user does not need to memorize and manage passwords, and the notification provides a seamless and user-friendly experience. Additionally, validating an authentication request is often quicker using push notifications than entering a complex user name and password.”)
In regards to claim 5,
5. (Currently Amended) The method of claim 3,
wherein the authentication confirmation check requests at least one of typing a one-time confirmation code sent to the contact information of the third party on the second computing device of the first user,
replying to a message sent to the contact information of the third party requesting to confirm the authentication of the first user,
clicking on a link included in a message sent to the contact information of the third party to confirm the authentication of the first user, or
pressing a key as requested in a call to the contact information of the third party to confirm the authentication of the first user.
(See Pattar, para. [0048]: “At step 173, the notification publisher 185 composes a message for the first push notification, for example, an automatic message composed through a message composer, based on the authentication policy for the requested resource 120 and prepares notification data to be sent with the message. In some embodiments, the message is composed as a notification that a user is trying to access a resource and the server needs confirmation that the user is who they say they are; thus, prompting the user to accept or deny confirmation. In other embodiments, the message is a code or question prompted by the user trying to access a resource and the server needs the user to respond with the code or answer to confirm that the user is who they say they are; thus, prompting the user to provide the code or answer. The notification publisher 185 defines the audience such as the client device 105 or another client device to whom the first push notification will be sent. In certain embodiments, the notification publisher 185 may determine whether the first push notification should be sent immediately or in accordance with a schedule.”)
In regards to claim 6,
6. (Previously Presented) The method of claim 1, further comprising:
registering a third computing device of a third party to the first user account;
receiving a third authorization request to complete a third financial transaction on the first user account, the third financial transaction having a third authentication level requirement;
sending to the first computing device of the second user a third authentication request for the first user;
receiving, using the processing circuitry, a third authentication confirmation by the second user at the application via the second user account;
determining that the third authentication confirmation does not meet the third authentication level requirement of the third financial transaction;
in response to the determination, sending a fourth authentication request to the third computing device;
receiving a fourth authentication confirmation, the fourth authentication confirmation including information indicative of at least one of a tapped credit card on the third computing device of the third party, an entered confirmation code on the third computing device of the third party, or a confirmed authentication on a second application on the third computing device of the third party;
determining that the fourth authentication confirmation meets the third authentication level requirement of the third financial transaction; and
in response to the determination, authorizing the third financial transaction on the first user account.
(See Pattar, para. [0048]: “At step 173, the notification publisher 185 composes a message for the first push notification, for example, an automatic message composed through a message composer, based on the authentication policy for the requested resource 120 and prepares notification data to be sent with the message. In some embodiments, the message is composed as a notification that a user is trying to access a resource and the server needs confirmation that the user is who they say they are; thus, prompting the user to accept or deny confirmation. In other embodiments, the message is a code or question prompted by the user trying to access a resource and the server needs the user to respond with the code or answer to confirm that the user is who they say they are; thus, prompting the user to provide the code or answer. The notification publisher 185 defines the audience such as the client device 105 or another client device to whom the first push notification will be sent. In certain embodiments, the notification publisher 185 may determine whether the first push notification should be sent immediately or in accordance with a schedule.”)
In regards to claim 7,
7. (Original) The method of claim 6, wherein the entered confirmation code includes at least one of a PIN, a swipe gesture, or a biometric recognition parameter.
(See Pattar, para. [0048]: “At step 173, the notification publisher 185 composes a message for the first push notification, for example, an automatic message composed through a message composer, based on the authentication policy for the requested resource 120 and prepares notification data to be sent with the message. In some embodiments, the message is composed as a notification that a user is trying to access a resource and the server needs confirmation that the user is who they say they are; thus, prompting the user to accept or deny confirmation. In other embodiments, the message is a code or question prompted by the user trying to access a resource and the server needs the user to respond with the code or answer to confirm that the user is who they say they are; thus, prompting the user to provide the code or answer. The notification publisher 185 defines the audience such as the client device 105 or another client device to whom the first push notification will be sent. In certain embodiments, the notification publisher 185 may determine whether the first push notification should be sent immediately or in accordance with a schedule.”)
In regards to claim 8, it is rejected on the same grounds as claim 1.
In regards to claim 9, it is rejected on the same grounds as claim 2.
In regards to claim 10, it is rejected on the same grounds as claim 3.
In regards to claim 11, it is rejected on the same grounds as claim 4.
In regards to claim 12, it is rejected on the same grounds as claim 5.
In regards to claim 13, it is rejected on the same grounds as claim 6.
In regards to claim 14, it is rejected on the same grounds as claim 7.
In regards to claim 15, it is rejected on the same grounds as claim 1.
In regards to claim 16, it is rejected on the same grounds as claim 2.
In regards to claim 17, it is rejected on the same grounds as claim 3.
In regards to claim 18, it is rejected on the same grounds as claim 4.
In regards to claim 19, it is rejected on the same grounds as claim 5.
In regards to claim 20, it is rejected on the same grounds as claim 6.
Response to Amendments
Re: Claim Rejections - 35 USC § 101
In response to Applicant’s amendments to the claims, the 35 U.S.C. 101 rejections have been amended.
Re: Claim Rejections - 35 USC § 103
In response to Applicant’s amendments to the claims, new 35 U.S.C. 103 rejections have been added.
Conclusion
Applicants are invited to contact the Office to schedule an in-person interview to discuss and resolve the issues set forth in this Office Action. Although an interview is not required, the Office believes that an interview can be of use to resolve any issues related to a patent application in an efficient and prompt manner.
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.
Any inquiry concerning this communication or earlier communications should be directed to Examiner Ayal Sharon, whose telephone number is (571) 272-5614, and fax number is (571) 273-1794. The Examiner can normally be reached from Monday to Friday between 9 AM and 6 PM. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, SPE Christine Behncke can be reached at (571) 272-8103 or at christine.behncke@uspto.gov. The fax 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.
Sincerely,
/Ayal I. Sharon/
Examiner, Art Unit 3695
May 5, 2026
Prosecution Insights