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 application has been examined. Claims 1-30 are pending.
The Group and/or Art Unit location of your application in the PTO has changed. To aid in correlating any papers for this application, all further correspondence regarding this application should be directed to Group Art Unit 2175.
Claim Rejections - 35 USC § 112
The following is a quotation of the second paragraph of 35 U.S.C. 112:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1 and 17 are rejected under 35 U.S.C. § 112(b) as indefinite. The limitation "the cryptographic result is configured for use for performing a cryptographic action" renders the claim scope unclear. The independent claims use the phrase “a cryptographic action” without limiting what action is performed. The specification lists numerous possible cryptographic actions: comparing a digest to an expected digest, comparing a MAC to an expected MAC, storing MACs in storage, providing integrity check pass indications, updating error registers, storing decrypted data in memory (spec., ¶¶ [0060]-[0090]). The independent claims leave “cryptographic action” entirely open-ended, and a POSITA cannot determine the metes and bounds of the claim with reasonable certainty (Nautilus, Inc. v. Biosig Instruments, Inc., 572 U.S. 898 (2014)).
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-29 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Claims 1-16 recite a method. Claims 17-29 recite an apparatus. Therefore, claims 1-16 are directed to a process, and claims 17-29 are directed to a machine.
With respect to claims 1, 17:
2A Prong 1: the claim recites a judicial exception.
• receiving a request to provide a cryptographic service type; (mathematical concept - mathematical relationships; or mental process - evaluation or judgement).
• initiating a cryptographic algorithm in a cryptographic hardware component, wherein the cryptographic algorithm is associated with the cryptographic service type; (mathematical concept - mathematical algorithms; or mental process - evaluation or judgement).
• applying a cryptographic operation to data to obtain a cryptographic result, wherein the cryptographic operation is associated with the cryptographic algorithm; (mathematical concept - mathematical algorithms and relationships, e.g., hash functions, AES-GCM authenticated encryption).
• storing at least a portion of the cryptographic result in a hardware register of the cryptographic hardware component, wherein the cryptographic result is configured for use for performing a cryptographic action (mathematical concept - storing a mathematical result; or mental process - evaluation or judgement).
2A Prong 2: This judicial exception is not integrated into a practical application.
• (claim 17) at least one memory; at least one processor; and a cryptographic hardware component coupled to the at least one memory and the at least one processor (mere instructions to apply an exception - see MPEP 2106.05(g))
2B: The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception.
• (claim 17) at least one memory; at least one processor; and a cryptographic hardware component coupled to the at least one memory and the at least one processor (mere instructions to apply an exception - see MPEP 2106.05(g)); the cryptographic hardware component performs the same functions (hash, AES-GCM, MAC generation, result storage) that dedicated crypto hardware has historically performed - see MPEP 2106.05(a) (no improvement to computer itself).
With respect to claims 2, and 18:
2A Prong 1: the claim recites a judicial exception.
• wherein the cryptographic service type comprises an integrity service; wherein the cryptographic algorithm is a hashing algorithm; and wherein the cryptographic result comprises a digest corresponding to the data (mathematical concept - mathematical algorithms, e.g., SHA-based hashing; or mental process - evaluation).
With respect to claims 3 and 24:
2A Prong 1: the claim recites a judicial exception.
• further comprising performing the cryptographic action using the cryptographic result (mathematical concept - applying a mathematical result; or mental process - evaluation or judgement).
With respect to claims 4 and 18 :
2A Prong 1: the claim recites a judicial exception.
• obtaining the cryptographic result from the hardware register of the cryptographic hardware component; and (mathematical concept - retrieving a mathematical result; or mental process - evaluation).
• performing a comparison between the cryptographic result and an expected cryptographic result to determine whether the cryptographic result and the expected cryptographic result match (mathematical concept - mathematical comparison; or mental process - evaluation or judgement).
With respect to claims 5 and 19:
2A Prong 1: the claim recites a judicial exception.
• determining a match between the cryptographic result and the expected cryptographic result; and determining, based on the match, at least a partial integrity check pass for the data (mental process - evaluation or judgement).
With respect to claims 6 and 20:
2A Prong 1: the claim recites a judicial exception.
• determining that the cryptographic result and the expected cryptographic result do not match; and determining, based on the non-match, an integrity check failure for the data (mental process - evaluation or judgement).
With respect to claims 7 and 20 (error register):
2A Prong 1: the claim recites a judicial exception.
• updating an error register of the cryptographic hardware component with an indication of the integrity check failure (mathematical concept - updating a mathematical data structure; or mental process - evaluation or judgement).
With respect to claims 8 and 21:
2A Prong 1: the claim recites a judicial exception.
• wherein the cryptographic operation is performed during a secure boot process; and wherein the data is at least a portion of an operating system image file (mental process - evaluation or judgement; or insignificant extra-solution activity - see MPEP 2106.05(g), mere data gathering/processing in a particular context).
With respect to claims 9 and 22:
2A Prong 1: the claim recites a judicial exception.
• wherein the cryptographic operation is performed during a data block integrity check; and wherein the data is at least a portion of a read-only file system (mental process - evaluation or judgement; or insignificant extra-solution activity - see MPEP 2106.05(g), mere data gathering/processing in a particular context).
2A Prong 2: This judicial exception is not integrated into a practical application.
• wherein the cryptographic operation is performed during a data block integrity check; and wherein the data is at least a portion of a read-only file system (insignificant extra-solution activity - see MPEP 2106.05(g), mere data gathering/processing; and WURC: storing and retrieving information in memory - see MPEP 2106.05(d)(II)(iii))
2B: The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception.
• wherein the cryptographic operation is performed during a data block integrity check; and wherein the data is at least a portion of a read-only file system (insignificant extra-solution activity - see MPEP 2106.05(g), mere data gathering/processing; and WURC: storing and retrieving information in memory - see MPEP 2106.05(d)(II)(iii)).
With respect to claims 10 and 23:
2A Prong 1: the claim recites a judicial exception.
• wherein the cryptographic service type comprises an authenticated encryption service; wherein the cryptographic algorithm is an authenticated encryption algorithm; and wherein the cryptographic result comprises a message authentication code (MAC) and encrypted data (mathematical concept - mathematical algorithms and relationships, e.g., AES-GCM authenticated encryption producing a MAC and ciphertext).
With respect to claims 11 and 24:
2A Prong 1: the claim recites a judicial exception.
• wherein applying the cryptographic operation to the data to obtain the cryptographic result further comprises encrypting the data using the authenticated encryption algorithm to obtain encrypted data (mathematical concept - mathematical algorithm, e.g., AES-GCM encryption)
With respect to claims 12 and 25:
2A Prong 1: the claim recites a judicial exception.
• obtaining the MAC from the hardware register of the cryptographic hardware component; and storing the MAC in persistent memory (mathematical concept - retrieving and storing a mathematical result; or mental process — evaluation or judgement; and WURC: storing and retrieving information in memory - see MPEP 2106.05(d)(II)(iii))
With respect to claims 13 and 26:
2A Prong 1: the claim recites a judicial exception.
• wherein the encrypted data comprises encrypted system state information obtained from memory, and the method further comprises: storing the encrypted data on a non-volatile storage device (insignificant extra-solution activity - see MPEP 2106.05(g), mere data gathering; and WURC: storing and retrieving information in memory - see MPEP 2106.05(d)(II)(iii))
With respect to claims 14 and 27:
2A Prong 1: the claim recites a judicial exception.
• wherein the data is encrypted system state information obtained from a non-volatile storage device, and wherein performing the cryptographic action comprises: obtaining the MAC from the hardware register of the cryptographic hardware component; and performing a comparison between the MAC and an expected MAC to determine whether the MAC and the expected MAC match (mathematical concept - mathematical comparison; or mental process - evaluation or judgement)
With respect to claims 15 and 28:
2A Prong 1: the claim recites a judicial exception.
• determining that the MAC and the expected MAC match; determining, based on the MAC and the expected MAC matching, an authentication check pass for the data; and decrypting, based on the authentication check pass, the data using the cryptographic algorithm (mental process - evaluation or judgement; mathematical concept - mathematical algorithm, e.g., AES-GCM decryption)
With respect to claims 16 and 29:
2A Prong 1: the claim recites a judicial exception.
• determining that the MAC and the expected MAC do not match; determining, based on the MAC and the expected MAC not matching, an authentication check failure for the data; and updating, based on the authentication check failure, an error register of the cryptographic hardware component with an indication of the authentication check failure (mental process - evaluation or judgement; mathematical concept - updating a mathematical data structure)
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless -
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-29 are rejected under 35 U.S.C. § 102(a)(1) as being anticipated by Grohoski et al. (“Grohoski”) (US Pub No. 2004/0225885).
In regard to claim 1, Groshoski discloses a method of offloading cryptographic services, the method comprising: receiving a request to provide a cryptographic service type (as shown in Fig. 3, which is reproduced below for ease of reference and convenience, Grohoski discloses the host CPU 205 receives a crypto operation request and writes a control word 212 (control word queue 210), or writes control register 1 (FIG. 8C), specifying the requested service via the Operation field (Table 1C), the Authentication Type field (Table 2: SHA-1/SHA-256/MD5/HMAC), and/or the Encryption Type field (Table 3: AES/DES/3DES); the co-processor 250 receives the request (FIG. 3, ops. 302-316; ¶ 58-61)).
PNG
media_image1.png
941
526
media_image1.png
Greyscale
initiating a cryptographic algorithm in a cryptographic hardware component, wherein the cryptographic algorithm is associated with the cryptographic service type (in Grohoski, cryptographic co-processor 250 (cryptographic hardware component) initiates the algorithm specified by the Authentication/Encryption Type field using the corresponding dedicated crypto unit 1005-1030 (DES unit 1005, AES unit 1010, hashing units 1015/1020 for SHA-1/SHA-256/MD5, HMAC (for integrity/authentication service types) and DES/3-DES/AES/RC4 (for encryption service types).) (FIG. 10; op. 312-314, Table 2)).
applying a cryptographic operation to data to obtain a cryptographic result, wherein the cryptographic operation is associated with the cryptographic algorithm (in Grohoski, the co-processor 250 executes the cipher/hash/MAC on the source data to produce a result - a hash/digest, an HMAC, or ciphertext (opcodes 64-67; “the hash will be written to the Hash Result registers”; “the ciphertext will be written to the Cipher Result registers”. SHA/HMAC hash to data [Wingdings font/0xE0] hash result (digest). Opcode 66: apply AES encryption then HMAC authentication to data [Wingdings font/0xE0] encrypted data + MAC. Opcode 73: apply hash [Wingdings font/0xE0] compare against expected hash (cryptographic result used for a cryptographic action). See ¶ 58-61; FIG. 3 op. 318; Table 1C opcodes 65-75).
and storing at least a portion of the cryptographic result in a hardware register of the cryptographic hardware component (in Grohoski, FIG. 8A-8C; table 1C; opcodes 73-75; ¶ 105-106. The crypto co-processor writes the AuthenticationFail bit to the Hardware Status Field residing in the hardware register set of the co-processor (FIG. 8A). This bit stores at least a portion of the cryptographic result that is specifically, the outcome of the hash comparison derived from the computed hash (cryptographic result).
wherein the cryptographic result is configured for use for performing a cryptographic action (in Grohoski, the AuthenticationFail bit is configured for use in performing a cryptographic action: the CPU polls the status field and takes action (pass or fail) based on the bit. (Opcode 73: “sets the AuthenticationFail bit of the Hardware Status field appropriately”; Table 1C, ¶ 105-106).
In regard to claim 2, Groshoski discloses wherein the cryptographic service type comprises an integrity service, the cryptographic algorithm is a hashing algorithm, and the cryptographic result comprises a digest corresponding to the data (in Grohoski, Table 2 (Authentication Type: SHA-1, SHA-256, MD-5, HMAC); opcode 65 (hash-only service type). The crypto co-processor executes a hashing algorithm (SHA-1, SHA-256, MD-5) as the integrity service type and produces a hash digest as the cryptographic result. (Table 1C, opcode 65: “Only perform the authentication MAC… the hash result is written to memory”; the AuthenticationFail bit in hardware stores whether the digest matched the expected value)).
In regard to claim 3, Groshoski discloses further performing the cryptographic action using the cryptographic result (in Grohoski, table 1C, opcodes 73-75: Grohoski expressly teaches performing a cryptographic action using the cryptographic result: opcode 73 states the co-processor “computes the hash, compares it to the expected hash, then sets the AuthenticationFail bit of the Hardware Status field appropriately.” The comparison is the cryptographic action; the computed hash is the cryptographic result. Storing and comparing MACs (opcodes 74-75) likewise performs a cryptographic action using the MAC result).
In regard to claim 4, Groshoski discloses wherein performing the cryptographic action comprises: obtaining the cryptographic result from the hardware register of the cryptographic hardware component; and performing a comparison between the cryptographic result and an expected cryptographic result to determine whether the cryptographic result and the expected cryptographic result match (in Grohoski, Table 1C, opcode 73-75; col. 11:30-60; FIG. 7 (Final Control Word, Destination Address field); FIG. 8A (hardware registers). Under opcode 73, the expected hash is stored at the address specified by the Destination Address field (hardware-accessible register-controlled location). The co-processor computes the hash, obtains the expected hash from the specified location, performs the comparison, and records the result in the AuthenticationFail bit of the Hardware Status Field (a hardware register). This maps directly to: (i) obtaining the cryptographic result from the hardware register, and (ii) performing a comparison between the result and an expected result).
In regard to claim 5, Groshoski discloses further: determining a match between the cryptographic result and the expected cryptographic result; and determining, based on the match between the cryptographic result and the expected cryptographic result, at least a partial integrity check pass for the data (in Grohoski, Table 1C, opcode 73. When the computed hash matches the expected hash, the AuthenticationFail bit is cleared (not set), signaling an integrity check pass. The CPU reads the hardware status register, determines a match, and determines an integrity check pass. (FIG. 3 ops. 324-326, ¶ 58-61)).
In regard to claim 6, Groshoski discloses further: determining that the cryptographic result and the expected cryptographic result do not match; and determining, based on the cryptographic result and the expected cryptographic result not matching, an integrity check failure for the data (in Grohoski, Table 1C, opcode 73. When the computed hash does NOT match the expected hash, the co-processor sets the AuthenticationFail bit to 1, indicating an integrity check failure. The CPU reads the hardware status register and determines an integrity check failure).
In regard to claim 7, Groshoski discloses further: updating an error register of the cryptographic hardware component with an indication of the integrity check failure (in Grohoski, FIG. 8A-8C; Table 1C, opcode 73. The AuthenticationFail bit written to the Hardware Status Field (a hardware register of the crypto co-processor, FIG. 8A) serves as an error register updated with an indication of the integrity check failure. A POSITA would recognize the Hardware Status Field’s AuthenticationFail bit as an error register indication within the cryptographic hardware component).
In regard to claim 8, Groshoski discloses wherein the cryptographic operation is performed during a secure boot process, and wherein the data is at least a portion of an operating system image file (in Grohoski, Table 1C: Grohoski teaches applying its hash integrity service (opcode 65/73) to software/firmware image data for integrity verification, which includes OS image verification during secure boot. Grohoski’s co-processor is described as performing integrity verification on software images loaded from storage).
In regard to claim 9, Groshoski discloses wherein the cryptographic operation is performed during a data block integrity check, and wherein the data is at least a portion of a read-only file system (in Grohoski, Table 1C, opcode 65/73. Grohoski’s hash-only service type (opcode 65/73) is applied to arbitrary data blocks from any source, including file system blocks. The co-processor performs a data block integrity check by hashing the data block and comparing against an expected hash).
In regard to claim 10, Groshoski discloses wherein the cryptographic service type comprises an authenticated encryption service, wherein the cryptographic algorithm is an authenticated encryption algorithm, and applying the cryptographic operation to obtain the cryptographic result comprises generating a message authentication code (MAC) (in Grohoski, Table 1C, opcodes 66-67, 70-71, 74-75; Table 2. Grohoski expressly teaches combined authenticated encryption operations: opcode 66 (“perform the cipher… then perform the authentication”) and opcode 67 (“perform the hash… then perform the cipher”), which together produce encrypted data and a MAC (authentication tag) as the cryptographic result. (¶ 74: “This operation can be used to produce the encrypt, then hash for an outbound IPsec ESP with AH packet” producing ciphertext + MAC.) The Dir bit controls whether the MAC is generated (outbound) or checked (inbound). (Grohoski, Table 1C, opcode 66).
In regard to claim 11, Groshoski discloses wherein applying the cryptographic operation to the data to obtain the cryptographic result further comprises encrypting the data using the authenticated encryption algorithm to obtain encrypted data (in Grohoski, opcode 66 (encrypt-then-authenticate); Table 1C. Opcode 66: “perform the cipher specified in the Encryption Type field, then perform the authentication specified by the Authentication Type field.” The cipher operation encrypts the data to obtain encrypted data (ciphertext); the authentication operation generates a MAC. Together, the cryptographic result comprises both encrypted data and a MAC).
In regard to claim 12, Groshoski discloses further performing the cryptographic action using the cryptographic result, wherein performing the cryptographic action comprises: obtaining the MAC from the hardware register of the cryptographic hardware component; and storing the MAC in persistent memory (in Grohoski, FIG. 7 (Final Control Word: Destination Address field); FIG. 8A-8C; opcode 66; Table 1C. After generating the MAC via opcode 66, the co-processor writes the MAC (hash result) to the address specified by the Destination Address field in the control word. The Destination Address is stored in the hardware register interface of the co-processor (FIG. 8A). The MAC is thereby obtained from the hardware register (Destination Address register) and stored in memory (persistent memory at the Destination Address). (Opcode 65: “the hash result is written to memory at the address specified in the Destination Address field” i.e. same mechanism applies to opcode 66)).
In regard to claim 13, Groshoski discloses wherein the encrypted data comprises encrypted system state information obtained from memory, and the method further comprises: storing the encrypted data on a non-volatile storage device (in Grohoski, ¶ 58-61; FIG. 3 ops. 308-318; FIG. 2 (network interface / memory). Grohoski’s crypto co-processor operates on data obtained from memory (the CPU/host memory) and writes the encrypted result (ciphertext) to a destination address, which can be a non-volatile storage location or a network output buffer. The data may be system state information (e.g., memory content, session state) passed to the co-processor for encryption and subsequent storage).
In regard to claim 14, Groshoski discloses wherein the data is encrypted system state information obtained from a non-volatile storage device, and wherein performing the cryptographic action comprises: obtaining the MAC from the hardware register of the cryptographic hardware component; and performing a comparison between the MAC and an expected MAC to determine whether the MAC and the expected MAC match (Grohoski, Table 1C, opcode 74-75; FIG. 8A-8C. Opcode 74: “the crypto co-processor computes the hash, compares it to the expected hash [expected MAC], then sets the AuthenticationFail bit of the Hardware Status field appropriately”. The data (encrypted system state from NV storage) is processed inbound: the co-processor decrypts/authenticates data read from a non-volatile storage device, computes the MAC, and compares it to the expected MAC stored at the Destination Address. The MAC is obtained from the hardware register (Hardware Status Field / AuthenticationFail bit reflects comparison); the comparison is performed by the co-processor hardware).
In regard to claim 15, Groshoski discloses further: determining that the MAC and the expected MAC match; determining, based on the MAC and the expected MAC matching, an authentication check pass for the data; and decrypting, based on the authentication check pass, the data using the cryptographic algorithm (in Grohoski, Table 1C, opcode 74-75; Dir bit, col. 12:45-55. When the computed MAC matches the expected MAC, the AuthenticationFail bit is not set (cleared), indicating an authentication check pass. The Dir bit controls inbound processing (decryption + MAC check). When the MAC matches (authentication check pass), the co-processor decrypts the data using the encryption algorithm (AES/DES). Opcode 75 combines hash-then-decrypt, explicitly teaching: authenticate first, then decrypt based on authentication result).
In regard to claim 16, Groshoski discloses further: determining that the MAC and the expected MAC do not match; determining, based on the MAC and the expected MAC not matching, an authentication check failure for the data; and updating, based on the authentication check failure, an error register of the cryptographic hardware component with an indication of the authentication check failure (in Grohoski, Table 1C, opcode 74: When the MAC does not match the expected MAC, the co-processor sets the AuthenticationFail bit of the Hardware Status Field to 1 which is indicating an authentication check failure. The Hardware Status Field (hardware register of the crypto co-processor, FIG. 8A) is updated with the indication of the authentication check failure. This is the error register updated under Claim 16. (Opcode 74: “sets the AuthenticationFail bit of the Hardware Status field appropriately”).
Independent claim 17 (apparatus) recites the same operative limitations as method claim 1 in apparatus form. Grohoski, ¶ 52-55; FIG. 2: host CPU 205 (processor); memory accessible by both CPU and co-processor; and crypto co-processor 250 (cryptographic hardware component) coupled to the CPU via hardware register interface 215. (Col. 2:20–35.) The method/apparatus distinction does not impart patentability where the underlying operative steps are the same. See MPEP § 2114; In re Bernhart, 417 F.2d 1395 (CCPA 1969). The element-by-element mapping set forth for claim 1 applies with equal force to claim 17.
Claim 18 (apparatus) recites the same operative limitations as method claims 2 and 4 in apparatus form. The method/apparatus distinction does not impart patentability where the underlying operative steps are the same. See MPEP § 2114; In re Bernhart, 417 F.2d 1395 (CCPA 1969). The element-by-element mapping set forth for claims 2 and 4 apply with equal force to claim 18.
Claim 19 (apparatus) recites the same operative limitations as method claim 5 in apparatus form. The method/apparatus distinction does not impart patentability where the underlying operative steps are the same. See MPEP § 2114; In re Bernhart, 417 F.2d 1395 (CCPA 1969). The element-by-element mapping set forth for claim 5 applies with equal force to claim 19.
Claim 20 (apparatus) recites the same operative limitations as method claims 6-7 in apparatus form. The method/apparatus distinction does not impart patentability where the underlying operative steps are the same. See MPEP § 2114; In re Bernhart, 417 F.2d 1395 (CCPA 1969). The element-by-element mapping set forth for claims 6-7 applies with equal force to claim 20.
Claims 21-29 (apparatus) recite the same operative limitations as method claims 8-16 in apparatus form respectively. The method/apparatus distinction does not impart patentability where the underlying operative steps are the same. See MPEP § 2114; In re Bernhart, 417 F.2d 1395 (CCPA 1969). The element-by-element mapping set forth for claims 8-16 apply with equal force to claims 21-29.
Allowable Subject Matter
Claim 30 is allowable over the prior of records.
The following is an Examiner's statement of reasons for the indication of allowable subject matter: Claim 30 is allowable over the prior art of record because the combination of claim 30 is not disclosed or rendered obvious by Grohoski:
Claim 30 recites a method comprising: (i) receiving, at a local computing device, a request to provide a cryptographic service type comprising a decryption of encrypted data, wherein the encrypted data is encrypted by a remote computing device using plaintext data, a cryptographic key, and an initialization vector (IV); (ii) initiating an encryption algorithm in a cryptographic hardware component; (iii) obtaining the cryptographic key and the IV; (iv) storing the IV in a hardware storage device of the cryptographic hardware component; (v) obtaining the encrypted data from a storage device of the local computing device; (vi) executing the encryption algorithm using the encrypted data, the cryptographic key, and the IV to obtain decrypted data; and (vii) storing the decrypted data in a memory device of the local computing device.
The combination of: (i) a local computing device with a cryptographic hardware component having a dedicated hardware IV storage device; (ii) the IV being associated with and obtained from a remote computing device that performed the original encryption; (iii) the encrypted data being retrieved from a local storage device; and (iv) executing the decryption algorithm in the cryptographic hardware component using the stored IV, key, and encrypted data - all as a unified method - constitutes allowable subject matter not taught by the art of record.
Examiner's note:
Examiner has cited particular paragraphs, columns and line numbers in the references applied to the claims above for the convenience of the Applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the Applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passages as taught by the prior art or disclosed by the Examiner.
Conclusion
Claims 1-29 are rejected. Claim 30 is allowed.
The prior arts made of record and not relied upon are considered pertinent to applicant's disclosure.
Stern (US No. 9,740,866) discloses an automatic measuring boot process using a measuring processor coupled to memory which is hardware-measured/secure boot.
Narendra et al. (US No. 10,536,274) disclose a cryptographic protection for trusted operating systems that is integrity/authenticated protection of system images.
Rao et al. (US Pub No. 2024/0202340) disclose the Trusted access control for secure boot for storage controllers / drivers that would be inline storage-path integrity verification.
Asbe et al. (US Pub No. 2025/0053659) disclose the Multistage device boot with independent stage keys that would be keyed stage-by-stage boot verification.
Siddhartha et al. (EP No. 3,757,848) disclose the Relied upon (secondary) that would be secure boot image hash-verify (compare computed hash to expected hash 139) before release.
Stephen et al. (EP No. 4,655,695) disclose the Inline encryption and/or decryption using address tagging that would be inline storage crypto in the data path.
Wagh et al. (US 12,164,650) teach a system for total storage encryption in which an inline crypto block resides in the data path between a non-volatile memory (NVM/UFS) storage device and host system memory.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to examiner Raymond Phan, whose telephone number is (571) 272-3630. The examiner can normally be reached on Monday-Friday from 6:30AM- 3:00PM. The Group Fax No. (571) 273-8300.
Communications via Internet e-mail regarding this application, other than those under 35 U.S.C. 132 or which otherwise require a signature, may be used by the applicant and should be addressed to [raymond.phan@uspto.gov].
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, Andrew Jung can be reached at (571) 270-3779. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
All Internet e-mail communications will be made of record in the application file. PTO employees do not engage in Internet communications where there exists a possibility that sensitive information could be identified or exchanged unless the record includes a properly signed express waiver of the confidentiality requirements of 35 U.S.C. 122. This is more clearly set forth in the Interim Internet Usage Policy published in the Official Gazette of the Patent and Trademark on February 25, 1997 at 1195 OG 89.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see hop://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Any inquiry of a general nature or relating to the status of this application should be directed to the TC 2100 central telephone number is (571) 272-2100.
/RAYMOND N PHAN/
Primary Examiner, Art Unit 2175
Prosecution Insights