DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
The amendment filed June 22, 2026 has been entered. Claims 1-20 remain pending in the application. Applicant’s amendments to the Claims have overcome each and every 101 rejections previously set forth in the Final Office Action mailed October 24, 2025.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 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.
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.
Claim(s) 1-2 and 4-12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Olson (US 20220043902 A1) in view of Toth (US 20190097812 A1).
Regarding Claim 1, Olson teaches A method, comprising (Olson: Abstract):
obtaining, by a computing device, a request from an endpoint device to access at least one executable system resource residing on a network-based infrastructure through a unified security [bridge] (Olson: Paragraph(s) 0096, 0093, 0010, 0085, 0043 teach(es) a requesting entity (e.g., a batch process) may request permission from the operating system of the OE to perform some action (e.g., open a file, access a system resource, etc.) with respect to a specified object; registering a schema of the verifiable credentials in a distributed ledger, periodically receiving new verifiable credentials from a credential repository, validating the new verifiable credentials, and storing the new validated credentials in the wallet, and determining whether to grant, to the subject, access to the object responsive to the request based on comparing the first verifiable MAC label associated with the object and a second verifiable MAC label associated with the subject to a verifiable MAC policy; Cloud computing is a model of service delivery for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a provider of the service), the unified security [bridge] being a custom controller with a unified interface that (i) bridges communication between a blockchain ledger network for [self-sovereign identity (SSI)] and multiple endpoint devices to automate authentication and authorization workflow , (ii) implements a set of common Application Programming Interfaces (APIs) to expand a capability of [SSI], and (iii) includes business logic such that read, write, execute authorization for each endpoint device is programmatically implemented based on schema attribute values of more than one credential schemas from multiple application credential issuers (Olson: Paragraph(s) 0010, 0078, 0083, 0085, 0088, 0094-0095, 0123, 0039, 0098 teach(es) registering a schema of the verifiable credentials in a distributed ledger, periodically receiving new verifiable credentials from a credential repository, validating the new verifiable credentials, and storing the new validated credentials in the wallet, and determining whether to grant, to the subject, access to the object responsive to the request based on comparing the first verifiable MAC label associated with the object and a second verifiable MAC label associated with the subject to a verifiable MAC policy; Entities within the MAC orchestration system that will be issuing verified credentials (e.g., the OE(s), the system owners, the system admins, and the resource owners/stewards) may register their DIDs and DID documents with the identity network. The DID document(s), in turn, may contain the associated entity's preferred authentication mechanisms and service endpoints. The identity network may publish digitally signed credential schemas, such as a MAC label schema and a MAC access policy schema, to be held in a ledger credential schema registry; embodiments that support self-service identity and decentralized credential issuance may eliminate the need for third-party Certificate Authorities; The blockchain architecture in some embodiments may include one or more applications, which are linked to application programming interfaces (APIs) to access and execute stored program/application code (e.g., chaincode, smart contracts, etc.)); obtaining, by the computing device, a digital certificate from a shared digital wallet (Olson: Paragraph(s) 0077, 0081-0082, 0090-0091 teach(es) The resource owner/steward component in some embodiments may be a user or a process creating, issuing, and/or maintaining the verified labels for the resources for which they are responsible (e.g. the file and the batch process). The resource owner/steward may create/digitally sign a verified label and issue it to an ID Hub/Credential repo, which holds the verified label until the OE puts it in its wallet); obtaining, by the computing device, a validation result associated with the digital certificate from the blockchain ledger network by verifying the digital certificate through the unified security [bridge] (Olson: Paragraph(s) 0082, 0097, 0036 teach(es) the OE agent may perform all the key management and cryptographic operations on behalf of the OE (e.g., digital signing, signature validation, encryption, etc.) and may be authorized to read/write to the associated OE wallet; blockchain transaction addition and validation process (consensus). One or more of the member nodes may endorse transactions based on endorsement policy and may provide an ordering service for all blockchain nodes in the architecture; A DID may resolve to its “DID document,” which may identify the subject's authentication mechanisms (including public keys, digital certificates (i.e., public key certificates), such as x509 certificates, etc.) and communication endpoints); determining, by the computing device, whether the validation result authorizes access to the at least one executable system resource by the endpoint device (Olson: Paragraph(s) 0082, 0086-0087, 0043 teach(es) The OE agent may be a trusted process executing on the OE that acts as agent on behalf of the OE, and that enforces authentication and authorization policies to access the OE-controlled system resources; The identity network blockchain access management system, in some embodiments, may be implemented by using the blockchain to enable associating identities to the entities that have granted access rights to connect/call services provided by the blockchain); sending, by the computing device, authorization to the endpoint device to deny or permit the endpoint device access to the at least one system resource based on the validation result (Olson: Paragraph(s) 0096, 0078-0079, 0089, 0091 teach(es) the OE MAC enforcement daemon enforces the authorization decision by permitting or denying access by the subject to the requested object; The MAC orchestration system embodiment in FIG. 4A may also include a plurality of identity hubs/credential repositories (“ID hub”). These ID hubs may act as OE accessible service endpoints to securely store and share signed VLs).
However, Olson does not explicitly teach bridge, self-sovereign identity (SSI), and permitting, by the computing device, the endpoint device to at least execute executable files, scripts, applications, services, and/or software/hardware products in the at least one executable system resource in an autonomous and decentralized manner based on the authorization.
Toth from same or similar field of endeavor teaches unified security bridge (Toth: Paragraph(s) 0005-0006, 0490 teach(es) identity schemes, bridges, add-ons, and protocols for identity access and management; a generative user-centric identity platform whereby users have and control and use richly specified digital identities by means of a single simple protocol across and “identity layer” that everyone implements), self-sovereign identity (SSI) (Toth: Abstract; Paragraph(s) 0015-0017, 0532-0535 teach(es) Self-Sovereign Digital Identity: denotes electronic identities that are specified and tightly controlled by their owners, specifying selected attributes of the owner, or possibly, none of them), and permitting, by the computing device, the endpoint device to at least execute executable files, scripts, applications, services, and/or software/hardware products in the at least one executable system resource in an autonomous and decentralized manner based on the authorization (Toth: Paragraph(s) 0490, 0508, 0544 teach(es) FIG. 9 depicts user having a smart phone communicating over pre-configured trusted communication channels with a smart card or a smart ring with embedded protected memory store containing private keys and secrets of user; Private keys are never revealed outside the context of the user's personal identity device, while PKI certificate authorities allow the distribution of private keys over networks; Both owners and attesting third-party issuers can register digital identities in a hashed “proof-of-existence” identity registry—possibly a distributed ledger system (blockchain)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Olson to incorporate the teachings of Toth for bridge, self-sovereign identity (SSI), and permitting, by the computing device, the end point device to at least execute executable files, scripts, applications, services, and/or software/hardware products in the at least one executable system resource in an autonomously and decentralized manner based on the authorization.
There is motivation to combine Toth into Olson because Toth’s teachings of unified security bridge and Self-Sovereign Digital Identity would facilitate to control and use richly specified digital identities by means of a single simple protocol across and “identity layer” (Toth: Abstract; Paragraph(s) 0005-0006).
Regarding Claim 2, the combination of Olson and Toth teaches all the limitations of claim 1 above; and Olson further teaches wherein the shared digital wallet is associated with multiple endpoints of a single owner, and each endpoint device includes one or digital certificates from multiple issuers which, depending on business rules, all or any combination of which need to be verified for access to executable system resources by each endpoint device (Olson: Paragraph(s) 0060, 0036, 0039, 0043; Fig. 1 teach(es) one or more cloud computing nodes 10 with which local computing devices used by cloud consumers, such as, for example, personal digital assistant (PDA) or cellular telephone 54A, desktop computer 54B, laptop computer 54C, and/or automobile computer system 54N may communicate; verifiable credentials (VCs) as trusted Mandatory Access Control (MAC) security labels—henceforth referred to as Verifiable Labels (VL). The VLs may include globally unique Decentralized Identifiers (DIDs) based on Uniform Resource Identifiers (URI) that are both resolvable and verifiable. A DID may resolve to its “DID document,” which may identify the subject's authentication mechanisms (including public keys, digital certificates (i.e., public key certificates), such as x509 certificates, etc.) and communication endpoints).
Regarding Claim 4, the combination of Olson and Toth teaches all the limitations of claim 3 and the bridge above; and Olson further teaches wherein the verifiable credentials of the endpoint device are sent from a verifier agent to the unified security [bridge] which sends the validation result to the endpoint device (Olson: Paragraph(s) 0082, 0089-0091 teach(es) Each operating environment may further include an OE policy enforcement point agent (“OE agent”)).
Regarding Claim 5, the combination of Olson and Toth teaches all the limitations of claim 4 and the bridge above; and Olson further teaches wherein the unified security [bridge] is scalable to multiple owners of different endpoint devices and multiple endpoints (Olson: Paragraph(s) 0048 teach(es) Rapid elasticity: capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out and rapidly released to quickly scale in).
Regarding Claim 6, the combination of Olson and Toth teaches all the limitations of claim 4 and the bridge above; and Olson further teaches wherein the verifier agent verifies a wallet ID against the blockchain ledger network and sends the verification to the unified security [bridge] (Olson: Paragraph(s) 0080-0083 teach(es) the OE agent may perform all the key management and cryptographic operations on behalf of the OE (e.g., digital signing, signature validation, encryption, etc.) and may be authorized to read/write to the associated OE wallet; The ledger credential schema registry and the credential revocation registry may be stored on one or more distributed ledgers on a blockchain).
Regarding Claim 7, the combination of Olson and Toth teaches all the limitations of claim 6 above; and Olson further teaches further comprising sending a user ID verify key to the blockchain ledger network and receiving a user ID verification response back to the verifier agent (Olson: Paragraph(s) 0080-0082 teach(es) an OE credential wallet (only one depicted for clarity) that securely stores one or more private keys and local copies of a plurality of verified credentials (collectively VCs) from ID hub(s)).
Regarding Claim 8, the combination of Olson and Toth teaches all the limitations of claim 1 above; and Olson further teaches wherein the determining step comprises receiving the validation result from the blockchain ledger network and determining if verification is successful by determining a verifiable credential is valid and schema attributes satisfy a defined policy, and further comprising sending a decision back to the endpoint device to permit access to the at least one executable system resource when the verifiable credential is valid and the schema attributes satisfy the defined policy (Olson: Paragraph(s) 0078, 0083, 0088, 0094-0095, 0043 teach(es) The identity network may publish digitally signed credential schemas, such as a MAC label schema and a MAC access policy schema, to be held in a ledger credential schema registry).
Regarding Claim 9, the combination of Olson and Toth teaches all the limitations of claim 8 and the bridge above; and Olson further teaches wherein the validation result is sent through the unified security [bridge] that supports a scalable verification model shared amongst multiple endpoint devices each of which provide a request to the unified security [bridge] to access the at least one executable system resource (Olson: Paragraph(s) 0048, 0067, 0071, 0043 teach(es) Rapid elasticity: capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out and rapidly released to quickly scale in; The network interfaces may allow the DPS a to communicate with other DPS over the communications medium).
Regarding Claim 10, the combination of Olson and Toth teaches all the limitations of claim 9 and the bridge above; and Olson further teaches further comprising: obtaining rules from application credential issuers, and applying the rules to credentials associated with the verifiable credentials for the endpoint; and applying the rules by the unified security [bridge] to the verifiable credentials to determine whether the endpoint is permitted access to the at least one executable system resource (Olson: Paragraph(s) 0039, 0043 teach(es) self-service identity and decentralized VL issuance may help to ensure labels and rules are correct and properly applied and maintained. That is, because a VL may be issued and digitally signed by the subject or resource owner rather than traditional labels which are merely unsigned, unaccountable system-level attributes assigned by system security administrators).
Regarding Claim 11, the combination of Olson and Toth teaches all the limitations of claim 10 above; and Olson further teaches wherein the unified security bridge is scalable and communicates between the blockchain ledger network, a verifier agent and multiple endpoints and wherein the verifier agent enables peer-to-peer interactions between agents and/or the blockchain ledger network (Olson: Paragraph(s) 0048, 0067, 0071, as stated above with respect to claim 9; and Paragraph(s) 0111 further teaches FIG. 8A illustrates an example of a permissioned blockchain network, which features a distributed, decentralized peer-to-peer architecture, consistent with some embodiments).
However, the combination of Olson and Toth does not explicitly teach self-sovereign identity.
Toth further teaches self-sovereign identity (Toth: Abstract; Paragraph(s) 0015-0017, 0532-0535).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of the combination of Olson and Toth to incorporate the teachings of Toth for self-sovereign identity.
There is motivation to combine Toth into the combination of Olson and Toth because Toth’s teachings of self-sovereign digital identity would facilitate provisioning unique digital identities to people (Toth: Abstract).
Regarding Claim 12, the combination of Olson and Toth teaches all the limitations of claim 1 above; and Olson further teaches wherein the computing device includes software provided as a service in a cloud environment (Olson: Paragraph(s) 0041-0043).
Claim(s) 13-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Olson (US 20220043902 A1) in view of Toth (US 20190097812 A1), and in further view of Panchamia (US 20220393883 A1; already of record in IDS).
Regarding Claim 13, Olson teaches A computer program product comprising one or more computer readable storage media having program instructions collectively stored on the one or more computer readable storage media, the program instructions executable to (Olson: Paragraph(s) 0165-0166):
obtain a device request to access at least one executable system resource residing on a network-based infrastructure through a unified security [bridge] (Olson: Paragraph(s) 0096, 0093, 0010, 0085, 0043 teach(es) a requesting entity (e.g., a batch process) may request permission from the operating system of the OE to perform some action (e.g., open a file, access a system resource, etc.) with respect to a specified object; registering a schema of the verifiable credentials in a distributed ledger, periodically receiving new verifiable credentials from a credential repository, validating the new verifiable credentials, and storing the new validated credentials in the wallet, and determining whether to grant, to the subject, access to the object responsive to the request based on comparing the first verifiable MAC label associated with the object and a second verifiable MAC label associated with the subject to a verifiable MAC policy; Cloud computing is a model of service delivery for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a provider of the service) that bridges communication between multiple devices and a blockchain ledger network for [self-sovereign identity (SSI)] that supports verifiable credentials based on [zero-knowledge proof (ZKP) technology] to automate authentication and authorization workflow, the unified security bridge comprising a custom controller with a unified interface where a set of common Application Programming Interfaces (APIs) is implemented to expand a capability of [SSI] (Olson: Paragraph(s) 0086, 0098, 0039, 0098 teach(es) OEs may only connect to the blockchain via nodes, which authenticates and authorizes them. OEs in these embodiments may invoke a blockchain network API to submit transactions, query transaction states, and attributes, etc.; The blockchain architecture in some embodiments may include one or more applications, which are linked to application programming interfaces (APIs) to access and execute stored program/application code (e.g., chaincode, smart contracts, etc.); embodiments that support self-service identity and decentralized credential issuance may eliminate the need for third-party Certificate Authorities; The blockchain architecture in some embodiments may include one or more applications, which are linked to application programming interfaces (APIs) to access and execute stored program/application code (e.g., chaincode, smart contracts, etc.)); obtain verifiable credentials of the device requesting access to the at least one executable system resource from a shared digital wallet (Olson: Paragraph(s) 0077, 0081-0082, 0090-0091, 0097, 0043 teach(es) The resource owner/steward component in some embodiments may be a user or a process creating, issuing, and/or maintaining the verified labels for the resources for which they are responsible (e.g. the file and the batch process). The resource owner/steward may create/digitally sign a verified label and issue it to an ID Hub/Credential repo, which holds the verified label until the OE puts it in its wallet; the OE agent may perform all the key management and cryptographic operations on behalf of the OE (e.g., digital signing, signature validation, encryption, etc.) and may be authorized to read/write to the associated OE wallet; blockchain transaction addition and validation process (consensus). One or more of the member nodes may endorse transactions based on endorsement policy and may provide an ordering service for all blockchain nodes in the architecture; Cloud computing is a model of service delivery for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a provider of the service); validate the verifiable credentials with the blockchain ledger network through the unified security [bridge] (Olson: Paragraph(s) 0082, 0086-0087, 0036 teach(es) The OE agent may be a trusted process executing on the OE that acts as agent on behalf of the OE, and that enforces authentication and authorization policies to access the OE-controlled system resources; The identity network blockchain access management system, in some embodiments, may be implemented by using the blockchain to enable associating identities to the entities that have granted access rights to connect/call services provided by the blockchain; A DID may resolve to its “DID document,” which may identify the subject's authentication mechanisms (including public keys, digital certificates (i.e., public key certificates), such as x509 certificates, etc.) and communication endpoints); permit the device access to the at least one executable system resource based on a successful validation result of the device (Olson: Paragraph(s) 0096, 0078-0079, 0089, 0091, 0043 teach(es) the OE MAC enforcement daemon enforces the authorization decision by permitting or denying access by the subject to the requested object; The MAC orchestration system embodiment in FIG. 4A may also include a plurality of identity hubs/credential repositories (“ID hub”). These ID hubs may act as OE accessible service endpoints to securely store and share signed VLs0067); and …, wherein the unified security [bridge] includes business logic such that read, write, execute authorization for each device is programmatically implemented based on schema attribute values of more than one credential schemas from multiple application credential issuers (Olson: Paragraph(s) 0010, 0078, 0083, 0085, 0088, 0094-0095, 0123 teach(es) registering a schema of the verifiable credentials in a distributed ledger, periodically receiving new verifiable credentials from a credential repository, validating the new verifiable credentials, and storing the new validated credentials in the wallet, and determining whether to grant, to the subject, access to the object responsive to the request based on comparing the first verifiable MAC label associated with the object and a second verifiable MAC label associated with the subject to a verifiable MAC policy; Entities within the MAC orchestration system that will be issuing verified credentials (e.g., the OE(s), the system owners, the system admins, and the resource owners/stewards) may register their DIDs and DID documents with the identity network. The DID document(s), in turn, may contain the associated entity's preferred authentication mechanisms and service endpoints. The identity network may publish digitally signed credential schemas, such as a MAC label schema and a MAC access policy schema, to be held in a ledger credential schema registry).
However, Olson does not explicitly teach bridge, self-sovereign identity (SSI), and permit the device to execute executable files, scripts, applications, services, and/or software/hardware products in the at least one executable system resource in an autonomous and decentralized manner based on the access.
Toth from same or similar field of endeavor teaches unified security bridge (Toth: Paragraph(s) 0005-0006, 0490 teach(es) identity schemes, bridges, add-ons, and protocols for identity access and management; a generative user-centric identity platform whereby users have and control and use richly specified digital identities by means of a single simple protocol across and “identity layer” that everyone implements), self-sovereign identity (SSI) (Toth: Abstract; Paragraph(s) 0015-0017, 0532-0535 teach(es) Self-Sovereign Digital Identity: denotes electronic identities that are specified and tightly controlled by their owners, specifying selected attributes of the owner), and permit the device to execute executable files, scripts, applications, services, and/or software/hardware products in the at least one executable system resource in an autonomous and decentralized manner based on the access (Toth: Paragraph(s) 0490, 0508, 0544 teach(es) FIG. 9 depicts user having a smart phone communicating over pre-configured trusted communication channels with a smart card or a smart ring with embedded protected memory store containing private keys and secrets of user; Private keys are never revealed outside the context of the user's personal identity device, while PKI certificate authorities allow the distribution of private keys over networks; Both owners and attesting third-party issuers can register digital identities in a hashed “proof-of-existence” identity registry—possibly a distributed ledger system (blockchain)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Olson to incorporate the teachings of Toth for bridge, self-sovereign identity (SSI), and permit the device to execute executable files, scripts, applications, services, and/or software/hardware products in the at least one executable system resource in an autonomously and decentralized manner based on the access.
There is motivation to combine Toth into Olson because Toth’s teachings of unified security bridge would facilitate to control and use richly specified digital identities by means of a single simple protocol across and “identity layer” (Toth: Paragraph(s) 0005-0006, 0015-0017).
However, the combination of Olson and Toth does not explicitly teach zero-knowledge proof (ZKP) technology.
Panchamia from same or similar field of endeavor teaches zero-knowledge proof (ZKP) technology (Panchamia: Paragraph(s) 0044 teach(es) The system includes a self-sovereign identity (SSI) and Zero-Knowledge-Proof approach to digital identity that gives actors in the system (e.g. owners of devices and devices) the control of their digital identities).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of the combination of Olson and Toth to incorporate the teachings of Panchamia for zero-knowledge proof (ZKP) technology.
There is motivation to combine Viswanathan into the combination of Olson and Toth because Panchamia’s teachings of zero-knowledge proof (ZKP) technology would facilitate control of digital identities (Panchamia: Paragraph(s) 0044).
Regarding Claim 18, Olson teaches A system comprising: a processor, a computer readable memory, one or more computer readable storage media, and program instructions collectively stored on the one or more computer readable storage media, the program instructions executable to (Olson: Paragraph(s) 0165-0166):
[bridge] communication between at least one endpoint device and a blockchain ledger network for [self-sovereign identity (SSI)] that supports verifiable credentials based on [zero-knowledge proof (ZKP)] technology (Olson: Paragraph(s) 0067, 0071, 0039, 0098 teach(es) The network interfaces may allow the DPS a to communicate with other DPS over the communications medium) to automate authentication and authorization workflow through a unified security bridge comprising a custom controller with a unified interface where a set of common Application Programming Interfaces (APIs) is implemented to expand a capability of [SSI] (Olson: Paragraph(s) 0086, 0098, 0039, 0098 teach(es) OEs may only connect to the blockchain via nodes, which authenticates and authorizes them. OEs in these embodiments may invoke a blockchain network API to submit transactions, query transaction states, and attributes, etc.; The blockchain architecture in some embodiments may include one or more applications, which are linked to application programming interfaces (APIs) to access and execute stored program/application code (e.g., chaincode, smart contracts, etc.); embodiments that support self-service identity and decentralized credential issuance may eliminate the need for third-party Certificate Authorities; The blockchain architecture in some embodiments may include one or more applications, which are linked to application programming interfaces (APIs) to access and execute stored program/application code (e.g., chaincode, smart contracts, etc.)), comprising: obtaining verifiable credentials of multiple devices from a shared digital wallet (Olson: Paragraph(s) 0077, 0081-0082, 0090-0091 teach(es) The resource owner/steward component in some embodiments may be a user or a process creating, issuing, and/or maintaining the verified labels for the resources for which they are responsible (e.g. the file and the batch process). The resource owner/steward may create/digitally sign a verified label and issue it to an ID Hub/Credential repo, which holds the verified label until the OE puts it in its wallet); receiving verification from the block chain ledger network that the verifiable credentials are valid and access to an executable system resource residing on a network-based infrastructure is authorized (Olson: Paragraph(s) 0036-0038, 0082, 0097, 0043 teach(es) the OE agent may perform all the key management and cryptographic operations on behalf of the OE (e.g., digital signing, signature validation, encryption, etc.) and may be authorized to read/write to the associated OE wallet; blockchain transaction addition and validation process (consensus). One or more of the member nodes may endorse transactions based on endorsement policy and may provide an ordering service for all blockchain nodes in the architecture; Cloud computing is a model of service delivery for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a provider of the service); and providing authorization to a device of the multiple devices requesting the access to the executable system resource (Olson: Paragraph(s) 0096, 0078-0079, 0089, 0091, 0043 teach(es) the OE MAC enforcement daemon enforces the authorization decision by permitting or denying access by the subject to the requested object; The MAC orchestration system embodiment in FIG. 4A may also include a plurality of identity hubs/credential repositories (“ID hub”). These ID hubs may act as OE accessible service endpoints to securely store and share signed VLs), wherein the unified security [bridge] includes business logic such that read, write, execute authorization for each device is programmatically implemented based on schema attribute values of more than one credential schemas from multiple application credential issuers (Olson: Paragraph(s) 0010, 0078, 0083, 0085, 0088, 0094-0095, 0123 teach(es) registering a schema of the verifiable credentials in a distributed ledger, periodically receiving new verifiable credentials from a credential repository, validating the new verifiable credentials, and storing the new validated credentials in the wallet, and determining whether to grant, to the subject, access to the object responsive to the request based on comparing the first verifiable MAC label associated with the object and a second verifiable MAC label associated with the subject to a verifiable MAC policy; Entities within the MAC orchestration system that will be issuing verified credentials (e.g., the OE(s), the system owners, the system admins, and the resource owners/stewards) may register their DIDs and DID documents with the identity network. The DID document(s), in turn, may contain the associated entity's preferred authentication mechanisms and service endpoints. The identity network may publish digitally signed credential schemas, such as a MAC label schema and a MAC access policy schema, to be held in a ledger credential schema registry).
However, Olson does not explicitly teach the bridge and self-sovereign identity (SSI).
Toth from same or similar field of endeavor teaches unified security bridge (Toth: Paragraph(s) 0005-0006, 0490 teach(es) identity schemes, bridges, add-ons, and protocols for identity access and management; a generative user-centric identity platform whereby users have and control and use richly specified digital identities by means of a single simple protocol across and “identity layer” that everyone implements), and self-sovereign identity (SSI) (Toth: Abstract; Paragraph(s) 0015-0017, 0532-0535 teach(es) Self-Sovereign Digital Identity: denotes electronic identities that are specified and tightly controlled by their owners, specifying selected attributes of the owner).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Olson to incorporate the teachings of Toth for bridge and self-sovereign identity (SSI).
There is motivation to combine Toth into Olson because Toth’s teachings of unified security bridge would facilitate to control and use richly specified digital identities by means of a single simple protocol across and “identity layer” (Toth: Paragraph(s) 0005-0006, 0015-0017).
Regarding Claim 14, the combination of Olson, Toth, and Panchamia teaches all the limitations of claim 13 above; and Olson further teaches further comprising authenticating and authorizing the device to access the at least one executable system resource (Olson: Paragraph(s) 0077, 0081-0082, 0090-0091, 0043).
Regarding Claim 15, the combination of Olson, Toth, and Panchamia teaches all the limitations of claim 14 above; and Olson further teaches wherein the successful validation result is based on policies within the verifiable credentials associated with providing access to executable system resources (Olson: Paragraph(s) 0040, 0081-0082, 0092, 0043 teach(es) credential-based access policies).
Regarding Claim 17, the combination of Olson, Toth, and Panchamia teaches all the limitations of claim 13 and the bridge above; and Olson further teaches wherein the validating of the verifiable credentials is through the unified security [bridge] that supports a scalable verification model shared amongst multiple owners of different devices which request access to the at least one executable system resource (Olson: Paragraph(s) 0048, 0067, 0071, 0043, as stated above with respect to claim 9).
Regarding Claim 20, the combination of Olson, Toth, and Panchamia teaches all the limitations of claim 18 and the bridge above; and Olson further teaches wherein the verification is provided to a verifying agent from the blockchain ledger network, upon a request, and the unified security [bridge] supports a scalable verification model shared amongst multiple providers, the verifiable credentials being in the shared digital wallet which is associated with an owner of multiple devices (Olson: Paragraph(s) 0048, 0060, 0067, 0071, as stated above with respect to claims 2 and 9).
Claim(s) 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Olson in view of Toth and in further view of Panchamia, as applied to claim 1 above, and in further view of Viswanathan (US 20220132303 A1).
Regarding Claim 3, the combination of Olson, Toth, and Panchamia teaches all the limitations of claim 1 and the bridge above; and Olson further teaches wherein the digital certificate includes verifiable credentials of the endpoint device that requests access to the at least one executable system resource (Olson: Paragraph(s) 0077-0082, 0043 teach(es) The resource owner/steward component in some embodiments may be a user or a process creating, issuing, and/or maintaining the verified labels for the resources for which they are responsible (e.g. the file and the batch process)).
However, the combination of Olson, Toth, and Panchamia does not explicitly teach wherein the unified security bridge includes a database that stores connection information between organizations and holders of a digital wallet.
Viswanathan from same or similar field of endeavor teaches wherein the unified security [bridge] includes a database that stores connection information between organizations and holders of a digital wallet (Viswanathan: Paragraph(s) 0028, 0039 teach(es) issuing or maintaining a credentials database comprising authenticated credentials. The IoT platform can compare credentials received from an IoT device with the verified credentials of the credentials database and confirm to the device provisioning system whether or not the credentials presented by the IoT device are in fact authentic).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of the combination of Olson, Toth, and Panchamia to incorporate the teachings of Viswanathan for wherein the unified security [bridge] includes a database that stores connection information between organizations and holders of a digital wallet.
There is motivation to combine Viswanathan into the combination of Olson, Toth, and Panchamia because Viswanathan’s teachings of credentials database would facilitate authentication process (Viswanathan: Paragraph(s) 0028).
Claim(s) 16 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Olson in view of Toth and in further view of Panchamia, as applied to claim 13 above, and in still further view of Cano (US 20210174914 A1).
Regarding Claim 16, the combination of Olson, Toth, and Panchamia teaches all the limitations of claim 13 and the bridge above; and Olson further teaches wherein the shared digital wallet is associated with multiple endpoints of a single owner (Olson: Paragraph(s) 0060; Fig. 1 teach(es) one or more cloud computing nodes 10 with which local computing devices used by cloud consumers, such as, for example, personal digital assistant (PDA) or cellular telephone 54A, desktop computer 54B, laptop computer 54C, and/or automobile computer system 54N may communicate).
However, the combination of Olson, Toth, and Panchamia does not explicitly teach the unified security bridge is based on Hyperledger Aries, and the unified security bridge includes a database that stores connection information between organizations and holders of the shared digital wallet
Cano from same or similar field of endeavor teaches the unified security bridge is based on Hyperledger Aries, and the unified security bridge includes a database that stores connection information between organizations and holders of the shared digital wallet (Cano: Paragraph(s) 0010-0011 teach(es) Hyperledger Aries RFC 0434 Out-of-Band Protocol was proposed in 2020 to deliver out-of-band DIDComm messages using JSON within this protocol, and encodes the messages for public key exchange to establish a secure connection; The standard DID specification of the World Wide Web consortium W3C establish the DID document as a repository of public verifiable cryptography information, so asymmetric public encryption and signing keys are stored in the DID document and are used to be exchanged with others to stablish secure communications (DIDCommunications), to verify digital signatures and to exchange data (e.g.: Hyperledger Aries DIDComm Exchange protocol) both in online and offline modes (Hyperledger Aries Out-Of-Band protocol) through a secure connection).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of the combination of Olson, Toth, and Panchamia to incorporate the teachings of Cano for the unified security bridge is based on Hyperledger Aries, and the unified security bridge includes a database that stores connection information between organizations and holders of the shared digital wallet.
There is motivation to combine Cano into the combination of Olson, Toth, and Panchamia because Cano’s teachings of Hyperledger Aries would facilitate communicating of credentials (Cano: Paragraph(s) 0010-0011).
Regarding Claim 19, the combination of Olson, Toth, and Panchamia teaches all the limitations of claim 18 and the bridge above; and Olson further teaches wherein the verification includes applying rules against the verifiable credentials and … (Olson: Paragraph(s) 0039, as stated above with respect to claim 10).
However, the combination of Olson, Toth, and Panchamia does not explicitly teach the unified security [bridge] is based on Hyperledger Aries.
Cano from same or similar field of endeavor teaches the unified security [bridge] is based on Hyperledger Aries (Cano: Paragraph(s) 0010-0011 teach(es) Hyperledger Aries RFC 0434 Out-of-Band Protocol was proposed in 2020 to deliver out-of-band DIDComm messages using JSON within this protocol, and encodes the messages for public key exchange to establish a secure connection; The standard DID specification of the World Wide Web consortium W3C establish the DID document as a repository of public verifiable cryptography information, so asymmetric public encryption and signing keys are stored in the DID document and are used to be exchanged with others to stablish secure communications (DIDCommunications), to verify digital signatures and to exchange data (e.g.: Hyperledger Aries DIDComm Exchange protocol) both in online and offline modes (Hyperledger Aries Out-Of-Band protocol) through a secure connection).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of the combination of Olson, Toth, and Panchamia to incorporate the teachings of Cano for the unified security [bridge] is based on Hyperledger Aries.
There is motivation to combine Cano into the combination of Olson, Toth, and Panchamia because Cano’s teachings of Hyperledger Aries would facilitate communicating of credentials (Cano: Paragraph(s) 0010-0011).
Response to Arguments
Applicant's arguments filed June 22, 2026 have been fully considered but they are not persuasive.
Regarding applicant' s argument under Claim Rejections - 35 USC § 103 that “Olson and Toth, alone or in combination, do not teach, show, or otherwise reasonably suggest the unified security bridge as recited in independent claim 1,” examiner respectfully argues that, as stated in the previous action, the unified security bridge, controller, or common APIs are not recited with technical details and contexts. The limitations “the unified security bridge being a custom controller with a unified interface that (i) bridges communication between a blockchain ledger network for self-sovereign identity (SSI) and multiple endpoint devices to automate authentication and authorization workflow , (ii) implements a set of common Application Programming Interfaces (APIs) to expand a capability of SSI, and (iii) includes business logic such that read, write, execute authorization for each endpoint device is programmatically implemented based on schema attribute values of more than one credential schemas from multiple application credential issuers” in the step of “obtaining” are nearly non-descriptive because they are not used or related for the other steps and “through the unified security bridge”. It is recommended for the applicant to amend the claims with more technical details and contexts of them.
Conclusion
THIS ACTION IS MADE FINAL. 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CLAY LEE whose telephone number is (571)272-3309. The examiner can normally be reached Monday-Friday 8-5pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, 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.
/CLAY C LEE/Primary Examiner, Art Unit 3699
Prosecution Insights