DETAILED ACTION
Acknowledgements
This Office Action is in response to Applicant’s response/application filed on 03/03/2026.
The Examiner notes that citations to United States Patent Application Publication paragraphs are formatted as [####], #### representing the paragraph number.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
Claim 1 has been cancelled.
Claims 2-21 have been added.
Claims 2-21 are currently pending and have been examined.
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.
As per claims 2-21, the claimed invention is directed to an abstract idea without significantly more because:
• Claim 2 recites:
receiving, by a system comprising one or more processors, a request associated with a [user] computing device for a document package that includes an electronic document and indicates identification information;
outputting, by the system, an instruction to the [user] computing device that causes the [user] computing device to access a certification platform and causes generation of certified identification information based on verification data obtained from the [user] computing device;
receiving, by the system, the certified identification information corresponding to the identification information; and
based on the certified identification information and cryptographic data associated with the request, configuring, by the system, the computing device to permit execution of an operation for the electronic document.
• Under Step 1 of the Section 101 analysis, the claim(s) is/are directed to a method, a system, and a manufacture, which are statutory categories of invention.
• Under Step 2A Prong One of the 2019 Revised Patent Subject Matter Eligiblity Guidance, the claimed invention as drafted includes language (see underlined language above) that recites an abstract idea of permitting access of a resource for a user based on the user authentication information received from a third party (a certain method of organizing human activity such as a commercial or legal interactions) but for the recitation of additional claim elements. That is, other than reciting “system”, “one or more processor(s)”, “computing device”, “memory”, “non-transitory computer-readable media”, nothing in the claim precludes the language from being considered as performed by a person.
• Under Step 2A Prong Two of the 2019 Revised Patent Subject Matter Eligiblity Guidance, the additional claim element(s), considered individually, do not apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception and in a manner that integrates the exception into a practical application of the exception. The additional claim elements(s) merely add the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea. For example, the additional elements of “system”, “one or more processor(s)”, “computing device”, “memory”, “non-transitory computer-readable media”, merely use a generic computer device and/or generic computer components as a tool to perform an abstract idea.
• Under Step 2A Prong Two, the additional claim element(s), considered in combination, do not apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception and in a manner that integrates the exception into a practical application of the exception. The combination of elements is no more than the sum of their parts. Unlike the eligible claims in Diehr and Bascom, in which the elements limiting the exception taken together improve a technical field, the instant claim lacks an improvement to the functioning of a computer or to any other technology or technical field.
• Under Step 2B, the additional claim element(s), considered individually and in combination, do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself for similar reasons outlined under Step 2A Prong Two.
A similar analysis can be applied to dependent claims 3-15, 17-20 which further recite the abstract idea of outputting an instruction, determining a request is associated/unassociated with a user account, performing a verification operation, transmitting an authorization request, storing the certified identification information, prepolulating an identity field of the electronic document, enabling a signature process, initiating an authentication challenge, combining certified identification information and the authentication challenge (a certain method of organizing human activity). That is, other than reciting “computing device”, “electronic”, “encrypted identity wallet”, nothing in the claim precludes the language from being considered as performed by a person.
A similar analysis can be applied to dependent claims 12, 13, 14 which include additional claim elements that merely add the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea. For example, “electronic”, “computing device”. Furthermore, the additional claim elements(s) such as “encrypted identity wallet” generally link the use of the judicial exception to a particular technological environment or field of use of e-wallet.
Therefore, claims 2-21 are rejected under 35 U.S.C. §101.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 2, 3, 6-11, 14, 16, 17, 20, 21 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Leicher (US 20130191884).
Regarding claim(s) 2, 16, 21, Leicher discloses:
at least one memory storing instructions and processing circuitry configured to execute the instructions ([0139]-[0140] of Leicher);
non-transitory computer-readable media storing instructions that, when executed by a system comprising one or more processors ([0139]-[0140] of Leicher), cause the system to:
receive, by a system comprising one or more processors, a request associated with a computing device for a document package that includes an electronic document and indicates identification information (By disclosing, “At 606, a user 600 may request access to a service by using an OpenID identifier, such as an email address for example. The identifier may comprise a username and the domain of an OpenID IdP (OP).” ([0071] and Fig. 6 of Leicher));
output, by the system, an instruction to the computing device that causes the computing device to access a certification platform and causes generation of certified identification information based on verification data obtained from the computing device (By disclosing, “At 608, the client 602 (service provider) may prepare an authorization request and may send the request to the user 600. The request may comprise desired request parameters. At 610, the authorization request may be sent to the authorization server 604 (e.g., via the user) using an HTTP re-direct for example. At 612, the authorization server 604 may authenticate the user 600, and thus the authorization server 604 may be referred to as an authentication end point (AEP)…. At 616, tokens may be created and the authorization server 604 may send the user 600 back to the client 602 (at 618) with an access token and/or an ID token. ” ([0071], [0043], and Fig. 6 of Leicher));
receive, by the system, the certified identification information corresponding to the identification information (By disclosing, “At 616, tokens may be created and the authorization server 604 may send the user 600 back to the client 602 (at 618) with an access token and/or an ID token. ” ([0071] and Fig. 6 of Leicher)); and
based on the certified identification information and cryptographic data associated with the request, configure, by the system, the computing device to permit execution of an operation for the electronic document (By disclosing, “In an example implementation, the RP may choose to verify the signature on the ID token itself, so the RP may need to know the verification keys. The pointer to the keys may be part of the header. For example, the pointer may be the jku (e.g., JSON Web Key URL) parameter, which may comprise a URL pointing to a set of JSON encoded public keys. In an example implementation, the x5u parameter may comprise a URL pointing to a X.509 public key certificate or certificate chain (e.g., corresponding to the key).” ([0065]-[0066], [0071] of Leicher); and “A successful verification may be required before the service provider 802 accepts the ID token and trusts its contents. For example, the service provider may not trust that an email address belongs to the current session's user until tokens are verified. Upon a successful verification, the service provider may 802 may take actions such as adding the verified user to its user database, allowing access to a service that it provides, or the like.” ([0078] of Leicher)).
Regarding claim(s) 3 and 17, Leicher discloses:
outputting the instruction based on a determination to perform authentication of a signatory using the certification platform (By disclosing, a service provider requesting an access token /ID token when the service provider determines that additional information is needed from the user when the user requested access to the service provider, ([0074] of Leicher); the service provider verifies the acquired access token/ ID token using a public key received from an identity provider entity ([0065]-[0066], [0071] of Leicher)).
Regarding claim(s) 6, Leicher discloses:
wherein the instruction specifies an interface endpoint of the certification platform (By disclosing, “Still referring to FIG. 1, indirect communication from the SP 102 to the local OP 104 may occur via the browser 106 of the UE 100, for example, by means of redirect messages. The SP 102 may send an HTTP 3xx message comprising the URL to redirect the browser 106. For example, in accordance with an OpenID protocol, the URL may be the URL that corresponds to the IdP authentication endpoint (AEP).” ([0033] of Leicher)).
Regarding claim(s) 7 and 20, Leicher discloses:
performing at least one verification operation using the cryptographic data associated with the request. (By disclosing, “In an example implementation, the RP may choose to verify the signature on the ID token itself, so the RP may need to know the verification keys. The pointer to the keys may be part of the header. For example, the pointer may be the jku (e.g., JSON Web Key URL) parameter, which may comprise a URL pointing to a set of JSON encoded public keys. In an example implementation, the x5u parameter may comprise a URL pointing to a X.509 public key certificate or certificate chain (e.g., corresponding to the key).” ([0065]-[0066], [0071] of Leicher); and “A successful verification may be required before the service provider 802 accepts the ID token and trusts its contents. For example, the service provider may not trust that an email address belongs to the current session's user until tokens are verified. Upon a successful verification, the service provider may 802 may take actions such as adding the verified user to its user database, allowing access to a service that it provides, or the like.” ([0078] of Leicher)).
Regarding claim(s) 8, Leicher discloses:
wherein the certified identification information includes at least one of a digital certificate, a liveness detection result, a spoof detection result, or a document authenticity assessment. (By disclosing, “The local OP may create an ID token and may sign the token, such as by using the private key for example. The URL of the certificate may be put in the x5u field of the JWS header of the token. …. The local OP may redirect the user agent with the ID token and the access token, for example, to the client endpoint. The URL to redirect the user agent may be provided by the service provider in the initial request (e.g., parameter redirect uri). The service provider may want to verify the ID Token signature itself. For example, the service provider may request the public key and/or certificate from the URL such as the URL provided in the x5u parameter in the header of the token for example.” ([0085] of Leicher)).
Regarding claim(s) 9, Leicher discloses:
wherein the certified identification information is received from the certification platform via a server interface of the system. (By disclosing, “The local OP may create an ID token and may sign the token, such as by using the private key for example. The URL of the certificate may be put in the x5u field of the JWS header of the token. …. The local OP may redirect the user agent with the ID token and the access token, for example, to the client endpoint. The URL to redirect the user agent may be provided by the service provider in the initial request (e.g., parameter redirect uri). The service provider may want to verify the ID Token signature itself. For example, the service provider may request the public key and/or certificate from the URL such as the URL provided in the x5u parameter in the header of the token for example.” ([0085] of Leicher)).
Regarding claim(s) 10, Leicher discloses:
wherein the certified identification information is received from the computing device after the computing device retrieves the certified identification information from the certification platform. (By disclosing, “The local OP may retrieve attributes, may create the token, and/or may sign the token.” ([0086] of Leicher); “tokens may be created and the authorization server 604 [(IDP/OP)] may send the user 600 back to the client 602 (at 618) with an access token and/or an ID token.” ([0071] , [0105] of Leicher); and “If the key and/or certificate have already been created, for example, the OPSF may directly provide the certificate to the client.” ([0097] of Leicher)).
Regarding claim(s) 11, Leicher discloses:
transmitting an authorization request for a signatory to authorize storage of at least a portion of the certified identification information. (By disclosing, “In accordance with an example implementation of an OpenID 2.0 protocol, a client secret (e.g., a shared secret between the Identity Provider (IdP/OP) and the SP/Client) may be established for each user (e.g., per authentication protocol run). The shared secret may be established between an OP and a service during a discovery process. For example, the shared secret may be derived from a long term secret and/or it may calculated by the local OP instance. In accordance with an example implementation of an OpenID Connect protocol, the client secret may comprise tokens. For example, an identity (ID) token may be signed by the OP and the client may verify the token (e.g., with the help of the OP provided token endpoint) and/or the client may verify the token signature on its own.” ([0036] of Leicher); and “verifying, at the SP, a signature of the ID token using a secret stored on the SP; and in response to the verification, granting the UE access to the service.” (Claim 21 of Leicher)).
Regarding claim(s) 14, Leicher discloses:
enabling an electronic signature process configured to identify a signatory, link the signatory to a signature, and invalidate the signature if data of the electronic document is altered after signing. (By disclosing, “In an example implementation, the RP may choose to verify the signature on the ID token itself, so the RP may need to know the verification keys. The pointer to the keys may be part of the header. For example, the pointer may be the jku (e.g., JSON Web Key URL) parameter, which may comprise a URL pointing to a set of JSON encoded public keys. In an example implementation, the x5u parameter may comprise a URL pointing to a X.509 public key certificate or certificate chain (e.g., corresponding to the key).” ([0065]-[0066], [0071] of Leicher); and “A successful verification may be required before the service provider 802 accepts the ID token and trusts its contents. For example, the service provider may not trust that an email address belongs to the current session's user until tokens are verified. Upon a successful verification, the service provider may 802 may take actions such as adding the verified user to its user database, allowing access to a service that it provides, or the like.” ([0078] of Leicher)).
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.
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(a) are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 4 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Leicher (US 20130191884), in view of Levine (US 9203829).
Regarding claim(s) 4 and 18, Leicher does not disclose, but Levine teaches:
determining that the request is unassociated with a user account of a document management platform. (By disclosing, “If the user status identifier module 402 determines that the user does not have an existing account (802—No), the user status identifier module 402 redirects the user to a legacy account creation page at block 804.” (Col 23 lines 6-13, Fig. 8 of Levine)).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the invention of Leicher in view of Levine to include techniques of determining that the request is unassociated with a user account of a document management platform. Doing so would result in an improved invention because this would allow the user register an account at the platform.
Claim(s) 5 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Leicher (US 20130191884), in view of Kalou (US 20220357977).
Regarding claim(s) 5 and 19, Leicher does not disclose, but Kalou teaches:
determining that the request is associated with a user account of a document management platform, wherein outputting the instruction comprises outputting the instruction in response to one or more of an unavailable, incomplete, or unsuccessful platform verification process (By disclosing, “The storage 368 can store credentials, identification, or authorization information of one or more users (e.g., users of the client devices 303). The credentials can be associated with one or more applications or microapps managed by either the remote computing environment or the DPS 301. For example, the remote computing environment can receive credentials from the client device 303. The remote computing environment can compare the credentials to a list of existing account logins (e.g., accounts authorized to access a session of an application or a microapp). If the credential matches with the existing account login, the remote computing environment can create a session and transmit the session identifier to the client device 303 for access. Otherwise, the remote computing environment can either request additional authentication (proof of identity) from the client device 303, lock the account that the client device 303 attempted to sign-in, provide notification of the unsuccessful login attempt, search for a listing of account credential on a different server (e.g., a second cloud managing the application or microapp), among other actions to provide the application to authorized users and prevent access from the attempted break-in.” ([0093] of Kalou)).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the invention of Leicher in view of Kalou to include techniques of determining that the request is associated with a user account of a document management platform, wherein outputting the instruction comprises outputting the instruction in response to one or more of an unavailable, incomplete, or unsuccessful platform verification process. Doing so would result in an improved invention because this would allow the user to access the service with another type of authentication.
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Leicher (US 20130191884), in view of Dowling (US 20230214836).
Regarding claim(s) 12, Leicher does not disclose, but Dowling teaches:
storing the portion of the certified identification information in an encrypted identity wallet associated with the signatory. (By disclosing, “Various example embodiments relate to systems, methods, and apparatuses for storing
verified identification information in a distributed database and for verifying entities to requestors are provided herein.” ([0006] of Dowling); and “Generally, the GRIP computing system 106 receives identity information from an entity (e.g., identity attributes), verifies the received identity information in an appropriate manner to the attribute's standard GRIP level, and publishes an identity owner's signature of the verified attributes along with the identity owner's public key and the GRIP's signature, which verifies that the attribute was confirmed by a GRIP at the appropriate level.” ([0030]-[0034] of Dowling).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the invention of Leicher in view of Dowling to include techniques of storing the portion of the certified identification information in an encrypted identity wallet associated with the signatory. Doing so would result in an improved invention because this would allow retrieving the stored identification information for future use.
Claim(s) 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Leicher (US 20130191884), in view of Queralt (US 20220407721).
Regarding claim(s) 13, Leicher does not disclose, but Queralt teaches:
prepopulating at least one identity field of the electronic document using the certified identification information. (By disclosing, “This flexibility requires the system to be able to find it and use that field to link to the authenticating protocol, in this case, the FIDO user name. This information is taken, and the system fills in the field for user name for the relying party.” ([0140] of Queralt)).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the invention of Leicher in view of Queralt to include techniques of prepopulating at least one identity field of the electronic document using the certified identification information. Doing so would result in an improved invention because this would improve overall user convenience.
Claim(s) 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Leicher (US 20130191884), in view of Terborg (US 20240013198).
Regarding claim(s) 15, Leicher does not disclose, but Terborg teaches:
initiating a supplemental authentication challenge at the computing device, the supplemental authentication challenge including one or more of a biometric input, a one time use code, or a passkey-based process; and wherein configuring the computing device to permit execution of the operation includes combining the certified identification information with results of the supplemental authentication challenge. (By disclosing, “Responsive to receiving the request, the system requests a wallet address associated with a wallet from the client device of the user, and requests an identifier (ID) token from the immutable database based on the wallet address. The ID token contains a first set of identity data of the user. Identity data includes a specific set of user information that is used to identify and/or authenticate the user. In some embodiments, identity data may include (but are not limited to) unique identifiers, personal information, or other data points that are associated with the user. The system requests a second set of identity data from the client device of the user… In some embodiments, the set of identity data includes a set of biometric data. The system causes the user to scan a set of biometric data, which may be performed via the client device or a gate system.” ([0005]-[0006] of Terborg); and “Third, the token can be stacked to update an existing identity token with new information (e.g., biometric
information or new identification documents).” ([0041] of Terborg)).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the invention of Leicher in view of Terborg to include techniques of initiating a supplemental authentication challenge at the computing device, the supplemental authentication challenge including one or more of a biometric input, a one time use code, or a passkey-based process; and wherein configuring the computing device to permit execution of the operation includes combining the certified identification information with results of the supplemental authentication challenge. Doing so would result in an improved invention because this would improve the accuracy of the user’s identification information.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20220021537 to Wagner for disclosing
Methods and systems for privacy-preserving identity attribute verification are presented. During an interaction between a relying entity and a user, a relying entity computer can transmit a policy token to a user device. The policy token may indicate the information needed by the relying entity in order to perform the interaction. The user device can verify the policy token, then use the policy token in conjunction with an identity token to generate a zero-knowledge proof. The user device may transmit the zero-knowledge proof to an identity service provider computer. The identity service provider computer may verify the zero-knowledge proof, then generate a verification message. The identity service provider computer may sign the verification message and transmit the signed verification message to the relying entity computer. The relying entity computer may verify the verification message and complete the interaction with the user.
US 20210266309 to Guccione for disclosing
Systems and methods for providing secure single sign-on authentication and management of encrypted vault in a fully cloud-based zero-knowledge environment. A user on a client device attempts to use a network resource. The user is directed to login to the identity provider. The identity provider authenticates the user through a login process. If the user is identified to be a valid user, the identity provider sends the user an attestation sign-on key to confirm the user is valid. The client device sends the attestation sign-on key to a vault service provider, which verifies the attestation using a configured public key. The client device retrieves a data decryption key and an encrypted data key, which are stored in different entities in the system. The encrypted data key is decrypted on the client device using the data decryption key.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUAN ZHANG whose telephone number is (571)272-4642. The examiner can normally be reached Mon - Fri 10 AM-5 PM.
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, Neha Patel can be reached at 571-270-1492. 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.
/DUAN ZHANG/Primary Examiner, Art Unit 3699
Prosecution Insights