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 .
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Drawings
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(4) because:
Regarding Fig. 1:
The drawing does not include reference sign(s) mentioned in the description. Specifically, ¶ 0033, inter alia, of the specification recites, “The environment 100 includes a graphical user interface (GUI) 132 on a financial institution application web server 106”. Reference character “132” is not represented in the drawings.
Regarding Fig. 2:
It includes the following reference character(s) not mentioned in the description: “206.”
Regarding Fig. 9:
It includes the following reference character(s) not mentioned in the description: “904.”
Regarding Fig. 10:
In specification ¶ 0158, reference character “1044” has been used to designate both “virtual machine” and “virtual machine monitor.”
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION. — The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claim(s) 8 and 17 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Regarding claim(s) 8 and 17:
Claim 8 recites, “… monitoring … for types of transactions comprising low-risk activities; and suggesting a change to the passkey type based on the monitoring.” Claim(s) 17 recite similar language. The claims are indefinite because the metes and bounds of the claim are unclear. It is unclear what sort of change to a passkey type is suggested based on detection of a low-risk activity. Based on the context of sibling claims 7 and 16, one might assume that a passkey with lower security is suggested; however, the claim language is ambiguous as to whether this is the case, and the specification offers no further insight (¶ 0100 of the specification essentially repeats the language of the claims). Where one of ordinary skill in the art would understand that when detecting a high-risk activity, that a higher-security type may be suggested or enforced, the opposite does not hold true. Downgrading to lower security measures based simply on a low-risk activity being performed, where at any time higher-risk transactions may be performed that require reverting back to higher security measures, would be highly unusual in the art, and there is no reasoning provided which positively affirm that this is the intended interpretation of the claim. This rejection can be overcome by amending the claims such that they more clearly recite the actions being claimed, provided those actions are supported by the original disclosure.
Claim Rejections - 35 USC § 103
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.
Claims 1, 4-6, 10, 13-15, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over CHAU et al (Doc ID US 20250030678 A1), and further in view of IANNELLI et al (Doc ID US 20260080410 A1).
Regarding claim 1:
CHAU teaches:
A system for managing digital authentication in a financial application, the system comprising: one or more hardware processors of a machine; and at least one memory storing instructions that, when executed by the one or more hardware processors, cause the system to perform operations comprising ([0049] "… The computer programs typically comprise one or more instructions (e.g., instructions 504, 508, 528) set at various times in various memory and storage devices in computing device(s). When read and executed by the processor 502, the instruction(s) cause the computing system 500 to perform operations ..."):
causing a user interface to be displayed to a user of the financial application, the user interface comprising a passkey control center for providing a centralized passkey management console associated with the financial application ([0040] "… the web domain can cause the browser application to display an example interface 420 illustrated in FIG. 4B. The interface 420 includes an option 422 to sign in with a passkey.");
receiving, via the user interface, user input, the user input comprising a user-specified authentication preference for a passkey type ([0042] "When the user selects the option in FIG. 4B to log in with a passkey, an interface ... can be displayed. The interface 440 includes options 442 to select the device where the passkey is stored.");
confirming the user-specified authentication preference for the passkey type based on the passkey permission to identify a passkey to employ for the financial service ([0042] "... if the passkey is stored on the device the user is currently using, the browser application may automatically present the passkey and cause the interface 440 to be bypassed. If the user selects the option 442C to access a passkey on a different device, the web domain can cause the browser application to display an interface such as the interface 450 depicted in FIG. 4E."); and
IANNELLI teaches the following limitation(s) not taught by CHAU:
associating the passkey type with a passkey permission based on the user input ([0022] "The purchaser could then authorize the use of his or her passkeys though various authentication mechanisms offered by the client device 100.");
receiving, via the user interface, a request for a financial service associated with the financial application ([0046] "The public passkey 1833 represents the public key of a public-private key pair used for authentication of a registered purchaser using the WebAuthN protocol.");
authenticating the financial service using the passkey ([0103] "If, after evaluating the information included in the prompt presented at block 2021a, the user chooses to authorize the transaction using the private passkey 1866 of the user, then the process can proceed to block 2023a.").
Allowing a user to choose a passkey authentication method via a user interface, and authenticating a is/are known technique(s) in the art, as demonstrated by CHAU. Further, using passkeys for authorizing transactions is/are known technique(s) in the art, as demonstrated by IANNELLI. 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 modify the passkey selection and user interface of CHAU with the passkey enabled transaction authorization of IANNELLI with the motivation to provide transaction services to a user which is already logged in so that additional authentication is not required to conduct the transactions.
Regarding claim 4:
The combination of CHAU and IANNELLI teaches:
The system of claim 1, wherein the passkey type comprises one of a device-bound passkey or a cloud-synced passkey (CHAU [0042] "... option 442A if the passkey is stored on the device the user is currently using, option 442B if the passkey is stored on a mobile device that is at least partially synchronized with the device used by the user …").
Regarding claim 5:
The combination of CHAU and IANNELLI teaches:
The system of claim 4, wherein the user-specified authentication preference includes: identifying an allowed authentication method for the device-bound passkey (CHAU [0018] "… the browser application 112 calls the authenticator 114 to authenticate the passkey 116, at operation 145, based on the selected credential. ... For example, the authenticator 114 may request a device password or screen lock passcode from the user or a fingerprint scan, a face scan, or a voice fingerprint of the user.").
Regarding claim 6:
The combination of CHAU and IANNELLI teaches:
The system of claim 4, the operations further comprising: defining a usage context for the cloud-synced passkey to be used within the financial application based on a contextual factor (CHAU [0042] "When the user selects the option in FIG. 4B to log in with a passkey, an interface ... can be displayed. The interface 440 includes options 442 to select the device where the passkey is stored.").
Regarding claim(s) 10, 13-5, and 19:
The listed claim(s) is/are rejected with the same justification, mutatis mutandis, as its/their counterpart claim(s) 1 and 4-6 above.
Claims 2, 3, 11, 12, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over CHAU et al (Doc ID US 20250030678 A1) and IANNELLI et al (Doc ID US 20260080410 A1) as applied to claims 1, 10, and 19 above, and further in view of BADHWAR et al (Doc ID US 20210194883 A1).
Regarding claim 2:
The combination of CHAU and IANNELLI teaches:
The system of claim 1,
BADHWAR teaches the following limitation(s) not taught by the combination of CHAU and IANNELLI:
the operations further comprising: monitoring a financial transaction to confirm conformance to the user-specified authentication preference for the passkey ([0055] "... Once an action is detected, the server system assesses the risk of the action of the user on the web application to determine whether a step-up authentication is required to re-authenticate and authorize the user to perform the action (step 214).").
Monitoring whether a transaction can be completed based on the type of transaction and current authentication is/are known technique(s) in the art, as demonstrated by BADHWAR. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the passkey manager and passkey transaction authorization of CHAU and IANNELLI with the authentication security monitoring of BADHWAR with the motivation to ensure that a passkey chosen to authenticate a user is sufficient for a transaction being attempted by the user.
Regarding claim 3:
The combination of CHAU, IANNELLI, and BADHWAR teaches:
The system of claim 2,
BADHWAR teaches the following limitation(s) not taught by the combination of CHAU, IANNELLI, and BADHWAR:
the operations further comprising: determining a risk level of the financial transaction based on the user-specified authentication preference ([0063] "… the server system assesses the action that the user is requesting. To assess the requested action, the server system calculates a cumulative action risk score for the requested action …"); and
selecting a corresponding passkey based on the user-specified authentication preference and the risk level of the financial transaction ([0058] "... the server system also assesses which step-up authentication method to provide .... For example, if a cumulative risk score ... exceeds a threshold risk score, the system determines that a strong step-up authentication method ... is required. In contrast, if a cumulative risk score ... is lower than a threshold risk score, the system determines that a weaker step-up authentication method ... is sufficient ...").
Upgrading an authentication measure based on the risk of a requested transaction is/are known technique(s) in the art, as demonstrated by BADHWAR. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the passkey manager and passkey transaction authorization of CHAU, IANNELLI, and BADHWAR with the authentication security monitoring of BADHWAR with the motivation to ensure that a passkey chosen to authenticate a user is sufficient for a transaction being attempted by the user, and to require additional security for transactions that are too risky for the currently selected measure.
Regarding claims 11, 12, and 20:
These claims are rejected with the same justification, mutatis mutandis, as their counterpart claims 2 and 3 above.
Claims 7, 8, 16, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over CHAU et al (Doc ID US 20250030678 A1) and IANNELLI et al (Doc ID US 20260080410 A1) as applied to claims 1, 4, 10, and 13 above, and further in view of KAPUR et al (Doc ID US 20240214194 A1).
Regarding claim 7:
The combination of CHAU and IANNELLI teaches:
The system of claim 4,
KAPUR teaches the following limitation(s) not taught by the combination of CHAU and IANNELLI:
the operations further comprising: identifying a high-risk financial service ([0275] "… a high-security service may only allow access using a key X1 ...; whereas a lower-security service may provide access based on either key X1 and/or key X2 …"); and
restricting the high-risk financial service to the device-bound passkey ([0275] "… a high-security service may only allow access using a key X1 ...; whereas a lower-security service may provide access based on either key X1 and/or key X2 …").
Identifying high-risk transactions and requiring authentication measures with higher security for them is/are known technique(s) in the art, as demonstrated by KAPUR. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the passkey manager and passkey transaction authorization of CHAU and IANNELLI with the transaction risk monitoring of KAPUR with the motivation to prevent lower security authentication measures from being used when a user is engaged in a high risk transaction, and to allow upgraded authentication to be used to authorize the transaction instead.
Regarding claim 8:
The combination of CHAU and IANNELLI teaches:
The system of claim 1,
KAPUR teaches the following limitation(s) not taught by the combination of CHAU and IANNELLI:
the operations further comprising: monitoring the passkey control center for types of transactions comprising low-risk activities ([0275] "… a high-security service may only allow access using a key X1 ...; whereas a lower-security service may provide access based on either key X1 and/or key X2 …"); and
suggesting a change to the passkey type based on the monitoring ([0275] "… a high-security service may only allow access using a key X1 ...; whereas a lower-security service may provide access based on either key X1 and/or key X2 …").
Identifying low-risk transactions and allowing authentication measures with lower security for them is/are known technique(s) in the art, as demonstrated by KAPUR. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the passkey manager and passkey transaction authorization of CHAU and IANNELLI with the transaction risk monitoring of KAPUR with the motivation to allow a user to switch to a device which may only have access to security measures which are appropriate for low risk transactions.
Regarding claims 16 and 17:
These claims are rejected with the same justification, mutatis mutandis, as their counterpart claims 7 and 8 above.
Claims 9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over CHAU et al (Doc ID US 20250030678 A1) and IANNELLI et al (Doc ID US 20260080410 A1) as applied to claims 1 and 10 above, and further in view of ABBASIAN et al (Doc ID US 20190370456 A1).
Regarding claim 9:
The combination of CHAU and IANNELLI teaches:
The system of claim 1,
ABBASIAN teaches the following limitation(s) not taught by the combination of CHAU and IANNELLI:
wherein the passkey control center is implemented as a container within a security center of the financial application ([0032] "… external credential metadata 124 and credential manager 130 are included with in a sandbox container 230 instantiated by OS 120 in memory 102.").
Identifying low-risk transactions and allowing authentication measures with lower security for them is/are known technique(s) in the art, as demonstrated by ABBASIAN. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the passkey manager and passkey transaction authorization of CHAU and IANNELLI with the transaction risk monitoring of ABBASIAN with the motivation to allow a user to switch to a device which may only have access to security measures which are appropriate for low risk transactions.
Regarding claim 18:
This claim is rejected with the same justification, mutatis mutandis, as its counterpart claim 9 above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRANDON BINCZAK whose telephone number is (703) 756-4528. The examiner can normally be reached M-F 0800-1600 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, Alexander Lagor can be reached on (571) 270-5143. 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.
/BB/Examiner, Art Unit 2437
/MENG LI/Primary Examiner, Art Unit 2437
Prosecution Insights