Office Action 1: Non-Final Rejection (2024-06-04)
Rejection types: 103 - Obviousness, Double Patenting

CLAIMS:
CLAIMS

What is claimed is:

1\. A system comprising:
a memory; and
a processor, operatively coupled to the memory, to perform operations comprising:
receiving a request to provide a post-secrets-provisioning service with respect to a device having a supply chain state corresponding to a supply chain associated with the device;
in response to receiving the request, determining whether to authorize the request;
in response to authorizing the request, obtaining a set of secrets data corresponding to the supply chain state of the device; and
providing the post-secrets-provisioning service by emulating, utilizing the set of secrets data, the device having the supply chain state.
2\. The system of claim 1, wherein determining whether to authorize the request further comprises determining whether a secrets and service provider system has ownership of the device based on a proof of ownership of the device maintained on a distribution ledger.
3\. The system of claim 2, wherein obtaining the set of secrets data comprises generating the set of secrets data using at least one of the distributed ledger or a secrets generator.
4\. The system of claim 1, wherein the supply chain state of the device is one of:a manufacturing provisioning state corresponding to a manufacturing stage of the supply chain associated with a manufacturer of the device, a vendor provisioning state corresponding to a vendor stage of the supply chain associated with a vendor in possession of the device, a network provisioning state corresponding to a network stage of the supply chain associated with an end- use network, and an operational state corresponding to an operational stage of the supply chain.

5\. The system of claim 1, wherein providing the post-secrets-provisioning service comprises at least one of: providing a data or trust verification service, providing a data production service, providing a file authorization service, or providing a service to locate a secrets and service provider system to handle the request.
6\. The system of claim 5, wherein the set of secrets data comprises a previous set of secrets data, and wherein providing the data production service comprises recovering data encrypted with the previous set of secrets data.
7\. The system of claim 5, wherein providing the file authorization service comprises:
generating, using the set of secrets data, an authorization packet comprising an encrypted version of a file; and
sending, to the device, the authorization packet to enable the device to determine whether the encrypted version of the file is valid for decryption by the device.
8\. The system of claim 7, wherein the file comprises at least one of: a document, an application, or a consumable data packet.
9\. A method comprising:
receiving, by at least one processing device, a request to provide a post-secrets- provisioning service with respect to a device having a supply chain state corresponding to a supply chain associated with the device;
in response to receiving the request, determining, by the least one processing device, whether to authorize the request;
in response to authorizing the request, obtaining, by the least one processing device, a set of secrets data corresponding to the supply chain state of the device; and
providing, by the at least one processing device, the post-secrets provisioning service by emulating, utilizing the set of secrets data, the device having the supply chain state.

10\. The method of claim 9, wherein determining whether to authorize the request comprises determining whether a secrets and service provider system owns the device based on a proof of ownership of the device maintained on a distributed ledger.

11\. The method of claim 10, wherein obtaining the set of secrets data comprises generating the set of secrets data using at least one of the distributed ledger or a secrets generator.

12\. The method of claim 9, wherein the supply chain state of the device is one of:a manufacturing provisioning state corresponding to a manufacturing stage of the supply chain associated with a manufacturer of the device, a vendor provisioning state corresponding to a vendor stage of the supply chain associated with a vendor in possession of the device, a network provisioning state corresponding to a network stage of the supply chain associated with an end- use network, and an operational state corresponding to an operational stage of the supply chain.

13\. The method of claim 9, wherein providing the post-secrets-provisioning service comprises at least one of: providing a data or trust verification service, providing a data production service, providing a file authorization service, or providing a service to locate a secrets and service provider system to handle the request.

14\. The method of claim 13, wherein the set of secrets data comprises a previous set of secrets data, and wherein providing the data production service comprises recovering data encrypted with the previous set of secrets data.

15\. The method of claim 13, wherein providing the file authorization service comprises:generating, using the set of secrets data, an authorization packet comprising an encrypted version of a file; and
sending, to the device, the authorization packet to enable the device to determine whether the encrypted version of the file is valid for decryption by the device.

16\. The method of claim 15, wherein the file comprises at least one of: a document, an application, or a consumable data packet.

17\. A non-transitory computer-readable storage medium comprising instructions that, when executed by a processing device, cause the processing device to perform operations comprising:receiving a request to provide a post-secrets-provisioning service with respect to a device having a supply chain state corresponding to a supply chain associated with the device;
in response to receiving the request, determining whether to authorize the request;
in response to authorizing the request, obtaining a set of secrets data corresponding to the supply chain state of the device; and
providing the post-secrets-provisioning service by emulating, utilizing the set of secrets data, the device having the supply chain state.

18\. The non-transitory computer-readable storage medium of claim 17, wherein the set of secrets data comprises a previous set of secrets data, and wherein providing the post-secrets- provisioning service comprises recovering data encrypted with the previous set of secrets data.

19\. The non-transitory computer-readable storage medium of claim 17, wherein providing the post-secrets-provisioning service comprises:generating, using the set of secrets data, an authorization packet comprising an encrypted version of a file; and
sending, to the device, the authorization packet to enable the device to determine whether the encrypted version of the file is valid for decryption by the device.

20\. The non-transitory computer-readable storage medium of claim 19, wherein the file comprises at least one of: a document, an application, or a consumable data packet.

