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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 07/17/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis 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.
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 of this title, 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-20 are rejected under 35 U.S.C 103 as being unpatentable over William et al. (US 2020/0084222), hereon referred to as William, in view of Nolan et al. (US 2019/0034936 ), and hereon referred to as Nolan.
In regards to claims 1, 11 & 18, William discloses compare a first signature generated when the serialized operations were signed with a second signature of the serialized operations stored by the cloud infrastructure service (The receiving network firewall validates the expiring HMAC by calculating valid HMAC values based on the secret seed shared with the sending network firewall; in combination with a current clock time or event counter; Paragraphs 0020-0030; 0040-0045); determine whether the serialized operations have been tampered with based at least in part on the comparison (if an attacker stole a valid payload extension and coupled it with a malicious data packet, a recipient would be able to check that the payload extension does not “match” the malicious data packet and may discard it as having evidence of tampering. A hash in the payload extension is thus a protection against replay attacks; Paragraphs 0020-0030; 0040-0045); and perform a procedure with the serialized operations based at least in part on the determination whether the serialized operations have been tampered with (If the secure data packet does satisfy the validity condition rules applied by the receiving network firewall with respect to the expiring HMAC and/or other security information, then the receiving network firewall may strip the HMAC and/or other security information from the secure data packet before forwarding the secure data packet together with other network traffic to the receiving network (e.g., to a particular application executing on a device of the receiving network); Paragraphs 0020-0030; 0040-0045; 0050-0055).
However, William does not disclose determine that an action is authorized to be performed for a client device; identify serialized operations corresponding to the action stored by the cloud infrastructure service. In an analogous art Nolan discloses determine that an action is authorized to be performed for a client device (The invention may use multi key authorization policies to protect wallet shares, for example, by employing an M of N agreement protocol that obtains spending approval from M of N wallet shares, for example, located on different devices, as a precondition to transaction submission. In some examples, each e-wallet share signs the proposed transaction and nonce that is subsequently countersigned with an e-wallet key, for example, an EPID key; Paragraphs 0208-0215); identify serialized operations corresponding to the action stored by the cloud infrastructure service (a blockchain may be included in the IoT device to record transactions and fractional transactions. In addition to other information, the blockchain may record revocation of wallet shares, shared public keys, and signed transactions; Paragraphs 0202-0215).
At the time before the effective filing date of the invention, it would have been obvious to the one with ordinary skill in the art to combine the teachings disclosed by William, with the teachings disclosed by Nolan regarding determine that an action is authorized to be performed for a client device; identify serialized operations corresponding to the action stored by the cloud infrastructure service. The suggestion/motivation of the combination would have been to provide additional security techniques in internet of things devices (Nolan; Paragraph 0001).
In regards to claims 2, 12 & 19 Nolan discloses wherein the first signature is generated using an elliptic curve digital signature algorithm (ECDSA) (if an EPID key using ECC of size 256 is used to achieve 128-bits of equivalent AES security, the EPID wallet key may be 512-bits in length; Paragraphs 0222-0230).
In regards to claims 3, 13 & 20, William discloses wherein the first signature is generated using the elliptic curve digital signature algorithm with a key, and wherein the key is maintained within an enclave of the cloud infrastructure service (The client endpoints are IoT devices and include a secure enclave for storing the shared secret used to generate and validate HMACs for use in connection with the system; Paragraphs 0050-0055).
In regards to claims 4 & 14, William discloses wherein the first signature is compared with the second signature when the serialized operations are retrieved from storage after the action is determined to be authorized (The expiring HMAC itself is calculated by the sending network firewall based on a secret seed value shared with the receiving network firewall and a current clock time; Paragraphs 0025-0030).
In regards to claims 5 & 15, the combination of William and Nolan discloses wherein the serialized operations maintain states of operations within the serialized operations (The elements presented in the claim(s) do not contain any additional features, do not present any inventive step or novelty not addressed/presented in the combination of William and Nolan. Examiner takes official notice, that these elements are commonly known, minor design details that are derivable from the prior art and are well known, and obvious to an ordinary skill in the art. The additional features of these claims represent normal design options, which the skilled person would implement the combination of William and Nolan, depending on the circumstances, without exercising any inventive activity).
In regards to claims 6 & 16, William discloses wherein the serialized operations are determined to have not been tampered with, and wherein to perform the procedure includes to: execute the serialized operations based at least in part on the determination that the serialized operations have not been tampered with (If the secure data packet does not satisfy the validity condition rules applied by the receiving network firewall with respect to the expiring HMAC and/or other security information included in the secure packet (e.g., nonce, UUID, etc.), then the receiving network firewall will direct the secure packet to a discard location (e.g., to/dev/null). If the secure data packet does satisfy the validity condition rules applied by the receiving network firewall with respect to the expiring HMAC and/or other security information, then the receiving network firewall may strip the HMAC and/or other security information from the secure data packet before forwarding the secure data packet together with other network traffic to the receiving network; Paragraphs 0025-0030).
In regards to claims 7 & 17, Nolan discloses wherein the determination whether the serialized operations have been tampered with is performed via a security element at an edge of an enclave of the cloud infrastructure service (The devices hosting the e-wallet shares may be edge devices, such as smart phones, or may be any number of other devices that may be connected to the anonymizing network , such as ATMs, car networks, fog servers, fog devices, or MEC servers; Paragraphs 0211-0220).
In regards to claim 8, Nolan discloses wherein the instructions, when executed by the cloud infrastructure service, cause the cloud infrastructure service to: initiate an inquiry procedure for obtaining authorization of the action from each of one or more authorizers (The wallet signing authorization may begin when a e-wallet share S6 in a first device issues a transaction with an approval request (Tx1_MofN). The approval request may be a combination of the transaction and the M of N approval policy; Paragraphs 0210-0220).
In regards to claim 9, Nolan discloses wherein the instructions, when executed by the cloud infrastructure service, cause the cloud infrastructure service to: receive a request for the action to be performed for the client device; determine that authorization for the action has not been granted when the request is received; and generate the serialized operations corresponding to the action based at least in part on the determination that authorization for the action has not been granted when the request is received (if M out of N devices send a set Master transaction within a period T (e.g., 10 minutes) tracked by a timer, then one of them is elected master, and its key may be used to withdraw all funds. If the timer expires before the transaction occurs, a vote sink may occur, banning the transaction; Paragraphs 0240-0240).
In regards to claim 10, Nolan discloses serialize one or more operations corresponding to the action, the serialization of the one or more operations configuring one or more states of the one or more operations to be maintained for performance of the one or more operations; and sign the serialized one or more operations with a signature via an elliptic curve digital signature algorithm to produce the serialized operations (if an EPID key using ECC of size 256 is used to achieve 128-bits of equivalent AES security, the EPID wallet key may be 512-bits in length; The e-wallet shares, may respond by signing the approval request, and exchanging messages with the multi-signed approval request; 0213-0225).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHARIF E ULLAH whose telephone number is (571)272-5453. The examiner can normally be reached Mon-Fri 7:00-5:30.
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, Farid Homayounmehr can be reached at 571-272-3739. 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.
/SHARIF E ULLAH/Primary Examiner, Art Unit 2495
Prosecution Insights