Office Action 2: Notice of Allowance (2024-09-03)

CLAIMS:
IN THE CLAIMS

What is claimed is:

1\. (Currently amended) 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 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.
2\. (Currently amended) 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\]\] the proof of ownership of the device .
3\. (Currently amended) The system of claim \[\[2\]\] 1, wherein obtaining the set of secrets data comprises generating the set of secrets data using at least one of \[\[the\]\] a distributed ledger or a secrets generator.
4\. (Original) 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\. (Currently amended) 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\. (Original) 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\. (Original) 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\. (Original) The system of claim 7, wherein the file comprises at least one of:a document, an application, or a consumable data packet.

9\. (Currently amended) 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, whether to authorize the request based on a proof of ownership of the device;
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\. (Currently amended) 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\]\] the proof of ownership of the device .

11\. (Currently amended) The method of claim \[\[10\]\] 9, wherein obtaining the set of secrets data comprises generating the set of secrets data using at least one of \[\[the\]\] a distributed ledger or a secrets generator.

12\. (Original) 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\. (Currently amended) 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\. (Original) 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\. (Original) 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\. (Original) The method of claim 15, wherein the file comprises at least one of:a document, an application, or a consumable data packet.

17\. (Currently amended) 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 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.

18\. (Currently amended) 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\. (Currently amended) 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\. (Original) 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 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

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,


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]