OFFICE ACTION:
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 .
This initial written action is responding to the communication dated on 10/27/2023.
Claims 1-20 are submitted for examination.
Claims 1-20 are pending.
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 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.
Priority
This application filed on October 27, 2023 claims priority of parent application 17/488,655 filed on September 29, 2021 which claims priority of a provisional application 63/086,928  filed on October 02, 2020.
Information Disclosure Statement
The following Information Disclosure Statements in the instant application submitted in compliance with the provisions of 37 CFR 1.97, and thus, have been fully considered:
IDS filed on 27 October 2023.
IDS filed on 26 December 2023
IDS filed on 14 May 2024
IDS filed on 21 May 2024.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA  as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-18of U.S. Patent No. 11,853,438. Although the claims at issue are not identical, they are not patentably distinct from each other. Please see comparison table below.
Instant Application 18/496113
US PAT. # US 11,853,438 (App. # 17/488,655)
CRYPTOGRAPHICALLY SECURE POST-SECRETS-PROVISIONING SERVICES
CRYPTOGRAPHICALLY SECURE POST-SECRETS-PROVISIONING SERVICES
1
A system comprising: a memory; and a processor, operatively coupled to the memory, to perform operations comprising: receiving a request to provide a post-secrets-provisioning service with respect to a device having a supply chain state corresponding to a supply chain associated with the device; in response to receiving the request, determining whether to authorize the request; in response to authorizing the request, obtaining a set of secrets data corresponding to the supply chain state of the device; and providing the post-secrets-provisioning service by emulating, utilizing the set of secrets data, the device having the supply chain state.
1
A system comprising: a memory; and a processor, operatively coupled to the memory, to perform operations comprising: receiving a request to provide a post-secrets-provisioning service with respect to a device having a supply chain state corresponding to a supply chain associated with the device, wherein the supply chain state is one of: a manufacturing provisioning state corresponding to a manufacturing stage of the supply chain, a vendor provisioning state corresponding to a vendor stage of the supply chain, a network provisioning state corresponding to a network stage of the supply chain, or an operational state corresponding to an operational stage of the supply chain; in response to receiving the request, determining whether to authorize the request based on a proof of ownership of the device; in response to authorizing the request, obtaining a set of secrets data corresponding to the supply chain state of the device; and emulating, by utilizing the set of secrets data, the device having the supply chain state to provide the post-secrets-provisioning service.
2
The system of claim 1, wherein determining whether to authorize the request further comprises determining whether a secrets and service provider system has ownership of the device based on a proof of ownership of the device maintained on a distribution ledger.
1, 2
…. determining whether to authorize the request based on a proof of ownership - The system of claim 1, further comprising a distributed ledger maintaining the proof of ownership of the device.
3
The system of claim 2, wherein obtaining the set of secrets data comprises generating the set of secrets data using at least one of the distributed ledger or a secrets generator.
3
The system of claim 2, wherein obtaining the set of secrets data comprises generating the set of secrets data using at least one of the distributed ledger or a secrets generator.
4
The system of claim 1, wherein the supply chain state of the device is one of: a manufacturing provisioning state corresponding to a manufacturing stage of the supply chain associated with a manufacturer of the device, a vendor provisioning state corresponding to a vendor stage of the supply chain associated with a vendor in possession of the device, a network provisioning state corresponding to a network stage of the supply chain associated with an end-use network, and an operational state corresponding to an operational stage of the supply chain.
1
….wherein the supply chain state is one of: a manufacturing provisioning state corresponding to a manufacturing stage of the supply chain, a vendor provisioning state corresponding to a vendor stage of the supply chain, a network provisioning state corresponding to a network stage of the supply chain, or an operational state corresponding to an operational stage of the supply chain
5
The system of claim 1, wherein providing the post-secrets-provisioning service comprises at least one of: providing a data or trust verification service, providing a data production service, providing a file authorization service, or providing a service to locate a secrets and service provider system to handle the request.
4
The system of claim 1, wherein providing the post-secrets-provisioning service comprises at least one of: providing a data or trust verification service, providing a data production service, providing a file authorization service, or providing a service to locate a secrets and service provider system to handle the request.
6
The system of claim 5, wherein the set of secrets data comprises a previous set of secrets data, and wherein providing the data production service comprises recovering data encrypted with the previous set of secrets data.
5
The system of claim 4, wherein the set of secrets data comprises a previous set of secrets data, and wherein providing the data production service comprises recovering data encrypted with the previous set of secrets data.
7
The system of claim 5, wherein providing the file authorization service comprises: generating, using the set of secrets data, an authorization packet comprising an encrypted version of a file; and sending, to the device, the authorization packet to enable the device to determine whether the encrypted version of the file is valid for decryption by the device.
6
The system of claim 4, wherein providing the file authorization service comprises: generating, using the set of secrets data, an authorization packet comprising an encrypted version of a file; and sending, to the device, the authorization packet to enable the device to determine whether the encrypted version of the file is valid for decryption by the device.
8
The system of claim 7, wherein the file comprises at least one of: a document, an application, or a consumable data packet.
7
The system of claim 6, wherein the file comprises at least one of: a document, an application, or a consumable data packet.
9
A method comprising: receiving, by at least one processing device, a request to provide a post-secrets-provisioning service with respect to a device having a supply chain state corresponding to a supply chain associated with the device; in response to receiving the request, determining, by the least one processing device, whether to authorize the request; in response to authorizing the request, obtaining, by the least one processing device, a set of secrets data corresponding to the supply chain state of the device; and providing, by the at least one processing device, the post-secrets provisioning service by emulating, utilizing the set of secrets data, the device having the supply chain state.
8
A method comprising: receiving, by a processor, a request to provide a post-secrets-provisioning service with respect to a device having a supply chain state corresponding to a supply chain associated with the device, wherein the supply chain state is one of: a manufacturing provisioning state corresponding to a manufacturing stage of the supply chain, a vendor provisioning state corresponding to a vendor stage of the supply chain, a network provisioning state corresponding to a network stage of the supply chain, or an operational state corresponding to an operational stage of the supply chain; in response to receiving the request, determining, by the processor, whether to authorize the request based on a proof of ownership of the device; in response to authorizing the request, obtaining, by the processor, a set of secrets data corresponding to the supply chain state of the device; and emulating, by the processor utilizing the set of secrets data, the device having the supply chain state to provide the post-secrets-provisioning service.
10
The method of claim 9, wherein determining whether to authorize the request comprises determining whether a secrets and service provider system owns the device based on a proof of ownership of the device maintained on a distributed ledger.
8, 9
..whether to authorize the request based on a proof of ownership of the device - The method of claim 8, wherein the proof of ownership of the device is maintained on a distributed ledger.
11
The method of claim 10, wherein obtaining the set of secrets data comprises generating the set of secrets data using at least one of the distributed ledger or a secrets generator.
10
The method of claim 9, wherein obtaining the set of secrets data comprises generating the set of secrets data using at least one of the distributed ledger or a secrets generator.
12
The method of claim 9, wherein the supply chain state of the device is one of: a manufacturing provisioning state corresponding to a manufacturing stage of the supply chain associated with a manufacturer of the device, a vendor provisioning state corresponding to a vendor stage of the supply chain associated with a vendor in possession of the device, a network provisioning state corresponding to a network stage of the supply chain associated with an end-use network, and an operational state corresponding to an operational stage of the supply chain.
8
wherein the supply chain state is one of: a manufacturing provisioning state corresponding to a manufacturing stage of the supply chain, a vendor provisioning state corresponding to a vendor stage of the supply chain, a network provisioning state corresponding to a network stage of the supply chain, or an operational state corresponding to an operational stage of the supply chain
13
The method of claim 9, wherein providing the post-secrets-provisioning service comprises at least one of: providing a data or trust verification service, providing a data production service, providing a file authorization service, or providing a service to locate a secrets and service provider system to handle the request.
11
The method of claim 8, wherein providing the post-secrets-provisioning service comprises at least one of: providing a data or trust verification service, providing a data production service, providing a file authorization service, or providing a service to locate a secrets and service provider system to handle the request.
14
The method of claim 13, wherein the set of secrets data comprises a previous set of secrets data, and wherein providing the data production service comprises recovering data encrypted with the previous set of secrets data.
12
The method of claim 11, wherein the set of secrets data comprises a previous set of secrets data, and wherein providing the data production service comprises recovering data encrypted with the previous set of secrets data.
15
The method of claim 13, wherein providing the file authorization service comprises: generating, using the set of secrets data, an authorization packet comprising an encrypted version of a file; and sending, to the device, the authorization packet to enable the device to determine whether the encrypted version of the file is valid for decryption by the device.
13
The method of claim 11, wherein providing the file authorization service comprises: generating, using the set of secrets data, an authorization packet comprising an encrypted version of a file; and sending, to the device, the authorization packet to enable the device to determine whether the encrypted version of the file is valid for decryption by the device.
16
The method of claim 15, wherein the file comprises at least one of: a document, an application, or a consumable data packet.
14
The method of claim 13, wherein the file comprises at least one of: a document, an application, or a consumable data packet.
17
A non-transitory computer-readable storage medium comprising instructions that, when executed by a processing device, cause the processing device to perform operations comprising: receiving a request to provide a post-secrets-provisioning service with respect to a device having a supply chain state corresponding to a supply chain associated with the device; in response to receiving the request, determining whether to authorize the request; in response to authorizing the request, obtaining a set of secrets data corresponding to the supply chain state of the device; and providing the post-secrets-provisioning service by emulating, utilizing the set of secrets data, the device having the supply chain state.
15
A non-transitory computer-readable storage medium comprising instructions that, when executed by a processing device, cause the processing device to perform operations comprising: receiving a request to provide a post-secrets-provisioning service with respect to a device having a supply chain state corresponding to a supply chain associated with the device, wherein the supply chain state is one of: a manufacturing provisioning state corresponding to a manufacturing stage of the supply chain, a vendor provisioning state corresponding to a vendor stage of the supply chain, a network provisioning state corresponding to a network stage of the supply chain, or an operational state corresponding to an operational stage of the supply chain, and wherein the post-secrets-provisioning service comprises at least one of: a data or trust verification service, a data production service, a file authorization service, or a service to locate a secrets and service provider system to handle the request; in response to receiving the request, determining whether to authorize the request based on a proof of ownership of the device maintained on a distributed ledger; in response to authorizing the request, obtaining a set of secrets data using the distributed ledger, wherein the set of secrets data corresponds to the supply chain state of the device; and emulating, by utilizing the set of secrets data, the device having the supply chain state to provide the post-secrets-provisioning service.
18
The non-transitory computer-readable storage medium of claim 17, wherein the set of secrets data comprises a previous set of secrets data, and wherein providing the post-secrets-provisioning service comprises recovering data encrypted with the previous set of secrets data.
16
The non-transitory computer-readable storage medium of claim 15, wherein the set of secrets data comprises a previous set of secrets data, wherein the post-secrets-provisioning service is a data production service, and wherein providing the data production service comprises recovering data encrypted with the previous set of secrets data.
19
The non-transitory computer-readable storage medium of claim 17, wherein providing the post-secrets-provisioning service comprises: generating, using the set of secrets data, an authorization packet comprising an encrypted version of a file; and sending, to the device, the authorization packet to enable the device to determine whether the encrypted version of the file is valid for decryption by the device.
17
The non-transitory computer-readable storage medium of claim 15, wherein the post-secrets-provisioning service is a file authorization service, and wherein providing the file authorization service comprises: generating, using the set of secrets data, an authorization packet comprising an encrypted version of a file; and sending, to the device, the authorization packet to enable the device to determine whether the encrypted version of the file is valid for decryption by the device.
20
The non-transitory computer-readable storage medium of claim 19, wherein the file comprises at least one of: a document, an application, or a consumable data packet.
18
The non-transitory computer-readable storage medium of claim 17, wherein the file comprises at least one of: a document, an application, or a consumable data packet.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 5-9 and 13-20 are rejected under 35 U.S.C. 103 as being unpatentable over Ramachandran et al. (US PGPUB. # US 2018/0316492, hereinafter “Ramachandran”), and further in view of Kumar et al. (US PGPUB. # US 2020/0242249, hereinafter “Kumar”).
Referring to Claims 1, 9 and 17:
Regarding Claim 1, Ramachandran teaches,
A system comprising:
a memory  (Fig. 5(66)); and
a processor,  operatively coupled to the memory, to perform operations comprising: (Fig. 5(62))
receiving a request to provide a post-secrets-provisioning service with respect to a device  (¶81, Fig. 8(801), ¶106, “the injector 60 receives or intercepts an inbound message that contains a payload that is to be encrypted or an outbound message that contains a payload that is to be decrypted”, i.e. encrypting a payload or decrypting a payload is considered a request to provide a post-secret-provisioning service) [having a supply chain state corresponding to a supply chain associated with the device];
in response to receiving the request, determining whether to authorize the request; (¶88, “The authentication and authorization module 68 then processes that information to verify the identity of the sender”, Fig. 8(802), ¶106, “ the injector 60 may then verify that the request is authentic and that the requestor is authorized to encrypt or decrypt the data at that node 2”, i.e. determination is made to authorize the request)
in response to authorizing the request, obtaining a set of secrets data  (¶91, Fig. 8, ¶107-¶110, ¶111, “After obtaining the encryption information from memory or the controller 40, the injector 60 uses the encryption information at step 812 to assemble the encryption key”, i.e. secret data is obtain to assemble an encryption key) [corresponding to the supply chain state of the device]; and
providing the post-secrets-provisioning service by emulating, utilizing the set of secrets data, the device (¶92-¶93,  Fig. 8(813-814), ¶111, “at step 813, the injector 60 uses the assembled encryption key to encrypt or decrypt data, as the case may be. The assembly of the encryption key and the encryption or decryption may proceed using any of the methods and protocols discussed above. Once the data is encrypted or decrypted, the injector 60 transmits either the encrypted payload to the node 2 or the decrypted payload to the requesting entity”, i.e. encrypted/decrypted data is provided to the requesting entity) [having the supply chain state].
Ramachandran does not teach explicitly,
[receiving a request to provide a post-secrets-provisioning service with respect to a device] having a supply chain state corresponding to a supply chain associated with the device;
[in response to authorizing the request, obtaining a set of secrets data] corresponding to the supply chain state of the device; and
[providing the post-secrets-provisioning service by emulating, utilizing the set of secrets data, the device] having the supply chain state..
However, Kumar teaches,
[receiving a request to provide a post-secrets-provisioning service with respect to a device] having a supply chain state corresponding to a supply chain associated with the device; (Abstract, “a device historian, across a supply chain of device manufactures and managers, by a plurality of device management services”, ¶106-¶107, ¶118,  ¶121-¶122, “The analytics service may verify the received artifacts and process the operation request to prepare and transmit a record of the detected in-field device activity based on the policy trigger, comprising of at least the episode information, runtime state measurements and device integrity scores”, Fig. 17, ¶130, “FIG. 17 describes a block schema to track change management for a device through a supply chain from a silicon fabrication plant, an original equipment manufacturer (OEM), a platform owner, to a device owner as a distributed ledger in a blockchain “, ¶131,¶134, i.e. supply chain state of the device)
[in response to authorizing the request, obtaining a set of secrets data] corresponding to the supply chain state of the device; (Abstract, “a device historian, across a supply chain of device manufactures and managers, by a plurality of device management services”, ¶106-¶107, ¶118,  ¶121-¶122, “The analytics service may verify the received artifacts and process the operation request to prepare and transmit a record of the detected in-field device activity based on the policy trigger, comprising of at least the episode information, runtime state measurements and device integrity scores”, Fig. 17, ¶130, “FIG. 17 describes a block schema to track change management for a device through a supply chain from a silicon fabrication plant, an original equipment manufacturer (OEM), a platform owner, to a device owner as a distributed ledger in a blockchain “, ¶131,¶134, i.e. supply chain state of the device)  and
[providing the post-secrets-provisioning service by emulating, utilizing the set of secrets data, the device] having the supply chain state.. (Abstract, “a device historian, across a supply chain of device manufactures and managers, by a plurality of device management services”, ¶106-¶107, ¶118,  ¶121-¶122, “The analytics service may verify the received artifacts and process the operation request to prepare and transmit a record of the detected in-field device activity based on the policy trigger, comprising of at least the episode information, runtime state measurements and device integrity scores”, Fig. 17, ¶130, “FIG. 17 describes a block schema to track change management for a device through a supply chain from a silicon fabrication plant, an original equipment manufacturer (OEM), a platform owner, to a device owner as a distributed ledger in a blockchain “, ¶131,¶134, i.e. supply chain state of the device).
As per KSR vs Teleflex, combining prior art elements according to known methods (device, product) to yield predictable results may be used to create a prima facie case of obviousness.
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Kumar with the invention of Ramachandran.
Ramachandran teaches, providing a post secret provisioning service upon checking authorization of a request. Kumar teaches, providing an update service in a supply chain management where a cryptographic data corresponds to a state of the device. Therefore, it would have been obvious to provide an update service in a supply chain management where a cryptographic data corresponds to a state of the device of Kumar with providing a post secret provisioning service upon checking authorization of a request of Ramachandran to  provide significant improvements and efficiencies to retrofit legacy devices for protection and remote device management. KSR Int’l v. Teleflex Inc., 127 S. Ct. 1727, 1740-41, 82 USPQ2d 1385, 1396 (2007).
Regarding Claim 9, it is a method Claim of above System Claim 1 and therefore Claim 9 is rejected with the same rationale as applied against Claim 1 above.
Regarding Claim 17, it is a non-transitory computer-readable storage medium Claim of above System Claim 1 and therefore Claim 9 is rejected with the same rationale as applied against Claim 1 above.
Referring to Claims 5 and 13:
Regarding Claim 5, rejection of Claim 1 is included and for the same motivation Ramachandran does not teach explicitly,
The system of claim 1, wherein providing the post-secrets-provisioning service comprises at least one of: providing a data or trust verification service, providing a data production service, providing a file authorization service, or providing a service to locate a secrets and service provider system to handle the request.
However, Kumar teaches,
The system of claim 1, wherein providing the post-secrets-provisioning service comprises at least one of: providing a data or trust verification service, providing a data production service, providing a file authorization service, or providing a service to locate a secrets and service provider system to handle the request. (Abstract, “a supply chain of device manufactures and managers, by a plurality of device management services comprising an enrollment service, an update service, a policy service, and an analytics service”, Fig. 6, ¶70, “ the update client 603 decrypts the received update package using the private key of the endpoint device 101 (or gateway device 102 for update of self) and the local secure element 401”, Fig. 12, ¶81, ¶105, i.e. Examiner submits that an update service is interpreted as a data production service).
Regarding Claim 13, rejection of Claim 9 is included and Claim 13 is rejected with the same rationale as applied against Claim 5 above.
Referring to Claims 6, 14 and 18:
Regarding Claim 6, rejection of Claim 5 is included and for the same motivation Ramachandran teaches,
The system of claim 5, wherein the set of secrets data comprises a previous set of secrets data, and wherein providing the data production service comprises recovering data encrypted with the previous set of secrets data. (Fig. 8(803, 812, 813), ¶107, “ an injector 60 may temporarily store encryption information, or in some embodiments, it may persistently store certain types of encryption information”, ¶111, “the injector 60 uses the encryption information at step 812 to assemble the encryption key. Then, at step 813, the injector 60 uses the assembled encryption key to encrypt or decrypt data”, i.e. encryption information is considered a previous set of secrets data. an encryption key is generated based on encryption information to decrypt (recover) data).
Regarding Claim 14 rejection of Claim 13 is included and Claim 14 is rejected with the same rationale as applied against Claim 6 above.
Regarding Claim 18 rejection of Claim 17 is included and Claim 18 is rejected with the same rationale as applied against Claim 6 above.
Referring to Claims 7, 15 and 19:
Regarding Claim 7, rejection of Claim 5 is included and for the same motivation Ramachandran does not teach explicitly,
The system of claim 5, wherein providing the file authorization service comprises:
generating, using the set of secrets data, an authorization packet comprising an encrypted version of a file; and
sending, to the device, the authorization packet to enable the device to determine whether the encrypted version of the file is valid for decryption by the device.
However, Kumar teaches,
The system of claim 5, wherein providing the file authorization service comprises:
generating, using the set of secrets data, an authorization packet comprising an encrypted version of a file; (¶21, Fig. 6, ¶101, “the update package 607 using a provider signing key 609, wherein a first digital signature is included in the update package. The method can include encrypting, by the release management system 608, the signed update package using a publisher public key from a publisher certificate 610 for the update publisher 602 for initial encryption of the update package”, i.e. an encrypted version of update package (encrypted version of file) with signature (authorize) is provided) and
sending, to the device, the authorization packet to enable the device to determine whether the encrypted version of the file is valid for decryption by the device. (¶21, Fig. 6, ¶101, “The method can include decrypting, by the update client 603, the encrypted update package using a device private key for the device 101, 102. The method can include verifying, by the update client 603, the first and second digital signatures using the respective public keys from the update provider 601 and publisher certificates issued by a certificate authority 406”, i.e. device determines that the package is valid based on verifying the signatures).
Regarding Claim 15 rejection of Claim 13 is included and Claim 15 is rejected with the same rationale as applied against Claim 7 above.
Regarding Claim 19 rejection of Claim 17 is included and Claim 19 is rejected with the same rationale as applied against Claim 7 above.
Referring to Claims 8, 16 and 20:
Regarding Claim 8, rejection of Claim 7 is included and for the same motivation Ramachandran does not teach explicitly,
The system of claim 7, wherein the file comprises at least one of: a document, an application, or a consumable data packet.
However, Kumar teaches,
The system of claim 7, wherein the file comprises at least one of: a document, an application, or a consumable data packet. (Fig. 6, ¶69, “a developer at a development system 604 builds an unsigned update package 607 from package elements 606 that include an update script and a plurality of component updates such as, for example, firmware updates, software updates, configuration updates, operating system patches/updates, device policies, etc. “, i.e. file is an application).
Regarding Claim 16 rejection of Claim 15 is included and Claim 16 is rejected with the same rationale as applied against Claim 8 above.
Regarding Claim 20 rejection of Claim 19 is included and Claim 20 is rejected with the same rationale as applied against Claim 8 above.
Claims 2-3 and 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over Ramachandran et al. (US PGPUB. # US 2018/0316492, hereinafter “Ramachandran”), and further in view of Kumar et al. (US PGPUB. # US 2020/0242249, hereinafter “Kumar”), and further in view of Dondeti et al. (US PGPUB. # US 2010/0125670, hereinafter “Dondeti”).
Referring to Claims 2 and 10:
Regarding Claim 2, rejection of Claim 1 is included and Ramachandran teaches,
The system of claim 1, [wherein determining whether to authorize the request further comprises determining whether a secrets and service provider system has ownership of the device based on a proof of ownership of the device] maintained on a distribution ledger. (Fig. 1, ¶41).
Combination of Ramachandran and Kumar does not teach explicitly,
The system of claim 1, wherein determining whether to authorize the request further comprises determining whether a secrets and service provider system has ownership of the device based on a proof of ownership of the device [maintained on a distribution ledger].
However, Dondeti teaches,
The system of claim 1, wherein determining whether to authorize the request further comprises determining whether a secrets and service provider system has ownership of the device based on a proof of ownership of the device [maintained on a distribution ledger]. (Fig. 5, ¶72,  “Upon receipt of the storage request 504, storage node B 506 may authenticate the requesting node is in fact the publishing node A 502”, “if the received signature Sig-A matches a locally generated signature of the received Data Value signed with Ver. Cert-A, then the storage node B 506 has successfully verified the authenticity of the storage request 504”, ¶76, “ resource ID verification may be based on providing an authenticatable proof of the first string (e.g., proof of ownership of the publishing node identifier)”, “the storage nodes that accept a service publication storage request to know that a particular type of service/usage (i.e., second string) is authorized”, i.e. request is authorized based on proof of ownership of the node A (device)).
As per KSR vs Teleflex, combining prior art elements according to known methods (device, product) to yield predictable results may be used to create a prima facie case of obviousness.
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Dondeti with the invention of Ramachandran in view of Kumar.
Ramachandran in view of Kumar teaches, providing a post secret provisioning service upon checking authorization of a request and providing an update service in a supply chain management where a cryptographic data corresponds to a state of the device. Dondeti teaches, authorizing request based on verification of the proof of ownership. Therefore, it would have been obvious to authorize a request based on verification of the proof of ownership of Dondeti into the teachings of Ramachandran in view of Kumar to provide a way to allow the data owner to control which nodes/users are allowed to write, modify, or delete a particular resource ID. KSR Int’l v. Teleflex Inc., 127 S. Ct. 1727, 1740-41, 82 USPQ2d 1385, 1396 (2007).
Regarding Claim 10 rejection of Claim 9 is included and Claim 10 is rejected with the same rationale as applied against Claim 2 above.
Referring to Claims 3 and 11:
Regarding Claim 3, rejection of Claim 2 is included and for the same motivation Ramachandran teaches,
The system of claim 2, wherein obtaining the set of secrets data comprises generating the set of secrets data using at least one of the distributed ledger or a secrets generator. (Abstract, “Distributed systems and methods for encrypting data on a blockchain network are disclosed”, “The controller acquires encryption information from the generator, which generates encryption keys and derives encryption information from those encryption keys”, Fig. 1, Fig. 2, ¶41, ¶46, “The generator 20 generates encryption keys that the system 10 uses to encrypt the data stored on the blockchain”).
Regarding Claim 11 rejection of Claim 10 is included and Claim 11 is rejected with the same rationale as applied against Claim 3 above.
Claims 4 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Ramachandran et al. (US PGPUB. # US 2018/0316492, hereinafter “Ramachandran”), and further in view of Kumar et al. (US PGPUB. # US 2020/0242249, hereinafter “Kumar”), and further in view of Charfi et al. (US PGPUB. # US 2013/0151317, hereinafter “Charfi”, provided by the applicant in an IDS).
Referring to Claims 4 and 12:
Regarding Claim 4 rejection of Claim 1 is included and combination of Ramachandran and Kumar does not teach explicitly,
The system of claim 1, wherein the supply chain state of the device is one of: a manufacturing provisioning state corresponding to a manufacturing stage of the supply chain associated with a manufacturer of the device, a vendor provisioning state corresponding to a vendor stage of the supply chain associated with a vendor in possession of the device, a network provisioning state corresponding to a network stage of the supply chain associated with an end-use network, and an operational state corresponding to an operational stage of the supply chain.
However, Charfi teaches,
The system of claim 1, wherein the supply chain state of the device is one of: a manufacturing provisioning state corresponding to a manufacturing stage of the supply chain associated with a manufacturer of the device, (¶28, For example, the client computing device 102 and/or the user 104 may be a service consumer that accesses and uses one or more services provided by the SPL. As discussed in further detail herein, the SPL involves ... one or more service providers 122, one or more service aggregators 126 ... and one or more service gateways 130.; ¶51, The service consumer 214 completes the service supply chain that if effectively fostered by the SDF 200.; ¶65, Referring to FIG.4, a state diagram 400 of an example service provisioning lifecycle (SPL) model for service provisioning lifecycle management (SPLM) in an SDF is depicted. The SPL model for SPLM can include several states, or states, and transitions between states. - A manufacturer is a service provider and may be included in the SPLM provisioning states and stages of the system.) a vendor provisioning state corresponding to a vendor stage of the supply chain associated with a vendor in possession of the device, (¶28 - For example, the client computing device 102 and/or the user 104 may be a service consumer that accesses and
uses one or more services provided by the SPL. As discussed in further detail herein, the SPL involves ... one or more service providers 122, one or more service aggregators 126 ... and one or more service gateways 130. ¶65, Referring to FIG.4, a state diagram 400 of an example service provisioning lifecycle (SPL) model for service provisioning lifecycle management (SPLM) in an SDF is depicted. The SPL model for SPLM can include several states, or states, and transitions between states. - The vendor is a service provider in this marketplace and may be included in the provisional state and stage of the system.)a network provisioning state corresponding to a network stage of the supply chain associated with an end-use network, (Fig. 2, ¶30-¶31, ¶65, Referring to FIG.4, a state diagram 400 of an example service provisioning lifecycle (SPL) model for service provisioning lifecycle management (SPLM) in an SDF is depicted. The SPL model for SPLM can include several states, or states, and transitions between states., ¶66), and an operational state corresponding to an operational stage of the supply chain. (¶65, Referring to FIG.4, a state diagram 400 of an example service provisioning lifecycle (SPL) model for service provisioning lifecycle management (SPLM) in an SDF is depicted. The SPL model for SPLM can include several states, or states, and transitions between states. - The SPLM may include an operational state and stage of the supply chain.).
As per KSR vs Teleflex, combining prior art elements according to known methods (device, product) to yield predictable results may be used to create a prima facie case of obviousness.
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Charfi with the invention of Ramachandran in view of Kumar.
Ramachandran in view of Kumar teaches, providing a post secret provisioning service upon checking authorization of a request and providing an update service in a supply chain management where a cryptographic data corresponds to a state of the device. Charfi teaches, secret data corresponding to various states like manufacturing provisioning state, vendor provisioning state, network provisioning state, operation state. Therefore, it would have been obvious to have secret data corresponding to various states like manufacturing provisioning state, vendor provisioning state, network provisioning state, operation state of Charfi into the teachings of Ramachandran in view of Kumar to provide states and stages throughout the supply chain, as specified by the tenant application. KSR Int’l v. Teleflex Inc., 127 S. Ct. 1727, 1740-41, 82 USPQ2d 1385, 1396 (2007).
Regarding Claim 12 rejection of Claim 9 is included and Claim 12 is rejected with the same rationale as applied against Claim 4 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.  Refer to PTO-892, Notice of References Cited for a listing of analogous art.
Sun et al. (US PGPUB. # US 2021/0382831) discloses, a method for managing user authorizations for blockchain-based services. One of the methods includes: at a service platform, receiving, from a computing device associated with a user, an encryption key and data for storage on a blockchain, wherein the data includes public data and private data, and the encryption key encrypts the private data; storing the encryption key and an identifier (ID) of the data in a cache storage dedicated to storing smart contract data for executing a smart contract; and invoking an application programming interface (API) to enable a blockchain node to initiate a consensus algorithm to record the data and the ID of the data on a blockchain.
Steele et al. (US PGPUB. # US 2020/0403805) discloses, a computer-implemented method for creating authenticable data may include receiving, at a computer server, a credential; storing, in a first data storage, the credential; and generating a credential decentralized identifier (DID) document. The credential DID document may correspond to the credential. The method may further include obtaining a first digital signature, which may be verifiable via a first public cryptographic key. A first attesting DID document may include the first public cryptographic key. The method may further include storing, in the first data storage, the first digital signature; and modifying the first attesting DID document to include a link configured to provide data access to data stored at first location in the first data storage. The data stored at the first location in the first data storage may include the credential or the first digital signature. The method may include obtaining a verifiable credential.
Peter Groarke (US PGPUB. # US 202/0097927) discloses, a method for dispute resolution for a blockchain transaction includes: receiving a dispute request from a first computing device including a blockchain transaction identifier and a reason code; identifying a blockchain data value included in a blockchain that includes the blockchain transaction identifier, a merchant blockchain address, and a currency amount; determining eligibility of the blockchain data value for reversal based on application of one or more reversal rules to at least one of: transaction data included in the blockchain data value or external data identified from the transaction data included in the blockchain data value; performing a dispute resolution process for the blockchain data value that includes receiving a merchant digital signature from a second computing device; and transmitting the merchant digital signature and the currency amount to a node in the blockchain network associated with the blockchain.
Jayaram et al. (US PGPUB. # US 2020/0074415) discloses,  a method as described. In one implementation, a collateral optimization system includes a data ingestion engine that receives information associated with a trade and a collateral optimization module configured to optimize collateral associated with the trade. The collateral can be optimized for yield maximization or cost minimization. An asset settlement engine moves assets between multiple counterparties associated with the trade.
Jorg Ruckriemen (WIPO PUB. # WO 2020/001996) discloses,  a method for protection against falsification and for handover control of consumer goods using a blockchain (106). The method comprises, in the event of a production of a consumer good, receiving a registration request (208) to register the consumer good in the blockchain (106) and executing first program instructions of the program module (108), as a result of which the consumer good is registered in the blockchain (106). The method further comprises, once or a plurality of times, in the event of a change in owner of the registered consumer good, receiving a transfer confirmation request (208, 228, 248) and executing second program instructions of the program module (108), as a result of which an authorization to transfer the consumer good is assigned to a further owner in replacement of the previous owner. The method further comprises, in the event of a final handover of the consumer good to an end user, receiving a final handover confirmation request (228, 248) and executing third program instructions of the program module (108), as a result of which a final handover note, stipulating that the consumer good cannot be transferred again, is assigned to the consumer good.

APPLICANT REBUTTAL: REMARKS
Applicant respectfully requests reconsideration of this application as amended and in view of the following remarks.
Summary of the Office Action
Claims 1-20 stand rejected on the ground of nonstatutory obviousness-type double patenting as allegedly being unpatentable over claims 1-18 of U.S. Patent No. 11,853,438.
Claims 1, 5-9 and 13-20 stand rejected under 35 U.S.C. § 103 as allegedly being unpatentable over U.S. Patent Application Publication No. 2018/0316492 to Ramachandran et al. (hereinafter "Ramachandran") in view of U.S. Patent Application Publication No. 2020/0242249 to Kumar et al. (hereinafter "Kumar").
Claims 2, 3, 10 and 11 stand rejected under 35 U.S.C. § 103 as allegedly being unpatentable over Ramachandran, in view of Kumar, and further in view of U.S. Patent Application Publication No. 2010/0125670 to Dondeti et al. (hereinafter "Dondeti").
Claims 4 and 12 stand rejected under 35 U.S.C. § 103 as allegedly being
unpatentable over Ramachandran, in view of Kumar, and further in view of U.S. Patent Application Publication No. 2013/0151317 to Charfi et al. (hereinafter "Charfi").
Status of the Claims
Claims 1-3, 5, 9-11, 13 and 17-19 are currently amended. Support for these
amendments may be found in, e.g., originally filed claims 2 and 10. No new matter has been added as a result of these amendments. Accordingly, claims 1-20 are pending.
Summary of Examiner Interview
Applicant thanks the Examiner for the telephonic interview conducted between the Examiner and Applicant's representative on July 29, 2024. In particular, the rejection of claim 1 under 35 U.S.C. §102(a)(1) and the Examiner's interpretation of the cited art were discussed. While no specific agreement was reached regarding allowability, the Examiner indicated that amendments of the type made herein would overcome the current grounds of rejection.
Response to Double Patenting Rejection
Claims 1-20 stand rejected on the ground of nonstatutory obviousness-type double patenting as allegedly being unpatentable over claims 1-18 of U.S. Patent No. 11,853,438. Applicant recognizes that a properly executed terminal disclaimer under 37 CFR § 1.321 will be sufficient to overcome this rejection. Although Applicant disagrees with the rejection, Applicant will file a terminal disclaimer to obviate the double patenting rejection upon resolution of remaining matters. Hence, the Examiner is respectfully requested to hold the double patenting rejection in abeyance pending the resolution of the remaining matters.
Response to Rejections under 35 U.S.C.
Q
Claims 1, 5-9 and 13-20 stand rejected under 35 U.S.C. § 103 as allegedly being unpatentable over Ramachandran in view of Kumar.
Applicant respectfully submits that claims 1 and 9 are patentable over the cited reference because Ramachandran does not disclose all of the features of the claims. For example, claim 1 recites:
1.    A system comprising:
a memory;
a processor, operatively coupled to the memory, to perform
operations comprising:
receiving a request to provide a service with respect to a device having a supply chain state corresponding to a supply chain
associated with the device;
determining whether to authorize the request based on a proof of ownership of the device;
in response to authorizing the request, obtaining a set of secrets data corresponding to the supply chain state of the device;
and
providing the service by emulating, utilizing the set of secrets data, the device having the supply chain state.
Applicant respectfully submits that Ramachandran and Kumar, either separately or in combination, fail to teach or suggest at least the bolded elements of claim 1. For example, in rejecting originally filed claim 1, the Office Action at page 10 cites to Ramachandran as allegedly teaching "in response to receiving the request, determining whether to authorize the request." In particular, the Office Action states:
in response to receiving the request, determining whether to authorize the
request; ( 88, "The authentication and authorization module 68 then
processes that information to verify the identity of the sender", Fig.
8(802),  106, " the injector 60 may then verify that the request is authentic
and that the requestor is authorized to encrypt or decrypt the data at that
node 2", i.e. determination is made to authorize the request).
Even if, arguendo, verifying that a request is authentic, as taught by Ramachandran, is construed to be analogous to determining whether to authorize a request, Ramachandran does not teach or suggest verifying that the request is authentic based on a proof of ownership of the device. Therefore, Ramachandran does not teach or suggest "determining whether to authorize the request based on a proof of ownership of the device." Kumar does not cure at least these deficiencies of Ramachandran. Accordingly, Ramachandran and Kumar, either separately or in combination, fail to teach or suggest, at least, "determining whether to authorize the request based on a proof of ownership of the device," as recited in claim 1.
For at least the reasons stated above, the combination of Ramachandran and Kumar fails to teach or suggest every element of claim 1. Similar language is also included in independent claims 9 and 17. Therefore, Ramachandran and Kumar, either separately or in combination, fail to teach or suggest every element of claims 1, 9 and 17. Given that claims 5-8, 13-16 and 18-20 directly or indirectly depend on at least one of the above independent claims, at least for reasons similar to those discussed above, it is
respectfully submitted that these dependent claims are patentable over the combination of Ramachandran and Kumar. Accordingly, Applicant respectfully requests that therejection of claims 1, 5-9 and 13-20 under 35 U.S.C. § 103 be withdrawn.
Claims 2, 3, 10 and 11 stand rejected under 35 U.S.C. § 103 as allegedly being unpatentable over Ramachandran, in view of Kumar, and further in view of Dondeti.
Claims 4 and 12 stand rejected under 35 U.S.C. § 103 as allegedly being
unpatentable over Ramachandran, in view of Kumar, and further in view of Charfi.
As discussed above, the combination of Ramachandran and Kumar fails to teach or suggest all of the features of claims 1, 9 and 17. Dondeti and Charfi, either separately or in combination, fail to cure at least these deficiencies of Ramachandran and Kumar. Therefore, Applicant respectfully submits that claims 2-4 and 10-12 are patentable over the cited references. Accordingly, Applicant requests that the rejections of claims 2-24 and 10-12 under 35 U.S.C. § 103 be withdrawn.
It is respectfully submitted that the rejections and objections have been overcome in view of the amendments and remarks set forth herein.
If the Examiner believes a telephone interview would expedite the prosecution of this application, the Examiner is invited to contact the undersigned, Eric C. Merenstein, at (973) 422-6758.
If there are any additional charges, please charge them to Deposit Account No.: 50-1358.
Respectfully submitted,

NEXT OFFICE ACTION: 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 .
This written action is responding to the amendment dated on July 30, 2024.
In the amendment dated on July 30, 2024, claims 1-3, 5, 9-11, 13 and 17-19 have been amended..
Claims 1, 3-9 and 11-20 are allowed.
EXAMINER’S AMENDMENT
An examiner’s amendment to the record appears below.  Should the changes and/or additions be unacceptable to Applicant, an amendment may filed as provided by 37 CFR 1.312.  To ensure consideration of such an amendment, it MUST be submitted no later than the payment of issue fee.
Authorization for this examiner’s amendment was given in a telephone interview with Mr. Dimitry Andreev of registration number 57,428, on August 16, 2024.  During the telephone conference, Mr. Andreev has agreed and authorized the examiner to further amend Claims 1, 3-9 and 11-20 on the amendment dated on July 30, 2024.
Claims
Replacing Claims 1, 3-9 and 11-20 of the amendment dated on July 30, 2024 with the following:
Claims
1.	A system comprising:
a memory; and
a processor, operatively coupled to the memory, to perform operations comprising:
receiving a request to provide a service with respect to a device having a supply chain state corresponding to a supply chain associated with the device;
determining, , whether a secrets and service provider system has ownership of the device;
responsive to determining that the secrets and service provider system has ownership of the device, authorizing the request;
in response to authorizing the request, obtaining a set of secrets data corresponding to the supply chain state of the device; and
providing the service by emulating, utilizing the set of secrets data, the device having the supply chain state.
2.	(Canceled)
3.	The system of claim 1, wherein obtaining the set of secrets data comprises generating the set of secrets data using at least one of a distributed ledger or a secrets generator.
4.	The system of claim 1, wherein the supply chain state of the device is one of: a manufacturing provisioning state corresponding to a manufacturing stage of the supply chain associated with a manufacturer of the device, a vendor provisioning state corresponding to a vendor stage of the supply chain associated with a vendor in possession of the device, a network provisioning state corresponding to a network stage of the supply chain associated with an end-use network, and an operational state corresponding to an operational stage of the supply chain.
5.	The system of claim 1, wherein providing the service comprises at least one of: providing a data or trust verification service, providing a data production service, providing a file authorization service, or providing a service to locate a secrets and service provider system to handle the request.
6.	The system of claim 5, wherein the set of secrets data comprises a previous set of secrets data, and wherein providing the data production service comprises recovering data encrypted with the previous set of secrets data.
7.	The system of claim 5, wherein providing the file authorization service comprises:
generating, using the set of secrets data, an authorization packet comprising an encrypted version of a file; and
sending, to the device, the authorization packet to enable the device to determine whether the encrypted version of the file is valid for decryption by the device.
8.	The system of claim 7, wherein the file comprises at least one of: a document, an application, or a consumable data packet.
9.	A method comprising:
receiving, by at least one processing device, a request to provide a service with respect to a device having a supply chain state corresponding to a supply chain associated with the device;
determining, by the least one processing device,  based on a proof of ownership of the device, whether a secrets and service provider system has ownership of the device;
responsive to determining that the secrets and service provider system has ownership of the device, authorizing the request;
in response to authorizing the request, obtaining, by the least one processing device, a set of secrets data corresponding to the supply chain state of the device; and
providing, by the at least one processing device, the service by emulating, utilizing the set of secrets data, the device having the supply chain state.
10.	(Canceled)
11.	The method of claim 9, wherein obtaining the set of secrets data comprises generating the set of secrets data using at least one of a distributed ledger or a secrets generator.
12.	The method of claim 9, wherein the supply chain state of the device is one of: a manufacturing provisioning state corresponding to a manufacturing stage of the supply chain associated with a manufacturer of the device, a vendor provisioning state corresponding to a vendor stage of the supply chain associated with a vendor in possession of the device, a network provisioning state corresponding to a network stage of the supply chain associated with an end-use network, and an operational state corresponding to an operational stage of the supply chain.
13.	The method of claim 9, wherein providing the service comprises at least one of: providing a data or trust verification service, providing a data production service, providing a file authorization service, or providing a service to locate a secrets and service provider system to handle the request.
14.	The method of claim 13, wherein the set of secrets data comprises a previous set of secrets data, and wherein providing the data production service comprises recovering data encrypted with the previous set of secrets data.
15.	The method of claim 13, wherein providing the file authorization service comprises:
generating, using the set of secrets data, an authorization packet comprising an encrypted version of a file; and
sending, to the device, the authorization packet to enable the device to determine whether the encrypted version of the file is valid for decryption by the device.
16.	The method of claim 15, wherein the file comprises at least one of: a document, an application, or a consumable data packet.
17.	A non-transitory computer-readable storage medium comprising instructions that, when executed by a processing device, cause the processing device to perform operations comprising:
receiving a request to provide a service with respect to a device having a supply chain state corresponding to a supply chain associated with the device;
determining, , whether a secrets and service provider system has ownership of the device;
responsive to determining that the secrets and service provider system has ownership of the device, authorizing the request;
in response to authorizing the request, obtaining a set of secrets data corresponding to the supply chain state of the device; and
providing the service by emulating, utilizing the set of secrets data, the device having the supply chain state.
18.	The non-transitory computer-readable storage medium of claim 17, wherein the set of secrets data comprises a previous set of secrets data, and wherein providing the service comprises recovering data encrypted with the previous set of secrets data.
19.	The non-transitory computer-readable storage medium of claim 17, wherein providing the service comprises:
generating, using the set of secrets data, an authorization packet comprising an encrypted version of a file; and
sending, to the device, the authorization packet to enable the device to determine whether the encrypted version of the file is valid for decryption by the device.
20.	The non-transitory computer-readable storage medium of claim 19, wherein the file comprises at least one of: a document, an application, or a consumable data packet.
Allowable Subject Matter
Claims 1, 3-9 and 11-20 are allowed.
Examiner’s Statement of Reasons for Allowance
The following is an examiner’s statement of reasons for allowance:
Independent claim 1 is allowable based on the amendment presented in amendment dated on July 30, 2024 and the examiner’s amendment dated on August 23, 2024.
Specifically, the independent claim 1 now recites limitations as follows:
“A system comprising:
a memory; and
a processor, operatively coupled to the memory, to perform operations comprising:
receiving a request to provide a service with respect to a device having a supply chain state corresponding to a supply chain associated with the device;
determining, based on a proof of ownership of the device, whether a secrets and service provider system has ownership of the device;
responsive to determining that the secrets and service provider system has ownership of the device, authorizing the request;
in response to authorizing the request, obtaining a set of secrets data corresponding to the supply chain state of the device; and
providing the service by emulating, utilizing the set of secrets data, the device having the supply chain state”.
The cited reference by Ramachandran et al. (US PGPUB. # US 2018/0316492) teaches, an  injector 60 overlays a node 2 in the blockchain network so that the injector 60 can intercept messages and encrypt their data before that data is inserted by the node 2 into new blocks on the chain. The injector 60 is communicatively coupled to both a node 2 in the blockchain and the controller 40. The injector 60 includes a processor 62, an encryption module 64, and it optionally includes a memory 66, an authentication and authorization module 68, an audit module 72, and a data analysis module 74. FIG. 5 provides a block diagram of some components of the injector 60. (¶81). Where the injector 60 receives or intercepts an inbound message that contains a payload that is to be encrypted or an outbound message that contains a payload that is to be decrypted. At step 802, the injector 60 may then verify that the request is authentic and that the requestor is authorized to encrypt or decrypt the data at that node 2. (Fig. 8*801), ¶106). For instance, the injector 60 includes an authentication and authorization module 68. When the injector 60 receives a new message, the injector 60 may transmit certain information to the authentication and authorization module 68. The authentication and authorization module 68 then processes that information to verify the identity of the sender and confirm that the sender has appropriate permissions to enter the data into the blockchain. Provided that the message is authenticated and authorized, the module may provide a confirmation to the injector 60. (¶88). The encryption information is retrieved from the optional memory 66 or requested from the controller 40. Specifically, in embodiments where the injector 60 includes a memory 66 that stores sets of encryption information, the injector 60 (or the encryption module 64) may first check the memory 66 for valid encryption information. If the memory 66 does not contain encryption information (or if it contains expired encryption information), the injector 60 transmits an Encryption Information Request to the controller 40. As discussed above, the controller 40 will, assuming receipt of a valid Encryption Information Request, return the requested encryption information to the injector 60. (¶91). At step 803, the injector 60 determines whether it currently possesses the encryption information that is required to encrypt or decrypt the data. As discussed above, an injector 60 may temporarily store encryption information, or in some embodiments, it may persistently store certain types of encryption information. If the injector 60 possesses the necessary encryption information, the process may skip to step 812. Otherwise, the injector 60 must request the encryption information from the controller 40 and the process proceeds to step 804, where the injector 60 transmits a request to the controller 40 for the encryption information. The request may be the Encryption Information Request discussed above. Next, at step 805, the controller 40 determines whether it possesses the encryption information requested by the injector 60. In some embodiments, the controller 40 may not store encryption information in its memory, in which case step 805 may be skipped. But if the controller 40 does possess the requested encryption information, the process may then skip to step 811. If the controller 40 does not possess the information, the controller 40 proceeds to step 806, where it transmits a request to the generator 20 for the encryption information. The request may be the New Key Command discussed above. The generator 20 receives the request and, at step 807, determines whether the generator 20 already possess an encryption key that is applicable to the requesting entity. If the generator 20 does not possess such an encryption key, the generator proceeds to step 808 to generate a new encryption key for the requesting entity. This step may proceed as described above and may include various authentication or authorization checks before generating the encryption key. Once the generator 20 possesses the appropriate encryption key, whether retrieved from its memory or newly generated, it derives encryption information from the encryption key at step 809. Note however that, in some embodiments, the generator 20 may store encryption information in memory, in which case the generator 20 may not generate new encryption information. The generator 20 then proceeds to step 810 and transmits the requested information to the controller 40. At step 811, the controller 40 possess the requested encryption information (whether from memory or through a request to the generator) and transmits the information to the requesting injector 60. Optionally, the controller 40 may also store the encryption information in its memory, but in many embodiments, the encryption information does not persist on the controller 40. After obtaining the encryption information from memory or the controller 40, the injector 60 uses the encryption information at step 812 to assemble the encryption key. Then, at step 813, the injector 60 uses the assembled encryption key to encrypt or decrypt data, as the case may be. The assembly of the encryption key and the encryption or decryption may proceed using any of the methods and protocols discussed above. Once the data is encrypted or decrypted, the injector 60 transmits either the encrypted payload to the node 2 or the decrypted payload to the requesting entity. The injector 60 also, at step 815, destroys the assembled encryption key so that it does not persist in memory. Depending on the embodiment, the injector 60 may, however, store the encryption information in memory. As discussed above, the encryption information may persist for a limited duration of time or only so long as certain conditions are satisfied. [0112] 3. Obtaining Quorum to Encrypt Data (Fig. 8, ¶107-¶111). Using the pertinent encryption information (whether retrieved from memory 66 or a request to the controller 40), the encryption module 64 proceeds with encrypting the data in the message. As discussed above, the encryption module 64 may use any known technique for encryption, and in a preferred embodiment, it uses the Advanced Encryption Standard. The OpenSSL library is one example of a suitable library for encrypting the message, but any other suitable code library may be used. Before calling the encryption function, an array may be generated based on the size of the message and based on any padding required to accommodate the soon-to-be encrypted message. Thereafter, an encryption function may be called and supplied with the message, the encryption key, and the padded array. The function will then return an array containing the encrypted message. In some embodiments using key shares (such as those based on Shamir's Secret Sharing Algorithm or another key sharing algorithm or protocol), the encryption process may require the injector 60 to cooperate with other injectors in the system 10 to obtain at least k key shares to enable encryption of the data. The injectors 60 are communicatively coupled to one another to accomplish this process, which may be referred to as obtaining quorum. The requirement of quorum is often imposed when multiple parties share an encryption key that is used to encrypt data that is shared between the parties. In general terms, the quorum process requires the injector 60 to contact other injectors and request that they provide their key shares so that at least k key shares are available to reassemble the encryption key. The different processes for obtaining quorum are more fully described below. The encryption key can then be assembled from the at least k key shares and be used to encrypt or decrypt data. Ordinarily, the encryption key is thereafter deleted. In many embodiments, the key shares obtained from other injectors are also deleted, although in some situations, the injector 60 may be permitted to retain the key shares in secure memory for a limited duration of time or based on certain conditions. Certain injectors 60 may also be classified as “trusted” injectors, in which case they may have greater rights to retain key shares. Retaining key shares in memory 66 may be advantageous to enhance processing speed and availability of the system 10. (¶92-¶93).
The reference by Charfi et al. (US PGPUB. # US 2013/0151317) discloses, an example architecture 100 can be used to realize implementations of SPLM in accordance with the present disclosure. For example, the client computing device 102 and/or the user 104 may be a service consumer that accesses and uses one or more services provided by the SPL. As discussed in further detail herein, the SPL involves a service broker 120, one or more service providers 122, one or more service aggregators 124, one or more service channel makers 126, one or more service hosters 128, and one or more service gateways 130. (¶28). The service consumer 214 completes the service supply chain that is effectively fostered by the SDF 200. Thus, the service consumer 214 discovers, selects, configures, negotiates, orders, and consumes the service with the goal of co-creating business value. Through the service consumer 214, parties can manage the last mile integration where services are consumed through different environments. This involves the allocation of resource consuming services to consumer environments in which they operate and the interfacing of consumer environments so that the services required can be accessed at run-time in a secure and reliable way. (¶51). Referring now to FIG. 4, a state diagram 400 of an example service provisioning lifecycle (SPL) model for service provisioning lifecycle management (SPLM) in an SDF is depicted. The SPL model for SPLM can include several stages, or states, and transitions between states. In some implementations, a service transitions from one state to another after one or more provisioning steps have been performed. In some examples, particular users can modify particular artifacts during a state transition. In some examples, service provisioning states can include one or more of Lodged (402), Registered (404), Failed (406), Rejected (408), Brokered (410), Gatewayed (412), Cloud-hosted (414), Channeled (416), and Consumable (418). In some examples, a state can be both Gatewayed and Cloud-hosted (420) at the same time. (Fig. 4, ¶65). FIG. 2 is a block diagram of an example service delivery framework (SDF) 200. The SDF 200 supports a variety of provisioning partners as seen through different roles. In some implementations, the roles include service provider 202, service broker 204, and service aggregator 206. The SDF 200 further includes service channel maker 208, service gateway 210, service hoster 212 and service consumer 214. Different provisioning partners can use particular platform functionalities dedicated for their service provisioning niches, as discussed in further detail below. The functionality offered through the SDF roles combines technical capabilities (e.g. service composition tools, service repository, service adaptation and runtime environment, and network convergence) with business functionality (e.g. customer relations management (CRM) and payments) for supporting various forms of service delivery. Service delivery can be drawn from a foundation layer of components accessed through a service-oriented architecture (SOA) enabled business process platform. In some implementations, an architectural strategy for the SDF 200 recognizes that industry-specific applications 216 may be needed for business networks operating in different industries. Example applications that apply to industry-specific business networks (e.g., eGovernment platforms for one-stop citizens and constituent services) can provide user interfaces (UIs) and logic that, while coded against a generic SPL layer, are specific to particular domains. Example applications can include enterprise applications 218, public sector applications 220, banking applications 222, and transport and logistics applications 224. In some implementations, the applications can be separately deployed as on-premise installations for customers. In some implementations, the applications can be run as on-demand for several customers. Because a variety of domains are targeted, the SDF 200 supports diverse services and diverse consumption modes. (Fig. 2, ¶30-¶31).
The reference by Kumar et al. (US PGPUB. # US 2020/0242249) discloses, at step 620, a transaction record for the device update is generated that includes at least the signed and encrypted device request log, and stored in the local ledger 310 that includes a database function 311. At step 617, the local ledger 625 emits an event 623 that represents a block of device update transactions for integration with applications in a blockchain. At step 621, the update client 603 first verifies the integrity of the received update package using the public key from the provider certificate 615 and the public key from the publisher certificate 614. At step 622, the update client 603 decrypts the received update package using the private key of the endpoint device 101 (or gateway device 102 for update of self) and the local secure element 401. (Fig. 6, ¶70). A method of updating a registered device (e.g., endpoint device 101, gateway device 102) using a development system 604 and a release management system 608 operated by an update provider 601, an update service 107 operated by an update publisher 602, an update client 603 on the device 101, 102, and a local secure element 401 on the device 101, 102. The method can include building, on the development system 604, an update package including at least one of a firmware update, a software update, a configuration update, and an update script. The method can include signing, by the release management system 608, the update package 607 using a provider signing key 609, wherein a first digital signature is included in the update package. The method can include encrypting, by the release management system 608, the signed update package using a publisher public key from a publisher certificate 610 for the update publisher 602 for initial encryption of the update package. The method can include sending, by the release management system 608, the signed and encrypted update package 611 to the update service 107. The method can include requesting, by the update client 603 on the device 101, 102, an update package. The request can include at least the vendor identifier, the model number, and a device certificate 613 for the device. The method can include resigning, by the update service 107, the signed update package using a publisher signing key 618. A second digital signature is included in the update package. The method can include reencrypting, by the update service 107, the doubly signed update package by decrypting the initial encryption using a publisher private key from the update publisher 602, and encrypting the update package using a device public key from the device certificate 613, for final encryption of the update package. The method can include sending, by the update service 107, the encrypted and doubly signed update package 619 to the update client 603 on the device 101, 102. The method can include decrypting, by the update client 603, the encrypted update package using a device private key for the device 101, 102. The method can include verifying, by the update client 603, the first and second digital signatures using the respective public keys from the update provider 601 and publisher certificates issued by a certificate authority 406. In an exemplary embodiment, the update script is executed on the device to apply the update package to the device 101, 102. (¶101).
Craige et al. (US PAT. # US 10,903,991) discloses, a method for distributed signature generation functions to restrict information about a private key, such that the private key does not need to exist in the clear outside of key generation. The system and method enables cryptographic signature generation with t of n participants without requiring the signing private key to be in the clear (e.g., reconstituted) for signing. (Abstract).
Patil et al. (US PGPUB. # US 2020/0226332) discloses, an air-gapped system enables the secure transfer and control of digital assets, such as those associated with crypto-currency. The system includes an Integration Server for receiving requests from an application interface, a Central Control Center for verifying the requests received and authorizing the requests using digital signatures, and multiple Distributed Data Centers, each including a cold Data Center Hardware Security Module (DC HSM). These DC HSMs securely store and manage cryptographic keys. Each Data Center also includes an offline Processing Unit coupling its DC HSM to a dedicated Remote Controlled Server. The Remote Controlled Server receives requests from the Integration Server and forwards them to the Processing Unit of a DC HSM using a Near-Field Communication (NFC) Interface between the two. Preferably, the NFC interface is physically shielded to resist side channel attacks. (Abstract).
Smith et al. (US PGPUB. # US 20180123804) discloses, a  method for a distributed security model that may be used to achieve one or more of the following: authenticate system components; securely transport messages between system components; establish a secure communications channel over a constrained link; authenticate message content; authorize actions; and distribute authorizations and configuration data amongst users' system components in a device-as-a-key system. (Abstract).
Rohloff et al. (US PGPUB. # US 2017/0155628) discloses, a method for fast and secure Proxy Re-Encryption (PRE) using key switching. A first user is assigned first encryption and decryption keys and a second user is assigned second encryption and decryption keys. First encrypted data encrypted with the first encryption key may be re-encrypted using a proxy re-encryption key to simultaneously switch encryption keys by adding the second encryption key and cancelling the first encryption key by the first decryption key to transform the first encrypted data encrypted by the first encryption key to second encrypted data encrypted by the second encryption key, without decrypting the underlying data. The second user may be the sole system device that possesses the (e.g., private) second decryption key to decrypt the second encrypted data. (Abstract).
Takeuchi et al. (US PGPUB. # US 2010/0153746) discloses, a secure memory card of the present patent application has a communication unit receiving encryption data and data to be signed; an encryption/decryption unit subjecting arbitrary data to encryption/decryption processing; a checking unit for checking the data to be signed against a signature stored in the encryption data decrypted by the encryption/decryption unit; a determination unit for determining validity of the data to be signed on the basis of a checking result of the checking unit; and a storage unit for storing, as valid data, data other than the signature of the encryption data including the signature when the determination unit determines that the data to be signed are valid. (Abstract).
However, each of the cited references or reference from the updated search, at least, fails to teach or suggest the limitations regarding “………………whether a secrets and service provider system has ownership of the device; responsive to determining that the secrets and service provider system has ownership of the device, authorizing the request ……”, in combination with the rest of the limitations recited in the independent claim(s).
None of the previous cited prior art references or reference(s) from the updated search yield any specific references that would reasonably, either singularly or in combination with previous cited reference, result a reasonable and proper rejection for each of the cited feature limitations of the independent claim 1 under 35 U.S.C. 102 or 35 U.S.C. 103 with proper motivation.
Claims 9 is a method claim of above system claim 1 and Claim 17 is a non-transitory computer readable storage medium claim of above system claim 1, and therefore, they are also allowed.
Claims 3-8 depend on the allowed claim 1, and therefore, they are also allowed.
Claims 11-16 depend on the allowed claim 9, and therefore, they are also allowed.
Claims 18-20 depend on the allowed claim 17, and therefore, they are also allowed.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and to avoid processing delays, should preferably accompany the issue fee.  Such submissions should be clearly labeled Comments on Statement of Reasons for Allowance.
Conclusion

CITED REFERENCE SUMMARIES: Ref US20200242249A1: Claims:
A method of building a device historian, across a supply chain of device manufactures and managers, by a plurality of device management services comprising an enrollment service, an update service, a policy service, and an analytics service, a transaction connector, a blockchain broker service participating as a node in a blockchain network, and transaction filters, the method comprising: sending, by the plurality of device management services a transaction record over the transaction connector to the blockchain broker service; receiving, by the blockchain broker service, the transaction record; filtering, by the blockchain broker service, information in the transaction record based on the transaction filters; preparing, by the blockchain broker service, a versioned block based on the filtered information from the transaction record; and adding, by the blockchain broker service, the versioned block to the blockchain network.
sending, by the plurality of device management services a transaction record over the transaction connector to the blockchain broker service;
receiving, by the blockchain broker service, the transaction record;
filtering, by the blockchain broker service, information in the transaction record based on the transaction filters;
preparing, by the blockchain broker service, a versioned block based on the filtered information from the transaction record; and
adding, by the blockchain broker service, the versioned block to the blockchain network.
The method of claim 1 , wherein the versioned block is configured for a specific industry sector by operation type, and with at least one of a device, application and operator as an entity, wherein the operator comprises at least one of a portal user and service user.
The method of claim 1 , wherein the versioned block is configured to track a chain of custody of the device based on a trust chain of a root certificate, a platform certificate, and an owner certificate.
The method of claim 1 , wherein the versioned block is configured to track applications on the device based on a trust chain of a root certificate, a platform certificate, an owner certificate, and a service certificate.
The method of claim 1 , wherein the versioned block is configured to track supply chain provenance of device update packages based on a trust chain established across a plurality of provider certificates, a publisher signing certificate, and a device encryption certificate.
The method of claim 5 , wherein the versioned blocks are in a distributed ledger of the blockchain network and are used to trace a history of device management operations orchestrated across the supply chain from a silicon fabrication plant, an original equipment manufacturer, a device owner, a device management service of the plurality of device management services, and in-field operations.
Ref US20200142979A1: Claims:
A system, comprising: a processor of a broker node; a memory on which are stored machine readable instructions that when executed by the processor cause the processor to: connect to a blockchain comprised of an arranger node and a plurality of client nodes; retrieve from the blockchain a request for information sent by a client node of the plurality of the client nodes; decrypt the request for the information with a private key of the broker node; extract a public key of a client associated with the client node from the decrypted request for the information; select a set of client properties based on the public key of the client; generate a modified request for information based on the request for the information and the set of the client properties; and send the modified request for the information to the arranger node.
a processor of a broker node;
a memory on which are stored machine readable instructions that when executed by the processor cause the processor to: connect to a blockchain comprised of an arranger node and a plurality of client nodes; retrieve from the blockchain a request for information sent by a client node of the plurality of the client nodes; decrypt the request for the information with a private key of the broker node; extract a public key of a client associated with the client node from the decrypted request for the information; select a set of client properties based on the public key of the client; generate a modified request for information based on the request for the information and the set of the client properties; and send the modified request for the information to the arranger node.
connect to a blockchain comprised of an arranger node and a plurality of client nodes;
retrieve from the blockchain a request for information sent by a client node of the plurality of the client nodes;
decrypt the request for the information with a private key of the broker node;
extract a public key of a client associated with the client node from the decrypted request for the information;
select a set of client properties based on the public key of the client;
generate a modified request for information based on the request for the information and the set of the client properties; and
send the modified request for the information to the arranger node.
The system of claim 1 , wherein the instructions executed by the processor are further to cause the processor to encrypt the set of the client properties by a proxy cryptographic schema.
The system of claim 2 , wherein the instructions executed by the processor are further to cause the processor to apply the proxy cryptographic schema that uses the private key of the broker node.
The system of claim 1 , wherein the instructions executed by the processor are further to cause the processor to encrypt the modified request for the information with a public key of the arranger node.
The system of claim 1 , wherein the instructions executed by the processor are further to cause the processor to generate the modified request for the information that hides an identity of the client.
The system of claim 1 , wherein the modified request for the information guarantees to the client that the arranger node is creditable.
The system of claim 6 , wherein, in response to the modified request for the information, the arranger node is to send a response to the client node encrypted by the proxy cryptographic schema that proves a credibility of the arranger node to the client.
A method, comprising: connecting, by a broker node, to a blockchain comprised of an arranger node and a plurality of client nodes; retrieving from the blockchain, by the broker node, a request for information sent by a client node of the plurality of the client nodes; decrypting, by the broker node, the request for the information with a private key of the broker node; extracting, by the broker node, a public key of a client associated with the client node from the decrypted request for the information; selecting, by the broker node, a set of client properties based on the public key of the client; generating, by the broker node, a modified request for information based on the request for the information and the set of the client properties; and sending, by the broker node, the modified request for the information to the arranger node.
connecting, by a broker node, to a blockchain comprised of an arranger node and a plurality of client nodes;
retrieving from the blockchain, by the broker node, a request for information sent by a client node of the plurality of the client nodes;
decrypting, by the broker node, the request for the information with a private key of the broker node;
extracting, by the broker node, a public key of a client associated with the client node from the decrypted request for the information;
selecting, by the broker node, a set of client properties based on the public key of the client;
generating, by the broker node, a modified request for information based on the request for the information and the set of the client properties; and
sending, by the broker node, the modified request for the information to the arranger node.
The method of claim 8 , further comprising encrypting the set of the client properties by a proxy cryptographic schema.
The method of claim 9 , further comprising applying the proxy cryptographic schema that uses the private key of the broker node.
The method of claim 8 , further comprising encrypting the modified request for the information with a public key of the arranger node.
The method of claim 8 , further comprising generating the modified request for the information that hides an identity of the client.
The method of claim 8 , wherein the modified request for the information guarantees to the client that the arranger node is creditable.
The method of claim 13 , wherein, in response to the modified request for the information, the arranger node is to send a response to the client node encrypted by the proxy cryptographic schema that proves a credibility of the arranger node to the client.
A non-transitory computer readable medium comprising instructions, that when read by a processor of a broker node, cause the processor to perform: connecting to a blockchain comprised of an arranger node and a plurality of client nodes; retrieving from the blockchain a request for information sent by a client node of the plurality of the client nodes; decrypting the request for the information with a private key of the broker node; extracting a public key of a client associated with the client node from the decrypted request for the information; selecting a set of client properties based on the public key of the client; generating a modified request for information based on the request for the information and the set of the client properties; and sending the modified request for the information to the arranger node.
connecting to a blockchain comprised of an arranger node and a plurality of client nodes;
retrieving from the blockchain a request for information sent by a client node of the plurality of the client nodes;
decrypting the request for the information with a private key of the broker node;
extracting a public key of a client associated with the client node from the decrypted request for the information;
selecting a set of client properties based on the public key of the client;
generating a modified request for information based on the request for the information and the set of the client properties; and
sending the modified request for the information to the arranger node.
The non-transitory computer readable medium of claim 15 , further comprising instructions, that when read by the processor of the broker node, cause the processor to encrypt the set of the client properties by a proxy cryptographic schema.
The non-transitory computer readable medium of claim 16 , further comprising instructions, that when read by the processor, cause the processor to apply the proxy cryptographic schema that uses the private key of the broker node.
The non-transitory computer readable medium of claim 15 , further comprising instructions, that when read by the processor, cause the processor to encrypt the modified request for the information with a public key of the arranger node.
The non-transitory computer readable medium of claim 15 , further comprising instructions, that when read by the processor, cause the processor to generating the modified request for the information that hides an identity of the client.
The non-transitory computer readable medium of claim 15 , wherein the modified request for the information guarantees to the client that the arranger node is creditable.
Ref US20180316492A1: Claims:
A system for encrypting blockchain data comprising: a generator operable to generate an encryption key and to derive n key shares from said encryption key, wherein at least k key shares are required to assemble said encryption key and k is less than or equal to n; a controller communicatively coupled to said generator, wherein said controller is operable to receive a set of said n key shares; and a plurality of injectors, each having a persistent memory, the plurality of injectors comprising: a first injector communicatively coupled to a blockchain network and to said controller, wherein said first injector is operable to receive a first message inbound for said blockchain and to identify a data portion of said message, and wherein said first injector is operable to receive a first portion of said set of n key shares, wherein said first portion is less than k; and a second injector communicatively coupled to said blockchain network, to said controller, and to said first injector, wherein said second injector is operable to receive a second portion of said set of n key shares, wherein said second portion is less than k,
a generator operable to generate an encryption key and to derive n key shares from said encryption key, wherein at least k key shares are required to assemble said encryption key and k is less than or equal to n;
a controller communicatively coupled to said generator, wherein said controller is operable to receive a set of said n key shares; and
a plurality of injectors, each having a persistent memory, the plurality of injectors comprising: a first injector communicatively coupled to a blockchain network and to said controller, wherein said first injector is operable to receive a first message inbound for said blockchain and to identify a data portion of said message, and wherein said first injector is operable to receive a first portion of said set of n key shares, wherein said first portion is less than k; and a second injector communicatively coupled to said blockchain network, to said controller, and to said first injector, wherein said second injector is operable to receive a second portion of said set of n key shares, wherein said second portion is less than k,
a first injector communicatively coupled to a blockchain network and to said controller, wherein said first injector is operable to receive a first message inbound for said blockchain and to identify a data portion of said message, and wherein said first injector is operable to receive a first portion of said set of n key shares, wherein said first portion is less than k; and
a second injector communicatively coupled to said blockchain network, to said controller, and to said first injector, wherein said second injector is operable to receive a second portion of said set of n key shares, wherein said second portion is less than k,
wherein said first injector is operable to request that said second injector transmit said second portion and operable to encrypt said data portion using said first and second portions of said set of n key shares, wherein said encrypted data portion is injected into said blockchain, and
wherein each of said plurality of injectors can read said encrypted data portion, and wherein each of said plurality of injectors stores less than k of said n key shares in said persistent memory.
The system of claim 1 , wherein said generator comprises a true random number generator.
The system of claim 1 , wherein said controller is physically separate from said generator.
The system of claim 1 , wherein said first injector is physically separate from said controller.
The system of claim 1 , wherein said encryption key is an AES-256 encryption key.
The system of claim 1 , wherein said first injector is operable to encrypt using the Advanced Encryption Standard protocol.
The system of claim 1 , wherein said first portion combined with said second portion is greater than or equal to k.
The system of claim 1 , said plurality of injectors further comprising: a third injector communicatively coupled to said blockchain network, to said controller, and to said first injector, wherein said third injector is operable to receive a third portion of said set of n key shares, wherein said third portion is less than (kâ1),
a third injector communicatively coupled to said blockchain network, to said controller, and to said first injector, wherein said third injector is operable to receive a third portion of said set of n key shares, wherein said third portion is less than (kâ1),
wherein said first portion is less than (kâ1) and said second portion is less than (kâ1), and wherein said first injector is operable to request that said third injector transmit said third portion and to use said third portion when encrypting said data portion.
The system of claim 1 , wherein said first injector is operable to encrypt a subsequent data portion of a subsequent message using only said key shares stored in said persistent memory of said plurality of injectors, wherein said first injector is operable to encrypt even if at least one of said controller and said generator is temporarily unavailable.
The system of claim 9 , wherein said first injector has a dataset containing a list of said plurality of injectors having at least one of said n key shares stored in persistent memory.
The system of claim 1 , wherein said second injector is operable to decrypt said encrypted data portion using only said key shares stored in said persistent memory of said plurality of injectors, wherein said second injector is operable to decrypt even if at least one of said controller and said generator is temporarily unavailable.
A method for encrypting blockchain data comprising the steps of: receiving a message inbound for a blockchain network, said message containing a data portion; transmitting a request to a controller for a first portion of a set of n key shares, wherein said set of n key shares are derived from an encryption key and at least k key shares are required to assemble said encryption key, and wherein said first portion is less than k; obtaining from at least one of a plurality of injectors having persistent memory a second portion of said set of n key shares, wherein said second portion is less than k; assembling said encryption key using said first portion and said second portion; extracting said data portion from said message and encrypting said data portion using said encryption key; and injecting said encrypted data portion into said blockchain,
receiving a message inbound for a blockchain network, said message containing a data portion;
transmitting a request to a controller for a first portion of a set of n key shares, wherein said set of n key shares are derived from an encryption key and at least k key shares are required to assemble said encryption key, and wherein said first portion is less than k;
obtaining from at least one of a plurality of injectors having persistent memory a second portion of said set of n key shares, wherein said second portion is less than k;
assembling said encryption key using said first portion and said second portion;
extracting said data portion from said message and encrypting said data portion using said encryption key; and
injecting said encrypted data portion into said blockchain,
wherein each of said plurality of injectors can read said encrypted data portion, and wherein each of said plurality of injectors stores less than k of said set of n key shares in said persistent memory.
A machine readable storage medium having stored thereon a computer program for encrypting blockchain data, the computer program comprising a set of instructions for causing the machine to perform the method of claim 12 .
The method of claim 12 , wherein said encrypting step uses Advanced Encryption Standard protocol to encrypt said data portion.
The method of claim 12 , said obtaining step comprising: transmitting to a first injector in said plurality of injectors a request for a third portion of said set of n key shares; and receiving from said first injector said third portion,
transmitting to a first injector in said plurality of injectors a request for a third portion of said set of n key shares; and
receiving from said first injector said third portion,
wherein said second portion comprises said third portion.
The method of cla
[Truncated to input limit]