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 .
Response to Arguments
Applicant’s arguments, see pages 9-11, filed 07/20/2026, with respect to the rejection(s) of claim(s) 1-5, 8-15 and 18-20 under 35 U.S.C. 103 as being unpatentable over Ross et al. (US 20190334884 A1 –hereinafter—"Ross”) in view of Dods et al (US 12105842 B1 –hereinafter – “Dods”) have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of SHAH et al. (US 20160087957 A1 –hereinafter – “SHAH”).
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.
Claims 1-5, 8-15 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Ross et al. (US 20190334884 A1 –hereinafter—"Ross”) in view of Dods et al (US 12105842 B1 –hereinafter – “Dods”) in further view of SHAH et al. (US 20160087957 A1 –hereinafter – “SHAH”).
As per claim 1. Ross discloses a computer-implemented method for multi-factor authentication, the method comprising:
receiving, by one or more processors, a user transaction request ([0134] a customer authentication and authorization system 1400 as shown in FIG. 14 provides for highly contextual and secure digital transactions between challenge origins and mobile device users interacting with and responding to challenges related to an attempted remote service initiation. The system 1400 transforms existing remote service applications 1402 into strong customer authenticators and authorizers. Challenge origins 1404 that provide remote services use the authorization service (AS or AuthService) server 1406 to send users challenges, a new form of secure engagement within apps, an AS may include a single IDP to provide an authorization service that is part of the services of a remote service provider embedded within a remote service provider framework and the remote service provider the ability to open up a secure channel with a mobile device user 1408 during a transaction involving one or more of the remote service provider's remote services. [0135] Challenges 2002 include traditional identity assertions, confirmations of intent, and any type of message that may require a response. Provides a streaming service including: a customer service system, a transactional service system, and a voice clients system, account change acknowledgements, fraud alerts and responses, purchase confirmations, execution of contracts and legal agreements, execution of regulatory compliance forms, call center authentication, user registration and permissions, Internet of Things (IoT) device account linking and identification, trade and payment confirmations, wire transfer approvals, etc. [0136] Challenges include transaction intent verification related challenges including, for example, purchase and payment confirmations (PSD2 SCA), wire transfer approval, funds transfer, financial account linking, fraud alerts);
generating, by the one or more processors, an authentication request data object in response to the user transaction request ([0016] creating an authentication token comprising a public key portion and a private key portion. The created authentication token may be specific to a user credential of a mobile device user and the authorization service computer readable program code. The created authentication token may be configured to be used by the mobile device user to authorize one or more remote services. [0139] The AuthService code residing on the mobile device 1410 create the respective authentication token, store a respective private key portion of the respective authentication token on the mobile device 1410, and prevent transmission of the respective private key portion of the respective authentication token from the respective mobile device 1410. The AuthService code cause a processor on the mobile device to create the respective access token, store a respective private key portion of the respective access token on the mobile device 1410, and prevent transmission of the respective private key portion of the respective access token from the respective mobile device 1410. [0142] Receiving challenge information from the AuthService server 1406 including information indicative of an action to initiate one of the one or more remote services. The challenge information is authorization challenge information. Enabling the input of a user credential 2102 from the mobile device user 1408. In response to receiving the challenge information, the AuthService code validating a received user credential 2102 by attempting to decrypt the stored private key portion of the created authentication token. If the received user credential 2102 is validated by the AuthService code, transmitting one or more messages to the AuthService server 1406. [0148] The AuthService server 1406 may require a mobile library on a mobile device 1410 to create a new authentication token (e.g., asymmetric key pair) at a predetermined periodicity, store the private key portion of the newly generated authentication token. Cryptographic code within the AuthService code of the remote service application 1402 may encrypt the private key portion of the newly generated authentication token, and store the encrypted private key.)
wherein the authentication request data object comprises an authentication code and a link ([0012] The created authentication token is specific to an electronic mail address, or anonymous identifier, of an Internet user, a user credential of the Internet user, a device identifier for each of one or more devices including the device, and the identity provider application. A web browser of the device displaying one or more of a plurality of web pages, where each web page belongs to a respective Internet service provider, and where each respective web page includes a respective link usable to request access by the Internet user to a respective one of the respective one or more Internet services provided by the respective Internet service provider. Receiving a respective selection of the respective link on each of the displayed one or more web pages and, in response to receiving each respective selection of the respective link on the displayed one or more web pages, and the web browser transmitting, to a web server of the Internet service provider, a respective electronic signal including content indicative of a respective identifier for the respective one of the respective one or more Internet services provided by the respective Internet service provider, displaying content of a respective first web page belonging to the single identity service provider at a respective first Internet address of the single identity service provider in response to receiving a respective API call from the web server of the single identity service provider, transmitting, to a web server of the single identity provider, a respective electronic signal including content indicative of an electronic mail address, or an anonymous identifier, of the Internet user, and displaying content of a respective second web page belonging to the single identity service provider at a respective second Internet address of the single identity service provider in response to receiving a respective API call from the web server of the single identity service provider, where the content of the second web page includes a respective visually perceptible identifier of the respective Internet service provider, the electronic mail address, or the anonymous identifier, of the Internet user, and a respective Internet address of the respective web page belonging to the respective Internet service provider);
delivering, by the one or more processors, the authentication request data object, including the authentication code and the link, to a pre-registered contact identifier ([0085] a pre-registered device of the Internet user is initiated to display a page to receive an input of a user credential of the Internet user (e.g. PIN, biometric factor, combination thereof) in response to the successful validation of the respective Internet user's identifier received by the single IDP (e.g. FIGS. 5A, 5B). Single IDP core (150, 250) requires the dID app 850 to display the page to input the Internet user credential. The processor of device automatically initiates dID app 850 in response to receiving an API call from a server (e.g. 352) of the single IDP (150, 250). A notification to the Internet user displayed on a web page of the single IDP (e.g. FIGS. 5C, 5D) instructs the Internet user to initiate the dID app 850 to display the page to input the Internet user credential. An Internet user may launch the dID application 750 by pressing (or clicking, or otherwise activating) an icon (or other suitable hypertext, image, hot spot, etc.) of the web page depicted in the examples of FIGS. 5A and 5B displayed on web browser 710. Referring to FIG. 5F, dID app 850 residing on the pre-registered device (e.g. 804, 104, 106) of the Internet user displays a page that displays a respective visually perceptible identifier of the respective RP 160-i (e.g. RP name (“Relying Party X”, RP image (key hole image)) (e.g. FIGS. 5C, 5D), a respective Internet address of a respective web page belonging to the respective RP 160-i (e.g. “https://www.relyingpartyX.com/InternetServiceA”) (e.g. FIGS. 5C, 5D), a date identifier (e.g. the date (e.g. “11/31/2014” of the Internet user's selection of a link displayed on the respective RP's web page (e.g. FIGS. 4A, 4B)), a time identifier (e.g. the time (e.g. “10:28:49 AM EDT” of the Internet user's selection of a link displayed on the respective RP's web page (e.g. FIGS. 4A, 4B)), and a verification code generated by the single IDP (e.g. “IUZ23”) (e.g. FIGS. 5C, 5D), in response to the successful validation of the respective Internet user's credential received by the dID app 850 (e.g. FIG. 5E), and requiring an input (e.g. selection of “Accept” or selection of “Reject”) from the Internet user to generate and/or transmit an approved authentication challenge message via an API call to a server (e.g. 352) of the single IDP. In various embodiments, dID app 850 automatically generates and transmits an approved authentication challenge message via an API call to a server (e.g. 352) of the single IDP in response to the successful validation of the respective Internet user's credential received by the dID app 850 (e.g. FIG. 5E).
receiving, by the one or more processors, a response data object from a user selecting the link, wherein the response data object is associated and the authentication code ([0087] an Internet user interface to relying party Internet services . The respective web browser of the respective Internet user is re-directed by the single IDP (150, 250) to a pre-registered call-back Internet address for the respective Internet service of the respective RP in response to the single IDP successfully validating the received approved authentication challenge message transmitted from dID app 850, and the web browser of the respective Internet user displays a web page, such as the web page depicted in the example of FIG. 5H, that indicates the single IDP (150, 250) has authorized access by the respective Internet user to the respective requested Internet service. In various embodiments, in response to successful validation of the received approved authentication challenge message transmitted from dID app 850, the single IDP automatically generates, and transmits to the web browser, a web page such as the web page depicted in the example of FIG. 5H. [0092] In an out-of-band interaction from dID app 850, another application residing on a device (e.g. an electronic mail application, an Internet user account at a website of the single IDP accessible by a web browser application) may display a page to receive an input from an Internet user (e.g. a click (or press, or otherwise activate)) a hypertext (or hot spots, such as buttons, or an image) “here” or the like on the page including an active link. In various embodiments, the single IDP service core (150-N, 250-N) may generate the page displayed at the another application residing on a device to activate a dID app 850 created authentication token of the Internet user. In various embodiments, the single IDP service core (150-N, 250-N) may generate the page displayed at the another application residing on a device, and transmit the generated page to the another application in an out-of-band interaction from dID app 850, in response to receiving a public key portion of the dID app 850 created authentication token of the Internet user via an API call from dID app 850. In various embodiments, the single IDP service core (150-N, 250-N) may generate the page displayed at the another application residing on a device to include an active link associated with a pseudorandom activation code generated by the single IDP service core (150-N, 250-N) in response to receiving a public key portion of the dID app 850 created authentication token of the Internet user via an API call from dID app 850);
validating, by the one or more processors, a user authentication based on the received response data object ([0087] The respective web browser of the respective Internet user is re-directed by the single IDP (150, 250) to a pre-registered call-back Internet address for the respective Internet service of the respective RP in response to the single IDP successfully validating the received approved authentication challenge message transmitted from dID app 850, and the web browser of the respective Internet user displays a web page, such as the web page depicted in the example of FIG. 5H, that indicates the single IDP (150, 250) has authorized access by the respective Internet user to the respective requested Internet service. In response to successful validation of the received approved authentication challenge message transmitted from dID app 850, the single IDP automatically generates, and transmits to the web browser, a web page such as the web page depicted in the example of FIG. 5H. [0097 -0098] The dID Application: Authentication Token Generation and Management. After an Internet user registers and/or validates his/her, and/or his/her device's, identity information with authentication engine (120, 220) of the single IDP, the dID app 850 may generate an authentication token including an asymmetric key pair (private key portion and corresponding public key portion) using a cryptographically secure algorithm );
authorizing, by the one or more processors, a transaction associated with the user transaction request upon successful validation of the user authentication ([0056] after the single IDP validates the transmitted approved authentication challenge response, the single IDP service can re-direct a web browser of the Internet user to an RP Internet service Internet address that is pre-registered with the single IDP (e.g. a call-back Internet address of the RP Internet service) to authorize the Internet user's access to the requested RP Internet service with a validation token (e.g. an Internet service identifier, an Internet service secret, and/or combinations thereof), and the RP providing the RP Internet service can then confirm the authenticity of the validation token with the single IDP. [0068] The authentication engine 120 of the single IDP manages and provides multifactor device based authentication capabilities for IDP service core (150, 250)of the single IDP to authorize respective access by each of a plurality of Internet users to a respective one or more Internet services provided by each of a plurality of Internet accessible RPs, dID application (FIG. 1), RPs 160-i (260-i), and respective Internet services provided by each of the RPs, including without limitation the operations of Internet user(s), Internet user device(s), RP(s), and RP(s)' services, registration, validating Internet user(s), Internet user device(s), RP(s), and RP(s)' services, registration information, encrypting and decrypting information, binding key portions of authentication tokens and Internet user and/or Internet user device information, generating authentication challenge request notification messages, and/or validating Internet user authentication requests to access Internet services provided by RPs).
Ross does not explicitly disclose a pre-registered contact identifier associated with a decentralized identity; wherein the response data object is associated with the decentralized identity. Dods, in analogous art, however, discloses a pre-registered contact identifier associated with a decentralized identity; wherein the response data object is associated with the decentralized identity (Column 3: lines 62-67, column 4: lines 1-10: Implement passwordless authentication, implementations can support removing the need for the user to enter any login credentials to sign in. Passwordless authentication methods may involve the use of biometric factors (e.g., FaceID), possession factors (e.g., a private key being held on a user's device), and “magic links”. So-called magic links entail sending the user a URL directing to a one-time-use embedded toke via a messaging platform, such as email or text messaging. A magic link can be a method of passwordless authentication involving entering a user identifier (e.g., email address) at a sign-in screen on a web endpoint, receiving a message with a one-time pin (OTP) code, and using that OTP code to sign in. Column 6: lines 17-26: (37) Decentralized identifiers (DIDs) are a type of globally unique identifier that enables an entity to be identified in a manner that is verifiable, persistent (as long as the DID controller desires), and does not require the use of a centralized registry. (See e.g., //www.w3.org/TR/did-core/incorporated herein by reference for all purposes), DIDs enable a new model of decentralized digital identity that is often referred to as self-sovereign identity or decentralized identity. (See e.g., //ec.europa.eu/futurium/en/system/files/ged/eidas_supported_ssi_may_2019_0.pdf incorporated herein by reference for all purposes), They are an important component of decentralized web applications. Column 7: line 20-40 The decentralized identity authentication (i.e., leveraging self-sovereign credentials to achieve bidirectional authentication between two actors using a messaging platform, VCs, and secure web endpoints) enable a Sender and a Recipient to authenticate each other's identity with an additional factor of authentication. Within authentication systems, users are able to authenticate themselves to verify their identity in order to access a service or resource. Once registered within a service (i.e., granted a token and credentials, often including certain access credentials authorizing the user to access specific data or functions), a user may authenticate themselves to access the service by providing one or more previously enrolled authentication factors to an authentication server. At the simplest level, authentication may involve a single factor; i.e., only requiring one authentication factor in order to authenticate a user such as a knowledge factor (e.g., password, passphrase, personal identification number (PIN), security questions, etc.), a possession factor (e.g., ID card, physical keystore, user device provisioned with a built-in hardware token or a software token, etc.), or an inherence factor (e.g., a biometric input like FaceID or a fingerprint scan). Column 8: lines 18-30: Users are provided with a magic link (sent via email, SMS, and so on) that enable the user to authenticate themselves via the use of OTP codes or XATP tracing. Magic link systems are advantageous in passwordless authentication in that they are relatively straightforward and accessible to implement in most scenarios (comparatively speaking to many other forms of passwordless authentication). The disadvantages of magic link systems, include security risks such as reliance on messaging system security and vulnerability to man-in-the-middle attacks. Moreover, magic links specifically (and passwordless authentication generally) tend to enable authentication for registered users on a given system; recipients who are not registered as part of the system are unable to participate. As a result, participants from disparate systems are unable to mutually authenticate each other without needing to register on one system or another (which may not be feasible), and thus fall back on insecure and unreliable methods of information exchange. New solutions are needed to address the security and feasibility problems associated with magic links).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations the pre-registered contact identifier is disclosed by Ross is associated with a decentralized identity and wherein the response data object is associated with the decentralized identity. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide a verifiable credentialing and message content provenance authentication, and to leverage decentralized identity authentication of verifiable credentials to achieve bidirectional authentication between two actors and content provenance authentication leveraging a messaging platform, verifiable credentials, and secure web endpoints as suggested by Dods (Column 2: lines 5-25).
Ross and Dods do not explicitly disclose determining, by the one or more processors, a level of assurance for the transaction based on one or more of a transaction value, a user behavior pattern, or a fraud risk; selecting, by the one or more processors, based on the determined level of assurance, one or more authentication methods; wherein the link directs the user to a secure authentication page that presents the selected one or more authentication methods based on the determined level of assurance. SHAH, in analogous art, however, discloses determining, by the one or more processors, a level of assurance for the transaction based on one or more of a transaction value, a user behavior pattern, or a fraud risk ([0048] In order to access a service, the user 107 may have to meet authentication requirements of the SP 104 that provides the service. Authentication requirements may be based on authentication policies of the various services. For example, a policy of the SP 104 may require that an authentication meets a predetermined assurance level, which may also be referred to as an authentication strength, before a service that is provided by the SP 104 is accessed. Thus, policies can be expressed as assurance levels. Assurance levels may indicate a strength of an authentication, and a high assurance level may require multiple factors of authentication. In an example embodiment, the assurance level refers to a level of assurance in which a user is authenticated. The assurance level may be based on which authentication protocols are used, a number of factors for authentication, a type of authentication factor (e.g., biometric, device, user) a freshness of the authentication, supplementary conditions, or any appropriate combination thereof. The assurance level may be defined by an external authority. [0094] In some cases, where there exists a capability to perform continuous authentication, for example using behavioral or biometric analytics, then the MFAS 106 may take advantage of that capability and utilize the measured assurance level of that authentication factor appropriately. Continuous authentication has the benefit of being able to authenticate a user without intrusion or with minimal interaction);
selecting, by the one or more processors, based on the determined level of assurance, one or more authentication methods ([0056] The UE 102 may include an indication of its authentication capability 206. At 208, the IdP 106 obtains or discovers the authentication capability 206 of the UE 102. At 210, in accordance with the illustrated embodiment, the IdP 106 determines whether the discovered UE's authentication capability 206 can meet the authentication assurance level 202. If the UE's authentication capability 206 can meet the required authentication assurance level 202, the IdP 106 may select one or more authentication factors that achieve the required authentication assurance level 202 based on a policy requirement of the RP 104. The required authentication assurance level 202 may also be referred to as a first authentication assurance level 202. For example, at 212, the IdP 106 may extract a list of authentication factors that are required. If the UE's authentication capability 206 cannot meet the required authentication assurance level 202, at 214, the IdP 106 may negotiate with the RP 104 to determine a second authentication assurance level. The second authentication assurance level may be based on the authentication capabilities of the UE 102 such that the second authentication assurance level is equal to the capabilities of the UE 102. By way of example, the second authentication assurance level may be less than the first authentication assurance level. After the authentication assurance level is negotiated, the IdP 106 may select one or more authentication factors that achieve the required authentication assurance level, at 212, based on a policy requirement of the RP 104);
wherein the link directs the user to a secure authentication page that presents the selected one or more authentication methods based on the determined level of assurance ([0095] Different services or URL domains may be associated with different assurance levels. At the MFAS, static URL policies may be matched against different authentication factors, and those authentication factors are invoked for different URL domains. In one embodiment, at the MFAS 106, assurance level mappings of URL substrings against authentication factors are used to execute the corresponding authentication factors for the static service provider URLs. Additionally, subdomains of a particular service provider may also request different authentication requirements. As an example, for an Amazon checkout scenario, a URL substring Amazon/cart may be mapped against the required authentication requirement. If the “openid.return_to” contains this substring, then the authentication factors corresponding to the specified authentication assurance level are invoked. [0191] Still referring to FIG. 15, in accordance with an example embodiment, an Assurance Level Broker (ALB) 1512 is a database and logic function that may allow for an essential function of the FNX 1508. The ALB 1512 may map assurance levels as described above. Assurance levels may refer to enumerations of levels of assurance of user authenticity defined by some authority, for example as assurance authority 1516. Thus, the ALB 1512 may map assurance levels to authentication methods and supplementary conditions, such as freshness of authentication for example. In accordance with an example embodiment, an Authentication Front End (AFE) broker (AFB) 1514 may be a broker that provides tailored front-ends (e.g., Web pages or active Web elements such as javascripts or ActiveX elements) to support user authentication. The AFE 1514 may provide tailored front-ends that represent combined authentications (e.g., reflecting to and requesting acceptance from, a user that a NAE authentication such as EAP-SIM, is used to authenticate to an IDP identity such as an email address).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the authentication request data object disclosed by Ross and Dods to include determining, by the one or more processors, a level of assurance for the transaction based on one or more of a transaction value, a user behavior pattern, or a fraud risk; selecting, by the one or more processors, based on the determined level of assurance, one or more authentication methods; wherein the link directs the user to a secure authentication page that presents the selected one or more authentication methods based on the determined level of assurance. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide a policy-driven authentication framework that discovers a user/device’s available authentication capabilities, compares them to a service provider’s required assurance level, and then selects the right combination of factors to meet that level. A master identity provider or proxy can orchestrate the factors, whether they are performed on the device, in the network, or both. The system can reuse fresh prior authentications and consolidate multiple results into a single assertion. If the requested assurance level is not achievable, it can negotiate a lower level or a reduced service as suggested by SHAH (0043-0055] and [0128-0131]).
As per claim 2. Ross in view of Dods in further view of SHAH disclose the computer-implemented method of claim 1, further comprising registering, by the one or more processors, the decentralized identity and the pre-registered contact identifier during a user onboarding process with an application provider, wherein the registering includes determining a level of assurance for the user, and wherein the generating an authentication request data object is based at least in part on the determined level of assurance (Ross: [0262] once the mobile device user 1408 has responded to a challenge 2002, the user's particular response information is digitally signed using the private key of the authentication token and, once the digital signature is validated by the AuthService server 1406 using the public key of the authentication token, the user's particular response information may be provided to the remote service server 1412. To ensure a frictionless but secure user experience, challenges 2102 may be configured to require a user to assert a user credential 2102, which may be a user's biometric or a PIN, as a second factor of assurance. An exemplary embodiment is illustrated in FIG. 21).
As per claim 3. Ross in view of Dods in further view of SHAH disclose the computer-implemented method of claim 2, wherein the authentication code is generated based on details associated with biometric aspects of the user, details of the transaction, or one or more user-specific details, and the generation of the link is determined based on a desired channel and one or more user authentication methods (Ross: [0072] Referring now to FIG. 8, each mobile or hand-wearable device 804 (mobile device 104 or HW device 106) can include a transceiver 810, a cryptographic component 820, a computer processor 830, one or more memory components 840, and a device identity provider application (dID app such as, for example, a PrivaKey™ device identity and authentication application) 850 stored in the memory component(s) 840. Memory component(s) 840 may be any suitable type of memory of various types of memory, e.g., flash memory, RAM, in-memory data grids, in-memory database (e.g. IMDB, MMDB, memory resident database, etc.), keychain software (e.g. Apple® Keychain) Device 804 may also include an input component such as a keyboard (not shown). The keyboard may be a physical keyboard with buttons that the user may press, or it may be a virtual keyboard that is displayed on a touch sensitive screen that is also used to display output. A microphone, a camera, an identification code reader, and/or a speech recognition module may optionally be used for providing input to device 804. In various embodiments, device 804 includes a biometric identification reader (e.g. fingerprint scanner, camera) configured to read biometric information (e.g. a fingerprint, a facial image) from an Internet user. In various embodiments, device 804 includes an identification code reader (e.g. QR code reader, barcode reader) configured to read an IDP-service generated recovery key embedded in a QR code and/or barcode on, for example, a printed paper to allow an Internet user to regain access to Internet services provided by RPs that are pre-registered with IDP service core (150, 250) and if all of the one or more Internet user's devices (104, 106, 102), having an instance of the dID app installed thereon, are destroyed, lost, or stolen).
As per claim 4. Ross in view of Dods in further view of SHAH disclose the computer-implemented method of claim 1, wherein the generating of the authentication request data object further comprises linking the decentralized identity and the authentication code (Dods: Column 18: lines 21-30: This approach addresses several fundamental weaknesses with messaging systems, such as email, SMS, and other legacy channels where spoofing and phishing are common. By anchoring authentication in VCs, it effectively represents a second authentication factor in addition to whatever trust participants might place in a communication route when sending to (or receiving from) a given messaging system (e.g., email) address. This is a superior means of two factor authentication than other channels such as SMS, as it can be entirely decentralized, and is less vulnerable to network attacks).
As per claim 5. Ross in view of Dods in further view of SHAH disclose the computer-implemented method of claim 1, further comprising applying a machine-learning model to analyze user behavior patterns and actions associated with the user to identify potential fraud before generating the authentication request data object (Dods: Column 13: lines 62-63 and column14: lines 1-10: In some implementations, Sender and/or Recipient are asked to provide additional authentication factor(s) using Mobile App 160. Certain implementations of the technology disclosed may leverage deep learning system 132 to securely detect fraudulent use of VCs by observing patterns in the messages signed by them. These predictions may take the form of risk scores, which may be visible to the message Sender or Recipient, and may also factor in the time difference between when a VC and/or VP is/are issued, and the time that the link was opened. The use of artificial intelligence and deep learning to detect fraudulent use of self-sovereign identities is described further in U.S. Non-Provisional patent application Ser. No. 17/492,488, titled “Decentralized Identity Authentication Framework for Distributed Data”, filed Oct. 1, 2021, the entirety of which is incorporated by reference).
As per claim 8. Ross in view of Dods in further view of SHAH disclose the computer-implemented method of claim 1, further comprising verifying the authenticity of the decentralized identity using a secure credential issued by an authorized entity (Dods: Column 8: lines 40-55: (46) The technology disclosed addresses these problems by extending and enhancing magic links with tooling such as Verifiable Credentials (VC)—anchoring passwordless authentication over legacy channels with decentralized (e.g., self-sovereign) cryptographic materials, capable of being supported by a decentralized data store. In many implementations, widely implemented standards for VCs such as W3C are applicable. VCs are an open standard for digital credentials that can represent both tangible (e.g., a passport) and intangible (e.g., a license to practice) credentials. VCs are verified by trusted identity authenticators (for instance, in the form of a digital signature) and implementable within decentralized systems. VCs can be represented within a “triangle of trust” model consisting of an “Issuer” (i.e., the entity that generates the credential), a “Holder” (i.e., the entity that uses the credential to create a presentation of proof for the credential), and a “Verifier” (i.e., the entity that requests proof of credentials from the Holder). Any role in the triangle can be filled by a person, an individual, a device, and so on. The triangle of trust model is built upon the principle that the Issuer trusts the Holder (i.e., provides and “vouches” for the credential), the Holder trusts the Verifier (i.e., presents their credentials), and the Verifier trusts the Issuer (i.e., views the credential as reputable).
As per claim 9. Ross in view of Dods in further view of SHAH disclose the computer-implemented method of claim 1, comprising: presenting one or more additional challenges on the secure authentication page based on user behavior analysis (Ross [0067] a dynamic catalog of respective Internet users' and/or respective Internet users' device(s) identity records maintained in identity repository 140 can be changed based on an Internet user's input, an Internet user device(s)' approval/rejection by the single IDP, and/or an IDP administrator's input (e.g. based on a user's subscription to the IDP service) of the single IDP. In various embodiments, IDP service core 150 of the single IDP can generate a unique anonymous identifier code for an Internet user).
As per claim 10. Ross in view of Dods in further view of SHAH disclose the computer-implemented method of claim 1, wherein the decentralized identity is a verifiable credential stored in a digital wallet on a device of the user, and the method further comprises verifying the verifiable credential as part of the validating the user authentication (Dods: Column 13: lines 35-47: User credentialing administration logic 152 can generate, after obtaining the VC from the Recipient's cryptographic wallet 165, a VP of the Recipient's credential. The Recipient can then sign the Response Message (i.e., the filled-out form) using their VP. In one implementation, Recipient opts to allow the web portal 167 to access their cryptographic wallet 165 to obtain the Recipient VC. In another implementation, Recipient does not allow access to their cryptographic wallet 165 and chooses to generate the VP separately then copy and paste the VP to sign the response. After accepting and validating the Recipient VP as authentic, message exchange logic 154 notifies Sender with the response, providing interoperable and bidirectional authentication of the recipient's identity, without the need for them to create an account on the server for web portal 167).
As per claims 11-15 and 18-19:
Claims 11, 12, 19, 13-15 and 18 are directed to a system comprising memory and one or more processors communicatively coupled to the memory, the one or more processors configured to perform corresponding limitation features of claims 1-5 and 8 respectively and therefore and limitations of claims 11, 12, 19, 13-15 and 18 are rejected with the same rationale given above to reject corresponding limitations of claims 1-5 and 8 respectively
As per claim 20: Claims 20 is directed to one or more non-transitory computer-readable storage media including instructions that, when executed by one or more processors, cause the one or more processors to perform features having substantially corresponding limitations of claim 1 and therefore claim 20 is rejected with same rationale given above to reject claim 1.
Allowable Subject Matter
Claims 6-7 and 16-17 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. The following is a statement of reasons for the indication of allowable subject matter: After consideration of the applicant’s correspondence filed on September 24, 2024, through examination of the application, claims, and conducted search, the pertinent prior arts of record, either taken alone or in combination neither anticipates nor renders obvious the claimed subject matter of claim 6-7 and 16-17 when taken as a whole together with their respective independent claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
CHOYI US 20180013782 describes a way to keep a user or device authenticated over time without forcing the user to log in again too often. Instead of treating authentication as a one-time event, the system tracks an “assurance level” that can rise after a successful login and then fade as time passes. When that assurance level drops below a required threshold, the system asks for another authentication step. The additional step can be chosen from multiple factors, such as passwords, biometrics, device possession, or behavioral signals. The approach is meant to reduce user frustration while still protecting access to apps, network services, and device functions. The system can work with a server-side continuous authentication service and a local agent on the device. It can use explicit checks, such as fingerprint scans, or implicit checks, such as continued network connectivity and security-message handling. The application also describes using authentication assertions and tokens so different apps or service providers can rely on the current assurance state. It supports network-based, device-based, and hybrid deployments. The disclosure further describes LTE-specific techniques, including using security mode command-related events as an implicit sign of authenticated access. Overall, the invention aims to make authentication continuous, risk-based, and less intrusive.
Lindemann US 20190222424 describes a way for a user’s device to hold and use “verifiable claims” such as membership or affiliation claims. A claim provider issues a claim to the user’s authenticator, and the authenticator stores it securely with associated attributes. When the user later authenticates to a website or other relying party, the authenticator sends a signature assertion that includes an attribute extension tied to that claim. The relying party can then check that the claim was bound to the authenticator and is not just a bare bearer token. In some embodiments, the claim binding is based on direct anonymous attestation so the user can prove the claim without exposing unnecessary identity details. The system can use different keys for different claim providers to preserve privacy across relationships. The specification also describes blockchain-related authentication, where a block can be attested and used to help carry verifiable claims from an older authenticator to a newer one. This allows claims to survive device replacement or migration. The overall goal is to let users prove facts about themselves in a privacy-preserving way while still binding those facts to trusted hardware.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TECHANE GERGISO whose telephone number is (571)272-3784. The examiner can normally be reached 9:30am to 6:30pm.
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, LINGLAN EDWARDS can be reached at (571) 270-5440. 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.
/TECHANE GERGISO/ Primary Examiner, Art Unit 2408
Prosecution Insights