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 .
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 January 14, 2026 has been entered.
Response to Amendment
The amendment filed January 14, 2026 has been entered. Claims 1-20 remain pending in the application. Applicant’s amendments to the Claims have overcome each and every objections previously set forth in the Final Office Action mailed October 24, 2025.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Under the Step 1 of the Section 101 analysis, Claims 1-12 are drawn to a method which is within the four statutory categories (i.e., a process), Claims 13-17 are drawn to a non-transitory computer-readable medium which is within the four statutory categories (i.e., a manufacture), and Claims 18-20 are drawn to a system which is within the four statutory categories (i.e. a machine).
Since the claims are directed toward statutory categories, it must be determined if the claims are directed towards a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea). Based on consideration of all of the relevant factors with respect to the claim as a whole, claims 1-20 are determined to be directed to an abstract idea. The rationale for this determination is explained below:
Regarding Claim 1:
Claim 1 is drawn to an abstract idea without significantly more. The claims recite “obtaining, by a computing device, a request from an endpoint device to access at least one system resource through a unified security bridge, the unified security bridge being a unified interface that (i) bridges between a blockchain-based platform and multiple endpoint devices to automate authentication and authorization workflow and (ii) 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; obtaining, by the computing device, a digital certificate from a shared digital wallet; obtaining, by the computing device, a validation result associated with the digital certificate from a blockchain ledger network; determining, by the computing device, whether the validation result authorizes access to the at least one system resource by the endpoint device; sending 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; and permitting, by the computing device, the endpoint device to at least execute executable files, scripts, applications, services, and/or software/hardware products in an autonomous and decentralized manner based on the authorization.”
Under the Step 2A Prong One, the limitations, as underlined above, are processes that, under its broadest reasonable interpretation, cover Certain Methods Of Organizing Human Activity such as fundamental economic principles or practices (including hedging, insurance, mitigating risk). For example, but for the “computing device”, “endpoint device”, “system resource”, “unified security bridge”, “unified interface”, “blockchain-based platform”, “automate”, “programmatically”, “application”, “digital certificate”, “digital wallet”, “blockchain ledger network”, “executable files”, “scripts”, “applications”, “services”, “software/hardware products”, and “autonomous and decentralized manner” language, the underlined limitations in the context of this claim encompass the human activity. The series of steps belong to a typical mitigating risk, because entities interact with one another, exchange and process data or information such as request, certificate, result, and authorization for access management.
Under the Step 2A Prong Two, this judicial exception is not integrated into a practical application. In particular, the claim only recites additional elements – “A method, comprising:”, “computing device”, “endpoint device”, “system resource”, “unified security bridge”, “unified interface”, “blockchain-based platform”, “automate”, “programmatically”, “application”, “digital certificate”, “digital wallet”, “blockchain ledger network”, “executable files”, “scripts”, “applications”, “services”, “software/hardware products”, and “autonomous and decentralized manner”. The additional elements are recited at a high-level of generality (i.e., performing generic functions of an interaction) such that it amounts no more than mere instructions to apply the exception using a generic computer component, merely implementing an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea. Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present, there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present, there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present, there is no effecting a transformation or reduction of a particular article to a different state or thing present, and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present such that the claim as a whole is more than a drafting effort designed to monopolize the exception. Accordingly, these additional elements, individually or in combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
Under the Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements in the process amounts to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claims are not patent eligible.
Regarding Claim 13:
Claim 13 is drawn to an abstract idea without significantly more. The claims recite “obtain a device request to access at least one system resource through a unified security bridge that bridges communication between multiple devices and a blockchain ledger network to automate authentication and authorization workflow, the unified security bridge comprising a controller where a set of common Application Programming Interfaces (APIs) is implemented to expand a capability of a self-sovereign identity; obtain verifiable credentials of the device requesting access to the at least one system resource from a shared digital wallet; validate the verifiable credentials with the blockchain ledger network; permit the device access to the at least one system resource based on a successful validation result of the device; and permit the device to execute executable files, scripts, applications, services, and/or software/hardware products in an autonomous and decentralized manner based on the access, 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.”
Under the Step 2A Prong One, the limitations, as underlined above, are processes that, under its broadest reasonable interpretation, cover Certain Methods Of Organizing Human Activity such as fundamental economic principles or practices (including hedging, insurance, mitigating risk). For example, but for the “device”, “system resource”, “unified security bridge”, “communication”, “devices”, “blockchain ledger network”, “automate”, “controller”, “Application Programming Interfaces (APIs)”, “digital wallet”, “executable files”, “scripts”, “applications”, “services”, “software/hardware products”, and “autonomous and decentralized manner” language, the underlined limitations in the context of this claim encompass the human activity. The series of steps belong to a typical mitigating risk, because entities interact with one another, exchange and process data or information such as request, certificate, result, and authorization for access management.
Under the Step 2A Prong Two, this judicial exception is not integrated into a practical application. In particular, the claim only recites additional elements – “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:”, the “device”, “system resource”, “unified security bridge”, “communication”, “devices”, “blockchain ledger network”, “automate”, “controller”, “Application Programming Interfaces (APIs)”, “digital wallet”, “executable files”, “scripts”, “applications”, “services”, “software/hardware products”, and “autonomous and decentralized manner”. The additional elements are recited at a high-level of generality (i.e., performing generic functions of an interaction) such that it amounts no more than mere instructions to apply the exception using a generic computer component, merely implementing an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea. Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present, there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present, there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present, there is no effecting a transformation or reduction of a particular article to a different state or thing present, and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present such that the claim as a whole is more than a drafting effort designed to monopolize the exception. Accordingly, these additional elements, individually or in combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
Under the Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements in the process amounts to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claims are not patent eligible.
Regarding Claim 18:
Claim 18 is drawn to an abstract idea without significantly more. The claims recite “bridge communication between at least one endpoint device and a blockchain ledger network to automate authentication and authorization workflow through a unified security bridge comprising a controller where a set of common Application Programming Interfaces (APIs) is implemented to expand a capability of a self-sovereign identity, comprising: obtaining verifiable credentials of multiple devices from a shared digital wallet; receiving verification from the block chain ledger network that the verifiable credentials are valid and access to a system resource is authorized; and providing authorization to a device of the multiple devices requesting the system resource access to the system resource, 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.”
Under the Step 2A Prong One, the limitations, as underlined above, are processes that, under its broadest reasonable interpretation, cover Certain Methods Of Organizing Human Activity such as fundamental economic principles or practices (including hedging, insurance, mitigating risk). For example, but for the “communication”, “endpoint device”, “blockchain ledger network”, “automate”, “unified security bridge”, “controller”, “Application Programming Interfaces (APIs)”, “digital wallet”, “system resource”, “device”, and “programmatically” language, the underlined limitations in the context of this claim encompass the human activity. The series of steps belong to a typical mitigating risk, because entities interact with one another, exchange and process data or information such as request, certificate, result, and authorization for access management.
Under the Step 2A Prong Two, this judicial exception is not integrated into a practical application. In particular, the claim only recites additional elements – “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:”, “communication”, “endpoint device”, “blockchain ledger network”, “automate”, “unified security bridge”, “controller”, “Application Programming Interfaces (APIs)”, “digital wallet”, “system resource”, “device”, and “programmatically”. The additional elements are recited at a high-level of generality (i.e., performing generic functions of an interaction) such that it amounts no more than mere instructions to apply the exception using a generic computer component, merely implementing an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea. Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present, there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present, there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present, there is no effecting a transformation or reduction of a particular article to a different state or thing present, and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present such that the claim as a whole is more than a drafting effort designed to monopolize the exception. Accordingly, these additional elements, individually or in combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
Under the Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements in the process amounts to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claims are not patent eligible.
Regarding Claims 2-12, 14-17, and 19-20:
Dependent claims 2-12, 14-17, and 19-20 include additional limitations, for example, “digital wallet”, “endpoint device”, “digital certificates”, and “system resource” (Claim 2); “digital certificate”, “endpoint device”, “system resource”, “unified security bridge”, “database”, and “digital wallet” (Claim 3); “endpoint device” and “bridge” (Claim 4); “bridge” and “endpoint device” (Claim 5); “wallet”, “blockchain ledger network”, and “bridge” (Claim 6); “blockchain ledger network” (Claim 7); “blockchain ledger network”, “endpoint device”, and “system resource” (Claim 8); “bridge” and “endpoint device” (Claim 9); “application”, “bridge”, and “system resource” (Claim 10); “bridge” and “blockchain ledger network” (Claim 11); “computing device”, “software”, and “cloud” (Claim 12); “device” and “system resource” (Claim 14); “system resources” (Claim 15); “digital wallet”, “devices”, “unified security bridge”, “Hyperledger Aries”, “database”, and “digital wallet” (Claim 16); “bridge”, “devices”, and “system resource” (Claim 17); “unified security bridge” and “Hyperledger Aries” (Claim 19); and “blockchain ledger network”, “bridge”, “digital wallet”, and “devices” (Claim 20), but none of these limitations are deemed significantly more than the abstract idea because, as stated above, they require no more than generic computer structures or signals to be executed, and do not recite any Improvements to the functioning of a computer, or Improvements to any other technology or technical field.
Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Furthermore, looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology, and their collective functions merely provide conventional computer implementation or implementing the judicial exception on a generic computer.
Therefore, whether taken individually or as an ordered combination, claims 2-12, 14-17, and 20 are nonetheless rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
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, 4-15, 17-18, and 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).
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 system resource through a unified security [bridge] (Olson: Paragraph(s) 0096, 0093, 0010, 0085 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), the unified security bridge being a unified interface that (i) bridges between a blockchain-based platform and multiple endpoint devices to automate authentication and authorization workflow and (ii) 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 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); 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 a blockchain ledger network (Olson: Paragraph(s) 0082, 0097 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); determining, by the computing device, whether the validation result authorizes access to the at least one system resource by the endpoint device (Olson: Paragraph(s) 0082, 0086-0087 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 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 and permitting, by the computing device, the endpoint device to at least execute executable files, scripts, applications, services, and/or software/hardware products 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) and permitting, by the computing device, the endpoint device to at least execute executable files, scripts, applications, services, and/or software/hardware products 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 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 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 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).
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 system resource through a unified security [bridge] (Olson: Paragraph(s) 0096, 0093, 0010, 0085 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) that bridges communication between multiple devices and a blockchain ledger network to automate authentication and authorization workflow, the unified security bridge comprising a controller where a set of common Application Programming Interfaces (APIs) is implemented to expand a capability of a … identity (Olson: Paragraph(s) 0086, 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.)); obtain verifiable credentials of the device requesting access to the at least one system resource from a shared digital wallet (Olson: Paragraph(s) 0077, 0081-0082, 0090-0091, 0097 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); validate the verifiable credentials with the blockchain ledger network (Olson: Paragraph(s) 0082, 0086-0087 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); permit the device access to the at least one system resource based on a successful validation result of the device (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 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, a self-sovereign identity, and permit the device to execute executable files, scripts, applications, services, and/or software/hardware products 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), a self-sovereign identity (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 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, a self-sovereign identity, and permit the device to execute executable files, scripts, applications, services, and/or software/hardware products 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).
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 (Olson: Paragraph(s) 0067, 0071 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 controller where a set of common Application Programming Interfaces (APIs) is implemented to expand a capability of a … identity (Olson: Paragraph(s) 0086, 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.)), 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 a system resource is authorized (Olson: Paragraph(s) 0036-0038, 0082, 0097 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); and providing authorization to a device of the multiple devices requesting the system resource access to the system resource (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), 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 a self-sovereign identity.
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 a self-sovereign identity (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 a self-sovereign identity.
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 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 a system resource by the each endpoint device (Olson: Paragraph(s) 0060, 0036, 0039; 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 system resource when the verifiable credential is valid and the schema attributes satisfy the defined policy (Olson: Paragraph(s) 0078, 0083, 0088, 0094-0095 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 system resource (Olson: Paragraph(s) 0048, 0067, 0071 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 system resource (Olson: Paragraph(s) 0039 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 for … identity (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).
Regarding Claim 14, the combination of Olson and Toth 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 system resource using a decentralized and … model (Olson: Paragraph(s) 0077, 0081-0082, 0090-0091).
However, Olson does not explicitly teach self-sovereign identity (SSI) security model.
Toth further teaches self-sovereign identity (SSI) security model (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 (SSI) security model.
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 15, the combination of Olson and Toth 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 system resources (Olson: Paragraph(s) 0040, 0081-0082, 0092 teach(es) credential-based access policies).
Regarding Claim 17, the combination of Olson and Toth 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 at least one system resource (Olson: Paragraph(s) 0048, 0067, 0071, as stated above with respect to claim 9).
Regarding Claim 20, the combination of Olson and Toth 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 (US 20220043902 A1) in view of Toth (US 20190097812 A1), as applied to claim 1 above, and in further view of Viswanathan (US 20220132303 A1).
Regarding Claim 3, the combination of Olson and Toth 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 system resource (Olson: Paragraph(s) 0077-0082teach(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 and Toth 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 and Toth 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 and Toth 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 (US 20220043902 A1) in view of Toth (US 20190097812 A1), as applied to claim 13 above, and in further view of Cano (US 20210174914 A1).
Regarding Claim 16, the combination of Olson and Toth 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 and Toth 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 and Toth 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 and Toth because Cano’s teachings of Hyperledger Aries would facilitate communicating of credentials (Cano: Paragraph(s) 0010-0011).
Regarding Claim 19, the combination of Olson and Toth 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 and Toth 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 and Toth 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 and Toth because Cano’s teachings of Hyperledger Aries would facilitate communicating of credentials (Cano: Paragraph(s) 0010-0011).
Response to Arguments
Applicant's arguments filed January 14, 2026 have been fully considered but they are not persuasive.
Regarding applicant’s argument under Claim Rejections - 35 USC § 101 that “the Examiner's interpretation of "mitigating risk" is inappropriate because it fails to account for the fact that any such alleged risk mitigation must be within the context of fundamental economic practices or principles in the § 101 analysis,” examiner respectfully argues that accessing of system resources is within the context of fundamental economic practices or principles, because the system resources include software products, databases, specific files or applications (e.g., local or web-based applications, etc., which is obviously within the context of fundamental economic practices or principles (See Paragraph(s) [0078] of the Specification). Regarding applicant’s further argument that “independent claims 1, 13, and 18 are directed towards an improvement in the technical field of endpoint authentication, and more specifically to using a consortium-based decentralized and self-sovereign identity (SSI) to verify authenticity of authorized endpoint devices to execute executable files, scripts, applications, services, and/or software/hardware products in an autonomous and decentralized manner,” examiner respectfully argues that denying or permitting endpoints access to resources by using certificates can be performed manually by people, and the features of “consortium-based decentralized and self-sovereign identity (SSI)” and “in an autonomous and decentralized manner” are recited without technical details or contexts, thus not providing any improvements to the functioning of the computer or other technology or technical fields. It is recommended for the applicant to amend the claims with more technical details and contexts of the additional elements such as the unified security bridge or the unified interface, or interactions of devices or entities.
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 the unified security bridge, controller, or common APIs are not recited with technical details and contexts. It is recommended for the applicant to amend the claims with more technical details and contexts of them.
Conclusion
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