Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on August 20, 2026 has been entered.
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, 7-10, 13-15 and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over CONA et al (U.S. Patent Publication 2019/0333054, hereinafter “Cona”) in view of Sweeney et al (International Publication WO 2019/210391, hereinafter “Sweeney”).
Regarding claim 1, Cona teaches a first computing system (Cona, Figure 2) comprising at least one processor and at least one memory coupled to the at least one processor, wherein the at least one processor is configured to:
receive an identity pass request for a user (Cona, paragraph [0080], “submit a request for a digital identity”);
receive at least attributes associated with the user (Cona, paragraph [0082], “identity information”);
transmit an authentication request for at least one verifiable credential of the user (Cona, paragraph [0083], “IdP personnel may then validate the identity and qualifications to determine if the user should be accredited for the privilege set/access rights requested and generate a digital identity credential”);
receive the at least one verifiable credential of the user (Cona, paragraph [0083], “generate a digital identity credential”);
generate an identity pass comprising a set of identity tokens (Cona, paragraph [0084], “a digital identity may include an EDIT as an access token”) and the at least one verifiable credential, wherein the set of identity tokens comprises at least a first identity token comprising attributes of the user (Cona, paragraph [0084], “that includes an appropriate “claim” for the user”);
generate a graphical user interface (GUI) comprising a representation of the identity pass (Cona, Figure 1(a) shows a graphical representation of a “Digital Identity”);
receive a data request corresponding with the at least one verifiable credential or at least one of the set of identity tokens of the identity pass (Cona, paragraph [0054], “When a user submits a request for a transaction with a service provider…, the platform will prompt the user (i.e., “data request”), through the digital wallet app. (or in their browser), to “present” their digital identity), wherein the data request is for an exchange (transaction) using an exchange instrument (digital wallet), by the user, or providing at least one of the attributes of the user;
verify the at least one verifiable credential based at least on verifying a cryptographic object (Cona, paragraph [0054], “the hash”), an issuer, or a status of the at least one verifiable credential;
responsive to verifying the at least one verifiable credential, determine, based at least on the data request, a first subset of the attributes corresponding with protected information of the user and a second subset of attributes corresponding with unprotected information of the user (Paragraph [0054], “An EDIT may be used to verify the required qualification data for the digital identity to allow the transaction to proceed”; examiner note: the EDIT will provide the unprotected information, the other information is protected), wherein determining the first subset and the second subset comprises, responsive to receiving the data request, processing the data request to identify attributes required to satisfy the data request, classifying the identified attributes as the unprotected information of the user, and classifying attributes not identified in the data request as the protected information of the user (i.e., as described in paragraph [0054] the EDIT is selected based on the required qualification data which is the unprotected information to allow the transaction to proceed, the information not required is protected), wherein the second subset comprises attributes included in the at least one identity token selected for use in satisfying the data request based on contents of the data request (Cona, paragraph [0049], “[w]ith a system of the invention, it is possible to create a digital identity and a specific identifier with specific set of credentials to be used for a particular service provider or for situations where only those specific credentials are needed”);
access a data storage storing the identity pass, wherein accessing comprises querying for unprotected information of the user corresponding with the at least one of the set of identity tokens, and wherein the query returns the unprotected information to satisfy the exchange or permit access to at least one of the attributes of the user (Cona, paragraph [0062], “what type of information was provided”);
transmit, to a second computing system, the unprotected information to satisfy the data request (Cona, paragraph [0062], “the request for, and exchange of, user personal data”), or, permit access, to the second computing system, to the unprotected information to satisfy the data request; and
update a usage log of the identity pass corresponding with the data request (Cona, paragraph [0062], “A history of that “due process” request transaction (i.e., the request for, and exchange of, user personal data…..may be recorded in the ledger”), the usage log being stored as part of the identity pass (Cona, paragraph [0005}, “usage data with service providers”) and comprising entries indicating, for a plurality of data requests, at least the data request and the second subset of the attributes provided in response to the data request (Cona, paragraph [0063], “[t]he specific transaction data stored in the distributed ledger may be limited to the verification transaction (e.g., the EDIT, the nature of the action requested, a timestamp)”) .
Cona does not specify whether the identity pass includes one or more interactive elements, wherein selection of the one or more interactive elements comprises updating the representation corresponding with the identity pass. Sweeney shows in Figure 2O-3O that it is known for identity passes to include one or more interactive elements, wherein selection of the one or more interactive elements comprises updating the representation corresponding with the identity pass (i.e. the graphical representation changes as you interact with it).
Therefore, it would have been it would have been obvious to one of ordinary skill in the art at the time of filing the invention to make the identity pass of Cona to be interactive as taught by Sweeney. The rationale is as follows: One of ordinary skill in the art would have been motivated to make the pass interactive so that the user can control what information that they want to share (See Figure 3N of Sweeney).
Furthermore, it would have been obvious to one of ordinary skill in the art at the time of filing the invention to provide the interactive identity pass of Cona in view of Sweeney with access to the usage log ledger. The rationale is as follows: One of ordinary skill in the art would have been motivated to provide the interactive identity pass of Kona in view of Sweeney with access to the usage log ledger since it would provide the identity pass with the usage data (“log”) as taught by Cona (Paragraph [0005]).
Regarding claim 2, Cona teaches (Paragraph [0005]) that a digital identity as shown in Figure 1(a) can include “usage data with service providers”). Selecting the usage data of the identity pass would update the representation of the identity pass to present the usage log, and when the usage log is updated so will be the representation of the identity pass in the GUI, when it is selected.
Regarding claim 3, Cona further shows wherein the identity pass is stored on a distributed ledger and the distributed ledger is a semi-private distributed ledger allowing selective access to the distributed ledger (See Cona, paragraph [0062] for description of the distributed ledger).
Regarding claim 4, Cona further shows wherein the authentication request is transmitted to the user (See Cona, paragraphs [0083]-[0085] where the digital identity credential is transmitted to the user), a government entity, or third-party.
Regarding claim 5, Cona further shows wherein the query returns the unprotected information and the at least one processor is further configured to determine, based at least on the data request, a portion of the unprotected information to satisfy the data request (See Cona, paragraph [0062]).
Regarding claim 7, Cona further shows wherein the at least one processor is further configured to: verify, using at least one authentication protocol, the data request; and transmit, to the second computing system, the at least one of the set of identity tokens (See Cona, paragraph [0079], “the user must be authorized to access the data requested under a tiered access system”).
With regard to claims 8 and 13, they are the method claims that correspond to system claims 1 and 3 above, and are therefore rejected for the same reasons.
Regarding claim 9, Cona further teaches updating the identity pass (See Cona, paragraph [0023], “the modification of a digital identity”).
Regarding claim 10, Cona further teaches generating a second identity token of the set of identity tokens (Cona, paragraph [0038], “access tokens”) comprising access credentials corresponding to the exchange instrument.
Regarding claim 14, Cona teaches wherein the identity pass request is generated responsive to an onboarding process (See Cona, paragraph [0080], “a user may submit a request for a digital identity credential to an authorized IdP”).
With regard to claims 15 and 17-19, they are the computer readable medium claims that correspond to claims 1-3 and 5 above, and are therefore rejected for the same reasons.
Regrading claim 20, Cona teaches the at least one processor is further configured to generate a second identity token of the set of identity tokens (Cona, paragraph [0023], “access tokens”) comprising access credentials corresponding to the exchange instrument.
Claims 6, 11, 12 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over CONA et al (U.S. Patent Publication 2019/0333054, hereinafter “Cona”) in view of Sweeney et al (International Publication WO 2019/210391, hereinafter “Sweeney”) as applied to claims 1, 8 and 15 above, and further in view of Cinaqui Pereira et al (U.S. Patent 12,192,370, hereinafter “Cinaqui Pereira”).
Regarding claims 6, 11 and 16, Cona does teach generating a second identity token (Paragraphs [0038] and [0039], “access tokens” and “multiple digital identities”) comprising supplementary information and updating the identity pass based at least on the second identity token (Cona, paragraph [0062]). Cona in view of Sweeney does not teach requiring user approval to receive the information. Cinaqui Pereira teaches (Columns 8 and 9, claim 5) a user approving or denying a request for information. It would have been obvious to one of ordinary skill in the art at the time of filing the invention to provide the user of Kona in view of Sweeney with the ability to approve or deny a request for information as taught by Cinaqui Pereira. The rationale is as follows: One of ordinary skill in the art would have been motivated to provide the user of Kona in view of Sweeney with the ability to approve or deny a request for information as taught by Cinaqui Pereira so that the user can control the information that they want to share.
Regrading claim 12, Cona does not specifically mention credit score as part of the personal data of a user. Official Notice is taken that a credit score is known personal data to be associated with a digital identity. It would have been obvious to one of ordinary skill in the art at the time of filing the invention to provide the digital identity of Kona in view of Sweeney and Cinaqui Pereira with credit score information. The rationale is as follows: One of ordinary skill in the art would have been motivated to provide the digital identity of Kona in view of Sweeney and Cinaqui Pereira with credit score information so that the user could use their digital identity in financial transactions, such as applying for a credit card or personal loan, where it would be required.
Response to Arguments
Applicant's arguments filed on August 20, 2026 have been fully considered but they are not persuasive.
Applicant asserts on page 12,
“In particular, Cona does not disclose or suggest, responsive to receiving a data request, processing the data request to identify which attributes are required to satisfy the request and then classifying those identified attributes as unprotected information while classifying attributes not identified in the data request as protected information. Instead, Cona pre-configures separate digital identities with predetermined credentials at identity creation time, rather than classifying attributes as protected or unprotected based on the contents of each incoming data request.”
It is the Examiner’s position that Cona teaches responsive to the data request, selecting the EDIT required to satisfy the request and that the edit selected means that the attributes it contains are classified as “unprotected”, which the other EDITs contain information that are classified as “protected”. Applicant identified paragraph [0069] of the instant specification as one of the paragraphs providing support for the amended claim limitations. Paragraph [0069] states “the processor may receive a data request from an external system, which may correspond to at least one verifiable credential or identity token stored in the user’s identity pass. For example, a financial institution’s system may send a request for a user’s employment verification as part of a loan approval process. In response to the data request, the processor may identify the relevant identity tokens or credentials from the identity pass and prepare them for transmission. In some arrangements, the processor may prompt the user for consent before sharing any data, particularly for sensitive or protected information. Additionally, the request may specify certain attributes needed, and the processor may determine whether the requested information is protected (e.g., social security number, bank account details) or unprotected (e.g., user name, job title). If the information is protected, the processor may restrict access based on predefined policies or request further authentication before sharing the information.” This is seen to be the same way that Cona operates, and therefore Cona is still seen as meeting the claim limitations as currently amended.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
All the references cited on the attached PTO-892 are cited for showing the creation of digital identities.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WILLIAM R KORZUCH whose telephone number is (571)272-7589. The examiner can normally be reached Mon.-Fri. 8:00-4:00.
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.
/WILLIAM R KORZUCH/Supervisory Patent Examiner, Art Unit 2491
