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 .
DETAILED ACTION
Claims 1-20 are pending in Instant Application.
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 01/21/2025 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement(s) is/are being considered if signed and initialed by the Examiner.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-8, 13-20 are rejected under 35 U.S.C. 103 as being unpatentable over MURDOCH et al., “hereinafter MURDOCH” (U.S. Patent Application: 20210271765) in view of CHO et al., “CHO” (U.S. Patent Application: 20230103021).
As per Claim 1, MURDOCH discloses a system, comprising:
a computing device comprising a processor and a memory; and machine-readable instructions stored in the memory that, when executed by the processor (MURDOCH, Para.38, The computer-executable instructions (and the manipulated data) is stored in the memory 104 of the computing system 100, Para.34, a computing system 100 typically includes at least one hardware processing unit 102 and memory 104. The processing unit 102 includes a general-purpose processor), cause the computing device to at least:
receive a request from a user device of a first user to issue a delegation verifiable credential that indicates that the first user has a delegation relationship with a second user (MURDOCH, Para.06, relationship between the two owners can often be clearly identified, such as parent-child relationship, employer-employee relationship, customer-service relationship, etc. When a certain relationship exists, one DID owner may want to grant a scope of permission to the other DID owner. For example, a child would likely want to delegate his/her parents a scope of permission to allow the parents to act on behalf of the child, Para.107, verifiable claims are issued and stored at the identity hub 411. For example, a verifiable claim that is associated with a DID owner 201 is issued by a claim issuing entity, and the issued verifiable claim is stored at the identity hub 411 that is associated with the DID owner 201. The DID owner 201 send the verifiable claim to another entity when the other entity requires to verify the credential of the DID owner, Para.65, The credential information 215 is any information that is associated with the DID owner 201's background. For instance, the credential information 215 is (but not limited to) a qualification, an achievement, a government ID, a government right such as a passport or a driver's license, a digital asset provider or bank account, a university degree or other educational history, employment status and history, or any other information about the DID owner 201's background. [The examiner interpreted the first DID owner as the first user and the second DID owner as the second user.]);
request confirmation from the second user of the delegation relationship with the first user (MURDOCH, Para.14, in response to receiving a request from the second DID owner of the second DID for access to the scope of permission, the computing system requests the second DID (i.e., the computing system associated with the second DID, including a management module, a user agent, or an ID hub of the second DID) for proof of delegation of the scope of permission. The second DID then generates a proof code and sends the proof code to the computing system. The proof code is configured to prove that the second DID has been delegated to the requested scope of permission.);
However MURDOCH does not disclose after receiving confirmation, issue a new verifiable credential for the first user, wherein the new verifiable credential includes a delegation attribute value that describes the delegation relationship between the first user and the second user and transmit the new verifiable credential to the user device of the first user.
CHO discloses issue after receiving confirmation, issue a new verifiable credential for the first user, wherein the new verifiable credential includes a delegation attribute value that describes the delegation relationship between the first user and the second user (CHO, Para.17, the digital wallet of the first user as to whether state information of the delegated credential is valid, verifying, by the digital wallet of the second user, a signature of the delegated credential using a public key in the DID document, when verification succeeds, requesting the DID registry to register an initially created DID document so as to be issued a newly generated delegated credential, when a response to registration of the DID document is received from the DID registry, checking a result of the registration and requesting the digital wallet of the first user to register the delegated credential, and receiving a delegated credential issuance response message from the first user.) and transmit the new verifiable credential to the user device of the first user (CHO, Para.94, The DID registry 130 registers the requested DID document at step S710, creates a response statement corresponding to the DID document, and transmits the response statement to the user 2 110-2 at step S720.).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in MURDOCH with the teachings as in CHO. The motivation for doing so would have been for presenting a delegated credential data model, which allows a user to apply a W3C verifiable credential data model standard in a Decentralized ID (DID)-based service environment. (CHO, Para.09).
With respect to Claim 13 is substantially similar to Claim 1 and is rejected in the same manner, the same art and reasoning applying.
As per Claim 2, MURDOCH in view of CHO discloses the system of claim 1, wherein the delegation relationship identifies that the first user has a delegator role (MURDOCH, Para.08, When a first DID owner delegates a scope of permission to a second DID owner, the first DID owner is a delegator).
With respect to Claim 14 is substantially similar to Claim 2 and is rejected in the same manner, the same art and reasoning applying.
As per Claim 3, MURDOCH in view of CHO discloses the system of claim 1, wherein the delegation relationship identifies that the first user has a delegatee role (MURDOCH, Para.08, When a first DID owner delegates a scope of permission to a second DID owner, the first DID owner is a delegator, and the second DID owner is a delegatee. The delegation of a scope of permission from a delegator to a delegatee is likely performed by a computing system that is associated with the delegator (e.g., a management module (e.g., a wallet app), a user agent, and/or an ID hub of the delegator).).
With respect to Claim 15 is substantially similar to Claim 3 and is rejected in the same manner, the same art and reasoning applying.
As per Claim 4, MURDOCH in view of CHO discloses the system of claim 1, wherein the new verifiable credential includes a delegation expiry attribute value that specifies a date or duration upon which the delegation relationship expires (MURDOCH, Para.13, the defining the scope of permission includes defining one or more restrictions, and the propagating a portion of data related to the delegation includes propagating the one or more restrictions to the distributed ledger. The one or more restrictions include, but are not limited to, (1) an expiration time of the delegation, (2) a predetermined number of times that the delegatee is allowed to access a portion of data or service,).
With respect to Claim 16 is substantially similar to Claim 4 and is rejected in the same manner, the same art and reasoning applying.
As per Claim 5, MURDOCH in view of CHO discloses the system of claim 1, wherein the machine-readable instructions further cause the computing device to:
receive a request from the user device of a first user to issue a new delegation verifiable credential that indicates that the first user has a delegation relationship with a third user (MURDOCH , Para.108, Each DID owner can generate many pairwise DIDs, each of which is only used to communicate with another entity. As such, even though the same DID owner is communicating with many different entities, each of these entities does not know the communications involving the same DID owner using other pairwise DIDs, Para.05, a DID owner can generate and use many different DIDs to communicate with other DID owners. Pairwise DIDs are referred to as a pair of DIDs that are only used for communications between two entities. For example, a first DID owner owns a first DID, and a second DID owner owns a second DID. When the first DID and the second DID are pairwise DIDs, the first DID and the second DID are used only between the first DID owner and the second DID owner. When the first owner is to communicate with a third DID owner, a third DID will be generated and used. Similarly, when the second DID owner is to communicate with the third DID owner, a fourth DID will be generated.);
revoke the new verifiable credential for the first user responsive to receiving the request for issuing a new delegation verifiable credential (MURDOCH , Para.12, In response to a determination that the particular relationship no longer exists, the computing system revokes the delegation of the corresponding scope of permission and propagating data related to the revocation of permission to the distributed ledger, Para.83, devices that change ownership as it is possible to associate the specific device DID to the new owner of the device by granting the new owner authorization rights in the DID document and revoking such rights from the old owner.); and
issue another new verifiable credential for the first user, wherein the other new verifiable credential includes a delegation attribute value that describes the delegation relationship between the first user and the third user (MURDOCH , Para.108,When the first owner is to communicate with a third DID owner, a third DID will be generated and used. Similarly, when the second DID owner is to communicate with the third DID owner, a fourth DID will be generated, Para.65, The DID document 210 also includes credential information 215, which also be referred to herein as an attestation. The credential information 215 is any information that is associated with the DID owner 201's background. For instance, the credential information 215 is (but not limited to) a qualification, an achievement, a government ID, a government right such as a passport or a driver's license, a digital asset provider or bank account, a university degree or other educational history, employment status and history, or any other information about the DID owner 201's background.).
With respect to Claim 17 is substantially similar to Claim 5 and is rejected in the same manner, the same art and reasoning applying.
As per Claim 6, MURDOCH in view of CHO discloses the system of claim 1, wherein the machine-readable instructions further cause the computing device to:
receive a revocation request from the user device of the first user to remove the delegation attribute value from the new verifiable credential for the first user (MURDOCH, Para.12, in response to a user input that changes information related to the first DID or information related to the second DID, the computing system determines whether the particular relationship still exists. In response to a determination that the particular relationship no longer exists, the computing system revokes the delegation of the corresponding scope of permission and propagating data related to the revocation of permission to the distributed ledger.);
issue an updated verifiable credential for the first user, wherein the updated verifiable credential does not include the delegation attribute value (MURDOCH, Para.10, the computing system receives a user input for generating, updating, or deleting a mapped pair of a particular scope of permission and a particular relationship. Based on the user input, the computing system updates the recorded mapping data in the storage. In some cases, in response to the user indication, the computing system also updates delegation(s) between pairwise DIDs that have a particular relationship that is affected by the user input.); and
notify a user device of the second user that the delegation attribute value has been removed from the verifiable credential for the first user.
With respect to Claim 18 is substantially similar to Claim 6 and is rejected in the same manner, the same art and reasoning applying.
As per Claim 7, MURDOCH in view of CHO discloses the system of claim 1, wherein the machine-readable instructions further cause the computing device to: issue a decentralized identifier for the first user; and issue a decentralized identifier for the second user (MURDOCH, Para.05, The embodiments described herein are related to delegating a scope of permission between pairwise decentralized identifiers (DIDs), Para.53, the DID owner 201 creates and registers the DID 205. The DID 205 is any identifier that is associated with the DID owner 201. Preferably, that identifier is unique to that DID owner 201,).
With respect to Claim 19 is substantially similar to Claim 7 and is rejected in the same manner, the same art and reasoning applying.
As per Claim 8, MURDOCH in view of CHO discloses the system of claim 7, wherein the machine-readable instructions further cause the computing device to:
receive a revocation request from the user device of the first user to remove the delegation attribute value from the new verifiable credential for the first user (MURDOCH, Para.86, The DID lifecycle management module 320 also includes a revocation module 370 that is used to revoke or sever a device from the DID 205. In operation, the revocation module uses the UI element 335, which allows the DID owner 201 to indicate a desire to remove a device from being associated with the DID 205. In one embodiment, the revocation module access the DID document 210 and causes that all references to the device be removed from the DID document. Alternatively, the public key for the device is removed.);
issuing a first updated verifiable credential for the first user, wherein the first updated verifiable credential does not include the delegation attribute value (MURDOCH, Para.116, when Alice's DID 511 is to delegate a scope of permission to Bob's DID 521, the Alice's computing system (e.g., Alice's management module, user agent, or ID hub) updates the DID document of Alice's DID 511 or the DID document of Bob's DID 521 to record the delegation of the scope of permission. In some embodiments, a new DID is generated, and delegation of the scope of permission is recorded in the DID document of the new DID. A portion of the data related to the delegation is then propagated onto the distributed ledger.); and
issuing a second updated verifiable credential for the second user, wherein the second updated verifiable credential does not include the delegation attribute value (MURDOCH, Para.116, when Alice's DID 511 is to delegate a scope of permission to Bob's DID 521, the Alice's computing system (e.g., Alice's management module, user agent, or ID hub) updates the DID document of Alice's DID 511 or the DID document of Bob's DID 521 to record the delegation of the scope of permission. In some embodiments, a new DID is generated, and delegation of the scope of permission is recorded in the DID document of the new DID. A portion of the data related to the delegation is then propagated onto the distributed ledger.);
With respect to Claim 20 is substantially similar to Claim 8 and is rejected in the same manner, the same art and reasoning applying.
Claims 9-12 are rejected under 35 U.S.C. 103 as being unpatentable over MURDOCH et al., “hereinafter MURDOCH” (U.S. Patent Application: 20210271765) in view of RAMASWAMY et al., “RAMASWAMY” (U.S. Patent Application: 20230171257).
As per Claim 9, MURDOCH discloses a method performed by a computing device, comprising:
receiving a request from a user device of a first user to perform an action on behalf of a second user (MURDOCH, Para.06, the relationship between the two owners can often be clearly identified, such as parent-child relationship, employer-employee relationship, customer-service relationship, etc. When a certain relationship exists, one DID owner may want to grant a scope of permission to the other DID owner. For example, a child would likely want to delegate his/her parents a scope of permission to allow the parents to act on behalf of the child.);
receiving a verifiable credential of the first user that includes a delegation attribute value that describes a delegation relationship between the first user and the second user (MURDOCH, Para.08, When a first DID owner delegates a scope of permission to a second DID owner, the first DID owner is a delegator, and the second DID owner is a delegatee. The delegation of a scope of permission from a delegator to a delegatee is likely performed by a computing system that is associated with the delegator (e.g., a management module (e.g., a wallet app), a user agent, and/or an ID hub of the delegator). The computing system first determines a relationship between the owners of the pairwise DIDs.), wherein the delegation relationship specifies the requested action (MURDOCH, Para.08, Based on the relationship, the computing system then delegates a scope of permission owned by the delegator DID to the delegatee DID.);
verifying a digital signature of an issuer of the verifiable credential (MURDOCH, Para.107, a verifiable claim that is associated with a DID owner 201 is issued by a claim issuing entity, and the issued verifiable claim is stored at the identity hub 411 that is associated with the DID owner 201. The DID owner 201 send the verifiable claim to another entity when the other entity requires to verify the credential of the DID owner. For example, the DID owner 201 is a person holding a driver's license, and the claim issuing entity is a DMV that has issued the DID owner's driver's license. The DMV issue a verifiable claim that verifies that the DID owner 201 is holding a valid driver's license.); and
asking the second user to verify that the first user is authorized to carry out the requested action (MURDOCH, Para.06, relationship between the two owners can often be clearly identified, such as parent-child relationship, employer-employee relationship, customer-service relationship, etc. When a certain relationship exists, one DID owner may want to grant a scope of permission to the other DID owner. For example, a child would likely want to delegate his/her parents a scope of permission to allow the parents to act on behalf of the child, Para.107, verifiable claims are issued and stored at the identity hub 411. For example, a verifiable claim that is associated with a DID owner 201 is issued by a claim issuing entity, and the issued verifiable claim is stored at the identity hub 411 that is associated with the DID owner 201. The DID owner 201 send the verifiable claim to another entity when the other entity requires to verify the credential of the DID owner.); and
responsive to receiving verification from the second user and verifying the digital signature of the issuer, confirming that the first user is verified to perform the requested action (MURDOCH, Para.128, After the delegatee receives the delegation of the scope of permission, the delegatee will be allowed to access the delegated scope of permission. FIG. 11 illustrates a flowchart of an example method 1100 for allowing a delegatee to access a delegated scope of permission in response to proving that the delegation is valid. The method 1100 is also likely implemented in a computing system that is associated with the delegator's DID. The method 1100 includes receiving a request from a delegatee DID for accessing a scope of permission (1110). In response to the request, the computing system requests the delegatee for proof of the delegation (1120). Once the proof code from the delegatee is received (1130), the computing system validates the proof code (1140).).
However MURDOCH does not disclose notifying the second user that the first user is attempting to carry out an action specified in the delegation relationship.
RAMASWAMY discloses notifying the second user that the first user is attempting to carry out an action specified in the delegation relationship (RAMASWAMY, Para.30, a delegate message is sent to the streaming service's server. The message contains the MDN of the father and information related to the attempted/requested transaction (e.g., information indicating a purchase the movie for $10.00 dollars)., Para.54, the delegatee being notified that the delegation request was approved by the delegator. For example, UI 470 depicts a notification message that indicates that the delegator has approved the delegation request. And, upon interacting with the notification message, UI 472 can be displayed which provides an interface indicating that activation was successful, and the transaction can be processed as requested by the delegatee. For example, the daughter is approved by the Father, and the movie is made available on the daughter's device for streaming.).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in MURDOCH with the teachings as in RAMASWAMY. The motivation for doing so would have been for providing a framework that expands the scope of existing authentication and identification verification services by enabling users to delegate other users as operators of their securely held account credentials. This, therefore, enables users to act on the basis of other user's credentials. (RAMASWAMY, Para.10).
As per Claim 10, MURDOCH in view of RAMASWAMY discloses the method of claim 9, wherein a notification is sent to the second user regarding the requested action in response to occurrence of a specified condition specified in the verifiable credential (MURDOCH, Para.121, When the scope of permission includes one or more restrictions or conditions, Alice's device 840 will also verify whether the requested scope of permission falls within the one or more restrictions and/or whether the one or more conditions are satisfied. For example, if a condition requires Bob to pay a predetermined amount of cryptocurrency, the proof data is required to show a proof of payment. As another example, if a condition requires Bob to provide his email address, the proof data is required to include Bob's email address. If the proof data is valid, Alice's device 840 approves the Bob's request, otherwise, Alice's device 840 denies the Bob's request, which is represented by arrow 835.).
As per Claim 11, MURDOCH in view of RAMASWAMY discloses the method of claim 9, wherein the delegation relationship identifies that the first user has a delegator role and the second user has a delegatee role (MURDOCH, Para.08, When a first DID owner delegates a scope of permission to a second DID owner, the first DID owner is a delegator, and the second DID owner is a delegatee. The delegation of a scope of permission from a delegator to a delegatee is likely performed by a computing system that is associated with the delegator (e.g., a management module (e.g., a wallet app), a user agent, and/or an ID hub of the delegator).).
As per Claim 12, MURDOCH in view of RAMASWAMYdiscloses the method of 9, wherein the verifiable credential includes a delegation expiry attribute value that specifies a date or duration upon which the delegation relationship expires (MURDOCH, Para.13, the defining the scope of permission includes defining one or more restrictions, and the propagating a portion of data related to the delegation includes propagating the one or more restrictions to the distributed ledger. The one or more restrictions include, but are not limited to, (1) an expiration time of the delegation, (2) a predetermined number of times that the delegatee is allowed to access a portion of data or service).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NORMIN ABEDIN whose telephone number is (571)270-5970. The examiner can normally be reached Monday to Friday from 10 am to 6 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, Vivek Srivastava can be reached at 5712727304. 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.
/NORMIN ABEDIN/Primary Examiner, Art Unit 2449