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 10/10/2025.
Claim 1 has been amended, Claims 4 and 16 are canceled and all other Claims are previously presented
Claims 1-3, 5-15 and 17-22 are submitted for examination.
Claims 1-3, 5-15 and 17-22 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 371 application filed on June 20, 2023 claims priority of PCT application PCT/US2021/065857 filed on December 31, 2021, which claims priority of a provisional application 63/132,227 filed on December 31, 2020.
Response to Arguments
Applicant’s amendment, filed on October 10, 2025 has claims 1 amended, claims 4 and 16 canceled, and all other claims previously presented. Among the amended claims, claim 1 is an independent claim.
Applicant’s remark, filed on October, 10, 2025 on top of page 7 regarding, “Applicant submits that the drawings comply with MPEP 608.02(d) which approves of "drawing[s] in the form of a graphical drawing symbol or a labeled representation (e.g., a labeled rectangular box)." The original drawings comply with these guidelines. Withdrawal of the objection is thus respectfully requested” has been considered however is not found persuasive. Examiner has pointed out the MPEP § 608.02(d) which states, “Any structural detail that is essential for a proper understanding of the disclosed invention should be shown in the drawing”. Thus it is necessary to provide details of the each flowchart box for the Figures 4 and 5. As an example of the flow chart drawing figure, the Applicant can refer to cited prior art by Simon et al. (US PGPUB. # US 2020/0274692, drawing Figure 4 that has flowchart with details.
Applicant’s remark, filed on October 10, 2025 on bottom of page 7 and top of page 8 regarding, “Though cited portions of Simon do teach "facilitat[ing] the decryption of the encrypted package" (paragraph 62), this does not teach or suggest anything with respect to transmitting encrypted outputs to one or more nodes within a decentralized network... wherein at least one of the one or more nodes within the decentralized network: receives the encrypted outputs as transmitted within the decentralized network and decrypts the received encrypted outputs using a share of a network key, as encompassed by claim 1” has been considered and “though cited portion of Simon do teach "facilitat[ing] the decryption of the encrypted package" is found persuasive however rest of the remark is not found persuasive. Simon teaches, “A smart contract is executable computer code that specifies actions to be taken, or to occur, to implement a contract between two or more entities. A smart contract may be implemented by one or more electronic contract executors (which, in some examples, may be implemented in a computing node of a distributed ledger network). A contract executor automatically carries out the terms of the smart contract by performing one or more actions specified by the smart contract. A smart contract can thereby facilitate automatic verification and performance of an agreement or transaction between multiple parties. Smart contract functionality may be provided by a distributed ledger network, such as the blockchain-based Bitcoin, Ethereum, and Litecoin distributed ledger networks”. (¶21). “The computing system 10 of FIG. 1 includes a contract creator 12 comprising a computing device 14, a contract executor 16 comprising a computing device 18, and a plurality of oracles 20-1-20-N comprising respective computing devices 22-1-22-N. In some examples, the contract executor 16 may comprise a node of a distributed ledger network (e.g., a Bitcoin, Litecoin, or Ethereum distributed ledger network, as non-limiting examples) that maintains a local copy of a distributed ledger (e.g., a blockchain, as a non-limiting example). The contract creator 12, the contract executor 16, and the oracles 20-1-20-N (“C.sub.1-C.sub.N”) are each communicatively coupled to the others via a network 23.”. (¶28). “FIGS. 5A-5F are communication diagrams illustrating communication flows among the elements of the computing system 10 of FIG. 1 for providing smart contracts including sensitive data, according to one example. Elements of FIG. 1 are referenced in describing FIGS. 5A-5F for the sake of clarity. As seen in FIGS. 5A-5F, each of the contract creator 12, the contract executor 16, and the oracles 20-1 and 20-N are represented by vertical lines, with communications between these elements illustrated by captioned arrows, and operations performed by each element illustrated by captioned boxes”. (Figs. 5A-5F, ¶63). Simon further teaches, “Once a subset of at least size R of the symmetric keys 32-1-32-N have been decrypted by the contract executor 16, the contract executor 16 uses the decrypted symmetric keys 32-1-32-N to decrypt the sensitive data 24 of the encrypted package 34 of the smart contract 26. The contract executor 16 then executes the smart contract 26 using the sensitive data 24. To further the example above, the contract executor action 59 may be to sell the stock. The sensitive data 24 of the encrypted package 34 may be the user's (e.g., a party to the smart contract 26) authentication information needed to initiate the sale of the stock. (¶40). “Also for each respective stage 70 of the at least some of the stages 70-1A-70-3A, the contract creator 12 generates an envelope 48 that corresponds to the respective stage 70. The envelope 48 comprises a condition precedent 28 confirmable by an oracle 20, and an encrypted package-decryption key K that is encrypted with the public key 40 of the contract executor 16, the encrypted package-decryption key K, when decrypted, being configured to facilitate the decryption of the encrypted package 34 that corresponds to the respective stage 70, wherein the encrypted package 34 for at least some of the stages 70 comprises an envelope 48 and an encrypted package 34 that corresponds to a next successive stage 70 (FIG. 4, block 1004). The contract creator 12 then sends the smart contract 26-1 to the contract executor 16 (FIG. 4, block 1006)”. Thus Simon teaches, a distributed ledger (decentralized network) has a contract creator node creates an encrypted packet and transmits the encrypted package to contractor execution node which receives the encrypted package within the distributed ledger (decentralized network). The contract execution node decrypts the encrypted package with a key.
Drawings
The drawings are objected to under 37 CFR 1.83(a) because they fail to show details alphabetical description in Figure 4 and Figure 5 as described in the specification. Any structural detail that is essential for a proper understanding of the disclosed invention should be shown in the drawing. MPEP § 608.02(d). Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Examiner suggests providing detail of method steps for each box for the drawing Figure 4 and Figure 5. As an example of the flow chart drawing figure, the Applicant can refer to cited prior art by Simon et al. (US PGPUB. # US 2020/0274692, drawing Figure 4 that has flowchart with details.
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-3 and 5-8 are rejected under 35 U.S.C. 103 as being unpatentable over Bonisch et al. (US PGPUB. # US 2024/0015027, hereinafter “Bonisch”, priority based on foreign application DE 10 2020 130 087.5 filed on 11/13/2020), and further in view of Simon et al. (US PGPUB. # US 2020/0274692, hereinafter “Simon”).
Regarding Claim 1, Bonisch teaches
A system comprising:
a processing device; (¶41) and
receiving one or more outputs from a sensor; (Fig. 3, ¶43, “electronic data are generated by the data generation devices 12 on the basis of the measurements of the sensors 34, 34′, 44, 44′, 46, 46′”, i.e. generated data is output of sensors)
encrypting the received one or more outputs using a public cryptographic key; (Fig. 3, ¶43, “In a cryptography step 72 the data packages 18, 22 are encrypted”, “the data packages 18, 22 are respectively encrypted by means of a key (e. g. a public key)”, i.e. received data is encrypted with a public key).
transmitting the encrypted outputs to one or more nodes within a decentralized network; (Fig. 3, ¶45, “one provision step 14 the electronic data are provided as the data packages 18, 22 via the data transmission network 16”, i.e. encrypted data is transmitted to a blockchain node)
Bonisch does not teach explicitly,
a memory coupled to the processing device and storing instructions that, when executed by the processing device, cause the system to perform one or more operations comprising:
wherein at least one of the one or more nodes within the decentralized network: receives the encrypted outputs as transmitted within the decentralized network and decrypts the received encrypted outputs using a share of a network key.
However, Simon teaches,
a memory coupled to the processing device and storing instructions that, when executed by the processing device, cause the system to perform one or more operations comprising: (Fig. 12, ¶98-¶101)
wherein at least one of the one or more nodes within the decentralized network: receives the encrypted outputs as transmitted within the decentralized network and decrypts the received encrypted outputs using a share of a network key. (¶21, Fig. 1, ¶28, “the contract executor 16 may comprise a node of a distributed ledger network (e.g., a Bitcoin, Litecoin, or Ethereum distributed ledger network, as non-limiting examples) that maintains a local copy of a distributed ledger (e.g., a blockchain, as a non-limiting example) “, ¶40, “the contract executor 16 uses the decrypted symmetric keys 32-1-32-N to decrypt the sensitive data 24 of the encrypted package 34 of the smart contract 26”, Fig. 4, ¶62, “an encrypted package-decryption key K that is encrypted with the public key 40 of the contract executor 16, the encrypted package-decryption key K, when decrypted, being configured to facilitate the decryption of the encrypted package 34 that corresponds to the respective stage 70”, “an encrypted package 34 that corresponds to a next successive stage 70 (FIG. 4, block 1004). The contract creator 12 then sends the smart contract 26-1 to the contract executor 16 (FIG. 4, block 1006)”, Figs. (5A-5F), ¶63-¶72, i.e. Simon teaches a distributed ledger having plurality of nodes where encrypted package is transmitted within the distributed ledger (decentralized network) where encrypted package is decrypted using a key).
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 Simon with the invention of Bonisch.
Bonisch teaches, encrypting data collected by sensors and transmitting to blockchain nodes. Simon teaches, decrypting encrypted data using a key to generate a plain text. Therefore, it would have been obvious to decrypt encrypted data using a key to generate a plain text of Simon with encrypting data collected by sensors and transmitting to blockchain nodes of Bonisch to take actions automatically upon satisfaction of one or more conditions precedent specified by a policy of the smart contract.
KSR Int’l v. Teleflex Inc., 127 S. Ct. 1727, 1740-41, 82 USPQ2d 1385, 1396 (2007).
Regarding Claim 2 rejection of Claim 1 is included and for the same motivation Bonisch does not teach explicitly,
The system of claim 1, wherein the at least one or more nodes within the decentralized network publishes a result of a decryption of the received encrypted outputs to a shared ledger.
However, Simon teaches,
The system of claim 1, wherein the at least one or more nodes within the decentralized network publishes a result of a decryption of the received encrypted outputs to a shared ledger. (¶40, i.e. decrypting sensitive data and executing a smart contract is interpreted as publishing result of the decryption into a shared ledger).
Regarding Claim 3 rejection of Claim 1 is included and for the same motivation Bonisch does not teach explicitly,
The system of claim 3, further comprising initiating one or more operations based on one or more results of the decryption of the received encrypted outputs.
However, Simon teaches,
The system of claim 3, further comprising initiating one or more operations based on one or more results of the decryption of the received encrypted outputs. (¶40, “the contract executor action 59 may be to sell the stock”, ¶57).
Claim 4 – Canceled
Regarding Claim 5 rejection of Claim 1 is included and for the same motivation Bonisch does not teach explicitly,
The system of claim 1, wherein the public key corresponds to a threshold-encryption quorum within the decentralized network.
However, Simon teaches,
The system of claim 1, wherein the public key corresponds to a threshold-encryption quorum within the decentralized network. (¶31, ¶40, Fig. 3, ¶48).
Regarding Claim 6 rejection of Claim 1 is included and for the same motivation Bonisch does not teach explicitly,
The system of claim 1, wherein decrypting the received encrypted outputs comprises generating a portion of a decrypted output.
However, Simon teaches,
The system of claim 1, wherein decrypting the received encrypted outputs comprises generating a portion of a decrypted output. (¶40, “he contract executor 16 uses the decrypted symmetric keys 32-1-32-N to decrypt the sensitive data 24”, i.e. Examiner submits that multiple keys are utilized to decrypt the data indicates that a portion of decrypted output is generated).
Regarding Claim 7 rejection of Claim 1 is included and for the same motivation Bonisch does not teach explicitly,
The system of claim 1, wherein decrypting the received encrypted outputs comprises decrypting the received encrypted outputs using portions of the decrypted output originating from one or more nodes.
However, Simon teaches,
The system of claim 1, wherein decrypting the received encrypted outputs comprises decrypting the received encrypted outputs using portions of the decrypted output originating from one or more nodes. (¶39-¶40, i.e. decrypted output origins from one or more nodes).
Regarding Claim 8 rejection of Claim 1 is included and for the same motivation Bonisch does not teach explicitly,
The system of claim 1, wherein decrypting the received encrypted outputs comprises decrypting the received encrypted outputs using a portions of the decrypted output originating from one or more nodes that meet an threshold-encryption quorum within the decentralized network.
However, Simon teaches,
The system of claim 1, wherein decrypting the received encrypted outputs comprises decrypting the received encrypted outputs using a portions of the decrypted output originating from one or more nodes that meet an threshold-encryption quorum within the decentralized network. (¶39-¶40, “Once a subset of at least size R of the symmetric keys 32-1-32-N have been decrypted by the contract executor 16, the contract executor 16 uses the decrypted symmetric keys 32-1-32-N to decrypt the sensitive data 24 of the encrypted package 34 of the smart contract 26”).
Claims 9-15 and 17-22 are rejected under 35 U.S.C. 103 as being unpatentable over Kim et al. (US PGPUB. # US 2020/0034550, hereinafter “Kim”), and further in view of Simon et al. (US PGPUB. # US 2020/0274692, hereinafter “Simon”).
Referring Claims 9 and 17:
Regarding Claim 17, Kim teaches,
A non-transitory computer readable medium having instructions stored thereon that, when executed by a processing device, cause the processing device to perform operations comprising: (Fig. 2, ¶41).
generating a cryptographic key at a first device; (Fig. 4, ¶64-¶65, “the parent BC nodes to generate the symmetric key K.sub.SD.sup.i that IoT device S and data recipient D will use to encrypt or decrypt data type i at time t, respectively”, i.e. cryptographic key is generated)
encrypting a message with the generated cryptographic key; (Fig. 4, ¶67, “Then S encrypts the data subblock and MAC to generate the encrypted block: EB.sub.t.sup.i=Enc.sub.KSD.sup.i(D.sub.t.sup.i)∥MAC.sub.KsB(D.sub.t.sup.i)”,i.e. data (message) is encrypted)
Kim does not teach explicitly,
encrypting the generated cryptographic key with a public key; and
transmitting the encrypted message and the encrypted generated cryptographic key to one or more nodes within a decentralized network;
wherein the transmitted encrypted message and the encrypted generated cryptographic key are received by a second device, wherein the second device transmits the received encrypted generated cryptographic key to at least one or more nodes within the decentralized network, and wherein the at least one or more nodes within the decentralized network decrypt the received encrypted generated cryptographic key with a share of a network key and publish the result of the decryption of the received encrypted generated cryptographic key to a shared ledger.
However, Simon teaches,
encrypting the generated cryptographic key with a public key; (¶32, “ Each of the symmetric keys 32-1-32-N are then encrypted using a public key e 40 of the contract executor 16”) and
transmitting the encrypted message and the encrypted generated cryptographic key to one or more nodes within a decentralized network; (Fig. 1, ¶34-¶37, ¶38, “the contract executor 16 transmits the envelope 48-1 of the smart contract 26 to the oracle 20-1, as indicated by arrow 62. After receiving the envelope 48-1”, i.e. Examiner submits that an envelop contains encrypted key and the encrypted message. The envelop is transmitted to an Oracle (node of decentralized network)).
wherein the transmitted encrypted message and the encrypted generated cryptographic key are received by a second device, wherein the second device transmits the received encrypted generated cryptographic key to at least one or more nodes within the decentralized network, and wherein the at least one or more nodes within the decentralized network decrypt the received encrypted generated cryptographic key with a share of a network key and publish the result of the decryption of the received encrypted generated cryptographic key to a shared ledger. (Fig. 1, ¶39, “the oracle 20-N, and transmits the wrapper 38-N back to the contract executor 16”, “The contract executor 16 then decrypts the symmetric key 32-N of the wrapper 38-N using the private key E 44”, ¶40, “Once a subset of at least size R of the symmetric keys 32-1-32-N have been decrypted by the contract executor 16, the contract executor 16 uses the decrypted symmetric keys 32-1-32-N to decrypt the sensitive data 24 of the encrypted package 34 of the smart contract 26. The contract executor 16 then executes the smart contract 26 using the sensitive data 24”, ¶42, Examiner submits that oracle is interpreted as first node. The oracle transmits encrypted data and encrypted key to a contract executor. The contract executor is interpreted as second node. The contract executor decrypts the data and executes the contract (i.e. published decrypted data to a blockchain).
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 Simon with the invention of Kim.
Kim teaches, encrypting data with generated encryption key and transmit data to a blockchain. Simon teaches, decrypting encrypted data using a key to generate a plain text. Therefore, it would have been obvious to decrypt encrypted data using a key to generate a plain text of Simon with encrypting data with generated encryption key and transmit data to a blockchain of Kim to take actions automatically upon satisfaction of one or more conditions precedent specified by a policy of the smart contract.
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 non-transitory computer readable medium Claim 17 and therefore Claim 9 is rejected with the same rationale as applied against Claim 17 above.
Regarding Claim 10 rejection of Claim 9 is included and for the same motivation Kim does not teach explicitly,
The method of claim 9, wherein at least one or more nodes within the decentralized network receives the received encrypted generated cryptographic key.
However, Simon teaches,
The method of claim 9, wherein at least one or more nodes within the decentralized network receives the received encrypted generated cryptographic key. (¶33, ¶39-¶40, i.e. contract executor receives encrypted cryptographic key).
Regarding Claim 11 rejection of Claim 10 is included and for the same motivation Kim does not teach explicitly,
The method of claim 10, wherein the at least one or more nodes within the decentralized network decrypts the received encrypted generated cryptographic key.
However, Simon teaches,
The method of claim 10, wherein the at least one or more nodes within the decentralized network decrypts the received encrypted generated cryptographic key. (¶39, “The contract executor 16 then decrypts the symmetric key 32-N of the wrapper 38-N using the private key E 44.”, ¶40).
Regarding Claim 12 rejection of Claim 11 is included and for the same motivation Kim does not teach explicitly,
The method of claim 11, wherein the at least one or more nodes within the decentralized network decrypts the received encrypted generated cryptographic key with a share of a network key.
However, Simon teaches,
The method of claim 11, wherein the at least one or more nodes within the decentralized network decrypts the received encrypted generated cryptographic key with a share of a network key. (¶39-¶40).
Regarding Claim 13 rejection of Claim 12 is included and for the same motivation Kim does not teach explicitly,
The method of claim 12, wherein the at least one or more nodes within the decentralized network publishes the result of the decryption of the received encrypted generated cryptographic key to a shared ledger.
However, Simon teaches,
The method of claim 12, wherein the at least one or more nodes within the decentralized network publishes the result of the decryption of the received encrypted generated cryptographic key to a shared ledger. (¶40, “The contract executor 16 then executes the smart contract 26 using the sensitive data 24”, ¶42).
Regarding Claim 14 rejection of Claim 13 is included and for the same motivation Kim does not teach explicitly,
The method of claim 13, further comprising initiating one or more operations based on one or more results of the decryption of the received encrypted generated cryptographic key.
However, Simon teaches,
The method of claim 13, further comprising initiating one or more operations based on one or more results of the decryption of the received encrypted generated cryptographic key. . (¶40, “the contract executor action 59 may be to sell the stock”, ¶57).
Regarding Claim 15 rejection of Claim 14 is included and for the same motivation Kim does not teach explicitly,
The method of claim 14, wherein the one or more operations comprises decrypting the encrypted message at the second device using the decrypted encrypted generated cryptographic key.
However, Simon teaches,
The method of claim 14, wherein the one or more operations comprises decrypting the encrypted message at the second device using the decrypted encrypted generated cryptographic key. (¶39, “The contract executor 16 then decrypts the symmetric key 32-N of the wrapper 38-N using the private key E 44.”, ¶40, “Once a subset of at least size R of the symmetric keys 32-1-32-N have been decrypted by the contract executor 16, the contract executor 16 uses the decrypted symmetric keys 32-1-32-N to decrypt the sensitive data 24 of the encrypted package 34 of the smart contract 26”).
Claim 16 - Canceled
Regarding Claim 18 rejection of Claim 17 is included and for the same motivation Kim does not teach explicitly,
The non-transitory computer readable medium of claim 17, wherein at least one or more nodes within the decentralized network receives the received encrypted generated cryptographic key.
However, Simon teaches,
The non-transitory computer readable medium of claim 17, wherein at least one or more nodes within the decentralized network receives the received encrypted generated cryptographic key. (¶33, ¶39-¶40, i.e. contract executor receives encrypted cryptographic key).
Regarding Claim 19 rejection of Claim 18 is included and for the same motivation Kim does not teach explicitly,
The non-transitory computer readable medium of claim 18, wherein the at least one or more nodes within the decentralized network decrypts the received encrypted generated cryptographic key.
However, Simon teaches,
The non-transitory computer readable medium of claim 18, wherein the at least one or more nodes within the decentralized network decrypts the received encrypted generated cryptographic key. (¶39, “The contract executor 16 then decrypts the symmetric key 32-N of the wrapper 38-N using the private key E 44.”, ¶40).
Regarding Claim 20 rejection of Claim 17 is included and for the same motivation Kim does not teach explicitly,
The non-transitory computer readable medium of claim 17, further comprising initiating one or more operations based on one or more results of the decryption of the received encrypted generated cryptographic key.
However, Simon teaches,
The non-transitory computer readable medium of claim 17, further comprising initiating one or more operations based on one or more results of the decryption of the received encrypted generated cryptographic key. . (¶40, “the contract executor action 59 may be to sell the stock”, ¶57).
Regarding Claim 21 rejection of Claim 20 is included and for the same motivation Kim does not teach explicitly,
The non-transitory computer readable medium of claim 20, wherein the one or more operations comprises decrypting the encrypted message at the second device using the decrypted encrypted generated cryptographic key.
However, Simon teaches,
The non-transitory computer readable medium of claim 20, wherein the one or more operations comprises decrypting the encrypted message at the second device using the decrypted encrypted generated cryptographic key. (¶39, “The contract executor 16 then decrypts the symmetric key 32-N of the wrapper 38-N using the private key E 44.”, ¶40, “Once a subset of at least size R of the symmetric keys 32-1-32-N have been decrypted by the contract executor 16, the contract executor 16 uses the decrypted symmetric keys 32-1-32-N to decrypt the sensitive data 24 of the encrypted package 34 of the smart contract 26”).
Regarding Claim 22 rejection of Claim 20 is included and for the same motivation Kim does not teach explicitly,
The non-transitory computer readable medium of claim 20, wherein the one or more operations comprises verifying receipt of the encrypted message at the second device.
However, Simon teaches,
The non-transitory computer readable medium of claim 20, wherein the one or more operations comprises verifying receipt of the encrypted message at the second device. (¶39-¶40).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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.
Cooper (US PGPUB. # US 2022/0103351) discloses, generating, distributing, validation, and processing secure commands on different devices and/or peripherals. A control device generates and encrypts a key corresponding to a secure command using a private key of control device to produce a key envelope. Control device further encrypts the key envelope with a recipient's public key producing a recipient envelope. The recipient envelope is delivered to a recipient's device. The recipient's device decrypts the recipient envelope with a private key of the recipient's device producing the key envelope. The key envelope is delivered back to the control device. The control device decrypts the key envelope producing the key, validates the key, and processes a secure command on behalf of a secure resource or delivers the secure command to the secure resource for processing. In an embodiment, control device maintains audit records/audit trail, which is maintained on the control device.
Gaddam et al. (US PGPUB. # US 2022/0012358) discloses, a system and techniques for enabling user control over usage of their information by data consumers, even when untrusted parties are involved, while also preventing collusion between the untrusted party and a data consumer. A user's information may be collected by a client device and provided to a host server. An encrypted version of the user'information may be stored at the host server so that it is processed on a private enclave of the host server. When the data is to be provided to multiple data consumers, the data may be encrypted for each of the data consumers and may be released to each of those data consumers simultaneously once confirmation has been received that the data has been made available to each of the data consumers.
Shami et al. (US PGPUB. # US 2020/0356989) discloses, a method of increasing security of digital assets stored in an isolated device by associating the isolated device with a plurality of accounts of the user each configured to store a limited value of digital assets, each of the plurality of accounts is assigned an asymmetric cryptographic key pair (comprising a unique private key encrypting the respective account and a corresponding public key identifying the respective account), transmitting, via a unidirectional secure channel, the public key assigned to each of the plurality of accounts to one or more computing nodes connected to a network community regulating the digital assets and transferring a value of the digital assets by transmitting, to one or more of the computing nodes, the private key of one or more of the plurality of accounts cumulatively storing the transferred value thus releasing the limited value stored in the respective account(s).
KRCMARICIC-BARACKOV et al. (US PGPUB. # US 2020/0266989) discloses, an Ad-hoc network comprising a configurator device and a plurality of nodes, wherein each node is an electronic device, wherein each node is connected by a communication connection with at least one of the other nodes and/or with the configurator device, wherein each node can be in different states comprising at least a non-commissioned state (NC), a commissioned state and a trust ring member state (TR) wherein a first node of the plurality of nodes being in the non-commissioned state (NC) is configured to send an non-commissioned advertisement message to the configurator device comprising an identifier of the first node, wherein the configurator device is configured to send an automated commissioning initialization (ACI) message to the first node containing a token, wherein the token is encrypted by a symmetric network key, wherein the first node is configured to send out a commissioning request message containing the received encrypted token, wherein the first node is configured to change its state, when it receives an authorisation message from another node or from the configurator device.
Qian (US PGPUB. # US 2017/0142082) discloses, a method for providing secure deposit and recovery of secret data based on a secret of a user, such as a password, a shared secret from a recovery server, and a secret from a recovery peer. The secret data is encrypted with these three secrets and stored remote from the user device to only allow the user to recover the secret data without compromising the secrecy of the secret data. Systems and methods for decoupling a password from the secret data the password protects is also provided to allow resetting the password or recovering the secret data to be separate operations that can be carried out independently. Another aspect provides for a user account to be securely recovered using a recovery peer to verify ownership of the user account.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DARSHAN I DHRUV whose telephone number is (571)272-4316. The examiner can normally be reached M-F 9:00 AM-5:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Yin-Chen Shaw can be reached on 571-272-8878. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/DARSHAN I DHRUV/ Primary Examiner, Art Unit 2498