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 .
Claims 1-20 have been examined.
Priority
Acknowledgement is made of the applicant’s claim to priority to the provisional application 63/416826 filed on 10/17/2022.
Information Disclosure Statement
The information disclosure statements (IDSs) submitted on 04/08/2025, 06/24/2025, and 02/18/2026 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
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 14-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter. Claim 14 is directed to an inline memory encryption engine comprising encryption logic, authentication logic, and integrity-protection logic which comprises of an intermediate state storage and packet storage. It was well known to one of ordinary skill in the art that logic represents software and storage can be implemented using transitory media. Therefore, claim 14 is directed to an engine that does not comprise of any hardware elements which is non-statutory. Claims 15, 17 and 18 also do not include any hardware elements and are also non-statutory. Claim 16 recites a data-integrity detection logic which is also software and also does not comprise of any hardware elements which is non-statutory. Claims 20 recites an error accumulator and a controller which can also be implemented in software and therefore, does not include any hardware elements which is non-statutory.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
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 2, 11 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 2 recites the limitation "the packet" in line 4. There is insufficient antecedent basis for this limitation in the claim.
Claim 11 uses the word “can” which renders the claim unclear and indefinite.
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.
Claims 8 and 9 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by CN112532740A to Sun (hereinafter Sun).
As per claim 8, Sun teaches:
A method of operating a receiver node, the method comprising:
storing a first portion of a data burst, received from a sender node, in a local storage (Sun: [n0090]: upload the first fragment and the corresponding hash value to the server. Storing the received first fragment in a local storage of the server was well known to one of ordinary skill in the art before the effective filing date of the claimed invention);
processing the first portion using an authentication algorithm to generate a first intermediate state, the authentication algorithm to generate a final authentication tag for the data burst (Sun: [n0090]: The server performs a hash operation on the first received fragment to obtain a verification hash value. [n0105]: When there are more fragments after the current fragment, the terminal will use the next fragment as the current fragment to be traversed in the next moment, and then jump to step S206 and continue to execute, so as to upload the next fragment to the server in a chained hash value correlation method. This process is repeated sequentially until all segments of the target file are successfully uploaded to the server, i.e., server will generate the final hash value after it processes the last fragment);
storing the first intermediate state in the local storage, the first intermediate state being associated with the first portion (Sun: [n0090]: The server stores the first shard and stores the hash value corresponding to the first shard (first intermediate state) in the global storage space for verification of the next shard);
storing a second portion of the data burst, received from the sender node, in the local storage (Sun: [n0098]: Specifically, the terminal can send a fragmented upload request to the server. It is understandable that the fragment upload request carries the current fragment. Storing the received current fragment (second portion) in a local storage of the server was well known to one of ordinary skill in the art before the effective filing date of the claimed invention);
processing the second portion using the authentication algorithm and the first intermediate state to generate a second intermediate state (Sun: [n0098]: The server performs a hash operation based on the current shard and the hash value corresponding to the previous shard (first intermediate state) stored in the global storage space to obtain the check hash value corresponding to the current shard, and then verifies the current hash value using the check hash value);
detecting an error in the processing the second portion (Sun: [n0109]: In one embodiment, if the server fails to verify the current hash value, it indicates that the currently uploaded fragment is incorrect and may have been tampered with);
storing a re-transmitted second portion of the data burst, received from the sender node, in the local storage (Sun: [n0109]: At this point, the server will send a second feedback message to the terminal indicating that the verification failed. Upon receiving this second feedback information, the terminal can then re-upload the current fragment until it is successfully uploaded to the server);
re-processing the re-transmitted second portion using the authentication algorithm and the first intermediate state to generate the second intermediate state (Sun: [n0124]: In this way, the terminal continuously executes the above steps S302-S310 on the received fragment upload requests until the verification of each fragment in the target file is completed. [n0117]: S306. Perform a hash operation based on the current segment and the hash value corresponding to the previous segment stored in the global storage space to obtain the check hash value corresponding to the current segment, and verify the current hash value through the check hash value);
storing the second intermediate state in the local storage, the second intermediate state being associated with the re-transmitted second portion (Sun: [n0098]: When the verification passes, the server can store the current shard and store the current hash value corresponding to the current shard in the global storage space. The stored current hash value will be used as the hash value for the next shard verification, so as to realize the verification of the next shard); and
generating the final authentication tag for the data burst after processing all portions of the data burst (Sun: [n0098]: The stored current hash value will be used as the hash value for the next shard verification, so as to realize the verification of the next shard. [n0105]: When there are more fragments after the current fragment, the terminal will use the next fragment as the current fragment to be traversed in the next moment, and then jump to step S206 and continue to execute, so as to upload the next fragment to the server in a chained hash value correlation method. This process is repeated sequentially until all segments of the target file are successfully uploaded to the server, i.e., server will generate the final hash value after it processes the last fragment).
As per claim 9, Sun teaches:
The method of claim 8, wherein storing the second intermediate state comprises overwriting the first intermediate state when no errors are detected in the re-processing the re-transmitted second portion (Sun: [n0109]: Upon receiving this second feedback information, the terminal can then re-upload the current fragment until it is successfully uploaded to the server. [n0117]: S306. Perform a hash operation based on the current segment and the hash value corresponding to the previous segment stored in the global storage space to obtain the check hash value corresponding to the current segment, and verify the current hash value through the check hash value. Overwriting previous or older data with current data was well known to one of ordinary skill in the art before the effective filing date of the claimed invention).
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 10-13 are rejected under 35 U.S.C. 103 as being unpatentable over Sun and JPH07244623A to Sunaga (hereinafter Sunaga).
As per claim 10, Sun does not teach the limitations of claim 10. However, Sunaga teaches:
wherein the first portion and the re-transmitted second portion are stored in parallel in a first-in-first-out (FIFO) buffer (Sunaga: [0020]: a frame message 100 consisting of parallel data words is transmitted from the internal data bus A and stored in the extended FIFO buffer 2).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Sunaga in the invention of Sun to include the above limitations. The claim would have been obvious because a particular known technique was recognized as part of the ordinary capabilities of one skilled in the art (see KSR Int’l Co. v. Teleflex Inc. 550 U.S. ___, 82 USPQ2d 1385 (Supreme Court 2007) (KSR)).
As per claim 11, Sun in view of Sunaga teaches:
The method of claim 10, wherein a depth of the FIFO buffer represents a number of errors that can be handled while generating the final authentication tag for the data burst (Sunaga: [0013]: the number of storage cells in each stage of the FIFO buffer is the same as the total number of bits of data words, control signals, and status flags. [0020]: a frame message 100 consisting of parallel data words is transmitted from the internal data bus A and stored in the extended FIFO buffer 2, i.e., the of stages in the FIFO buffer represents the number of data words and hence the number of errors that will be handled).
The examiner provides the same rationale to combine prior arts Sun and Sunaga as in claim 8 above.
As per claim 12, Sun in view of Sunaga teaches:
The method of claim 10, wherein, after re-processing the re-transmitted second portion, the method further comprises: sending an acknowledgment signal to the sender node to indicate that a current authentication iteration has finished; overwriting the first intermediate state with the second intermediate state (Sun: [n0101]: Specifically, when the verification is successful, the terminal will receive the first feedback information from the server indicating that the verification has been successful, and then traverse the next shard of the current shard based on the first feedback information. [n0098]: The server performs a hash operation based on the current shard and the hash value corresponding to the previous shard stored in the global storage space to obtain the check hash value corresponding to the current shard, and then verifies the current hash value using the check hash value. When the verification passes, the server can store the current shard and store the current hash value corresponding to the current shard in the global storage space. The stored current hash value will be used as the hash value for the next shard verification, so as to realize the verification of the next shard, i.e., the temporary storage used by the server to store the calculated check hash value during the verification process will be overwritten by the next calculated check hash value of the next fragment); and removing the first portion from the FIFO buffer (Sunaga: when the bus interface 3 reads data from the extended FIFO buffer 2 and places it on the internal data bus A, the status flag processing unit 511 of the bus interface control unit 51 reads the status flag stored in the status flag storage cell of the storage segment that stores the data word to be read from the extended FIFO buffer 2. If the content of the flag is normal, it instructs the bus interface 3 to transmit the content of the data word stored in the storage segment to the internal data bus A as is).
The examiner provides the same rationale to combine prior arts Sun and Sunaga as in claim 8 above.
As per claim 13, Sun in view of Sunaga teaches:
The method of claim 12, wherein, in response to detecting the error and before the processing the re-transmitted second portion has finished, the method further comprises refraining from sending the acknowledgment signal to the sender node to indicate that a current authentication iteration has finished (Sun: [n0124]: When the verification fails, the server can send a second feedback message to the terminal. After receiving the second feedback message, the terminal can re-upload the current fragment. In this way, the terminal continuously executes the above steps S302-S310 on the received fragment upload requests until the verification of each fragment in the target file is completed. [n0117]: S306. Perform a hash operation based on the current segment and the hash value corresponding to the previous segment stored in the global storage space to obtain the check hash value corresponding to the current segment, and verify the current hash value through the check hash value. [n0124]: Specifically, when the verification is successful, the server can send the first feedback information to the terminal. After receiving the first feedback information, the terminal can continue to upload the next segment of the target file to be uploaded, i.e., the server refrains from sending first feedback information until the re-uploaded fragment has been successfully verified and finished).
Claims 1, 3-7, 14-17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Sun and US 12299143 to Elbaum et al (hereinafter Elbaum).
As per claim 1, Sun teaches:
A method comprising:
starting generation of a message authentication code (MAC) tag with error detection from a sequence of packets received from a source node (Sun: [n0080]: Terminal 102 obtains the target file to be uploaded and splits the target file into multiple fragments. Terminal 102 sends the fragmented upload request to server 104. [n0098]: The server performs a hash operation based on the current shard and the hash value corresponding to the previous shard stored in the global storage space to obtain the check hash value corresponding to the current shard, and then verifies the current hash value using the check hash value. [n0117]);
detecting an error associated with a first packet in the sequence of packets (Sun: [n0098]: If the check hash value is different from the current hash value, it indicates that the check failed. [n0119]);
in response to detecting the error, continuing the generation of the MAC tag without updating a first intermediate state corresponding to the first packet to produce a first result (Sun: [n0109]: In one embodiment, if the server fails to verify the current hash value, it indicates that the currently uploaded fragment is incorrect and may have been tampered with. At this point, the server will send a second feedback message to the terminal indicating that the verification failed. [n0116]: Specifically, the server can determine the previous fragment received and stored before the current fragment, and look up the hash value corresponding to the previous fragment in the global storage space, i.e., the server does not update the global storage space with the hash value of the current fragment (first intermediate state) when the verification check fails);
storing a second intermediate state of the MAC tag corresponding to a second packet before the error (Sun: [n0117]: the hash value corresponding to the previous segment (second packet) stored in the global storage space);
sending a request to the source node to re-transmit the first packet (Sun: [n0099]: When the verification fails, the server will send a second feedback message to the terminal indicating that the verification failed, so that the terminal will re-upload the fragment. [n0124]); and
receiving a third packet that is a re-transmission of the first packet (Sun: [n0108]: In one embodiment, the file upload method further includes a fragment retransmission step, which specifically includes: receiving a second feedback message from the server when the verification fails; retrieving the historical hash value corresponding to the previous fragment uploaded before the current fragment based on the second feedback message, and re-uploading the current fragment based on the historical hash value);
continue the generation of the MAC tag with the third packet to produce a second result using the second intermediate state (Sun: [n0124]: In this way, the terminal continuously executes the above steps S302-S310 on the received fragment upload requests until the verification of each fragment in the target file is completed. [n0117]: S306. Perform a hash operation based on the current segment and the hash value corresponding to the previous segment stored in the global storage space to obtain the check hash value corresponding to the current segment, and verify the current hash value through the check hash value. [n0120]: S308: When the verification is successful, store the current fragment and store the current hash value corresponding to the current fragment in the global storage space); and
calculating a final MAC tag from the first result and the second result (Sun: [n0098]: The server performs a hash operation based on the current shard and the hash value corresponding to the previous shard stored in the global storage space to obtain the check hash value corresponding to the current shard, and then verifies the current hash value using the check hash value. [n0106]: The terminal performs a hash operation on fragment 1 to obtain the corresponding hash value 1. When uploading the second fragment, the terminal combines hash value 1 and fragment 2 and then performs a hash operation to obtain hash value 2. The terminal uploads hash value 2 and fragment 2).
Sun teaches a hash value but does not teach: a message authentication code (MAC). However, Elbaum teaches:
a message authentication code (MAC) (Elbaum: Fig. 4, column 9, lines 43-48: the left side presents the additional plaintext authentication tag, which is a Galois Message Authentication Code (GMAC) of the plaintext).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Elbaum in the invention of Sun to include the above limitations. The motivation to do so would be to facilitating plaintext integrity protection for link encryption in computing environments (Elbaum: column 1, lines 16-19).
As per claim 3, Sun in view of Elbaum teaches:
The method of claim 1, further comprising:
signaling to the source node to hold off sending one or more subsequent packets in the sequence of packets (Sun: [n0109]: In one embodiment, if the server fails to verify the current hash value, it indicates that the currently uploaded fragment is incorrect and may have been tampered with. At this point, the server will send a second feedback message to the terminal indicating that the verification failed. Upon receiving this second feedback information, the terminal can then re-upload the current fragment until it is successfully uploaded to the server, i.e., the second feedback information signals the terminal to hold off sending subsequent packets);
storing one or more intervening packets in a buffer until the third packet arrives (Sun: [n0109]: Upon receiving this second feedback information, the terminal can then re-upload the current fragment until it is successfully uploaded to the server. Holding received fragments in a buffer was well known to one of ordinary skill in the art before the effective filing date of the claimed invention);
resuming a hash computation using the second intermediate state once the third packet arrives (Sun: [n0124]: In this way, the terminal continuously executes the above steps S302-S310 on the received fragment upload requests until the verification of each fragment in the target file is completed. [n0117]: S306. Perform a hash operation based on the current segment and the hash value corresponding to the previous segment stored in the global storage space to obtain the check hash value corresponding to the current segment, and verify the current hash value through the check hash value. [n0120]: S308: When the verification is successful, store the current fragment and store the current hash value corresponding to the current fragment in the global storage space);
continue the hash computation with the one or more intervening packets stored in the buffer (Sun: [n0117]: S306. Perform a hash operation based on the current segment and the hash value corresponding to the previous segment stored in the global storage space to obtain the check hash value corresponding to the current segment, and verify the current hash value through the check hash value); and
signaling to the source node to continue sending the one or more subsequent packets in the sequence of packets (Sun: [n0101]: Specifically, when the verification is successful, the terminal will receive the first feedback information from the server indicating that the verification has been successful, and then traverse the next shard of the current shard based on the first feedback information. [n0103]: In one embodiment, after receiving the first feedback information, the terminal knows that the current fragment has been successfully uploaded to the server, and can then continue to start uploading the next fragment).
As per claim 4, Sun in view of Elbaum teaches:
The method of claim 1, wherein the second intermediate state comprises an intermediate hash state of a hash computation and an intermediate initialization vector (IV) (Sun: [n0106]: In this continuous uploading process, for the i-th fragment, the terminal merges the hash value i-1 (intermediate IV) calculated from fragment i-1 into fragment i, calculates the hash value i (second intermediate state) of the merged stream file, and transmits fragment i and the hash value i calculated in this step to the server. [n0107]: After receiving the current hash value and the current shard, the server will search for the hash value corresponding to the previous shard in the global storage space to verify the current hash value).
As per claim 5, Sun in view of Elbaum teaches:
The method of claim 1, wherein the error is a data integrity (DI) error in at least one of an encryption computation, an authentication computation, a static random access memory (SRAM) operation, or an input/output (I/O) operation (Sun: [n0107]: When the verification is successful, it indicates that the current uploaded fragment is legal and compliant (authentication computation)).
As per claim 6, Sun in view of Elbaum teaches:
The method of claim 1, wherein the generation of the MAC tag is performed in connection with an authentication algorithm that uses a hashing function to compute the MAC tag (Sun: [n0107]: After receiving the current hash value and the current shard, the server will search for the hash value corresponding to the previous shard in the global storage space to verify the current hash value. Elbaum: Fig. 4, column 9, lines 43-48: the left side presents the additional plaintext authentication tag, which is a Galois Message Authentication Code (GMAC) of the plaintext).
The examiner provides the same rationale to combine prior arts Sun and Elbaum as in claim 1 above.
As per claim 7, Sun in view of Elbaum teaches:
The method of claim 6, wherein the authentication algorithm is the Galois Message Authentication Code (GMAC) algorithm and the hash function is the GHASH function (Elbaum: Fig. 4, column 9, lines 43-48: the left side presents the additional plaintext authentication tag, which is a Galois Message Authentication Code (GMAC) of the plaintext).
The examiner provides the same rationale to combine prior arts Sun and Elbaum as in claim 1 above.
As per claim 14, Sun teaches:
An inline memory encryption (IME) engine comprising:
authentication logic to receive the segments of the output a final authentication tag associated with the data burst (Sun: [n0144]: In one embodiment, as shown in FIG5, a file verification device 500 is provided, including: a receiving module 501, a searching module 502, a verification module 503, a storage module 504, and a feedback module 505, wherein: The verification module 503 is used to perform a hash operation based on the current fragment and the hash value corresponding to the previous fragment stored in the global storage space to obtain the verification hash value corresponding to the current fragment, and to verify the current hash value through the verification hash value. [n0107]: The above file upload method splits the target file into multiple fragments when it needs to be uploaded, and then uploads them one by one. [n0090]: upload the first fragment and the corresponding hash value to the server. The server performs a hash operation on the first received fragment to obtain a verification hash value (intermediate state). [n0105]: When there are more fragments after the current fragment, the terminal will use the next fragment as the current fragment to be traversed in the next moment, and then jump to step S206 and continue to execute, so as to upload the next fragment to the server in a chained hash value correlation method. This process is repeated sequentially until all segments of the target file are successfully uploaded to the server, i.e., server will generate the final hash value after it processes the last fragment); and
integrity-protection logic coupled between the encryption logic and the authentication logic, the integrity-protection logic comprising: an intermediate state storage to store a copy of a last intermediate state computed by the authentication logic; and a packet storage to store a copy of one or more segments of the cyphertext data (Sun: [n0090]: The server stores the first shard and stores the hash value corresponding to the first shard (intermediate state) in the global storage space for verification of the next shard. [n0148]: Storage module 504 is used to store the current fragment when the verification is successful, and to store the current hash value corresponding to the current fragment to the global storage space),
wherein the integrity-protection logic is to: receive an indication of an error associated with a current segment of the cyphertext data (Sun: [n0109]: In one embodiment, if the server fails to verify the current hash value, it indicates that the currently uploaded fragment is incorrect and may have been tampered with); and cause the authentication logic to re-compute a current intermediate state associated with the current segment using the last intermediate state and the current segment of the cyphertext data without the error (Sun: [n0109]: At this point, the server will send a second feedback message to the terminal indicating that the verification failed. Upon receiving this second feedback information, the terminal can then re-upload the current fragment until it is successfully uploaded to the server. [n0124]: In this way, the terminal continuously executes the above steps S302-S310 on the received fragment upload requests until the verification of each fragment in the target file is completed. [n0117]: S306. Perform a hash operation based on the current segment and the hash value corresponding to the previous segment stored in the global storage space to obtain the check hash value corresponding to the current segment, and verify the current hash value through the check hash value).
Sun does not teach: encryption logic to receive segments of plaintext data of a data burst and output segments of cyphertext data of the data burst; authentication logic to receive the segments of the cyphertext data, output an intermediate state corresponding to a respective segment of the cyphertext data. However, Elbaum teaches:
encryption logic to receive segments of plaintext data of a data burst and output segments of cyphertext data of the data burst (Elbaum: Fig. 3, column 8, line 60-column 9, line 2: In one embodiment, ciphertext generation logic 312 generates ciphertext for sequentially numbered blocks. In such an embodiment, each block number is combined with an initialization vector (IV) and encrypted with a block cipher (e.g., AES). Subsequently, an exclusive-or (XOR) operation is performed using the result of the encryption and plaintext to generate the ciphertext);
authentication logic to receive the segments of the cyphertext data, output an intermediate state corresponding to a respective segment of the cyphertext data (Elbaum: Fig. 3, column 9, lines 4-9: Plaintext integrity protection mechanism 110 also includes GHASH logic 314 implemented to perform a GHASH function on blocks of ciphertext and encrypt the results to generate the ciphertext authentication tag (or outer tag)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Elbaum in the invention of Sun to include the above limitations. The motivation to do so would be to facilitating plaintext integrity protection for link encryption in computing environments (Elbaum: column 1, lines 16-19).
As per claim 15, Sun in view of Elbaum teaches:
The IME engine of claim 14, wherein the authentication logic implements the Galois Message Authentication Code (GMAC) algorithm that uses a GHASH function to generate the final authentication tag (Elbaum: column 8, lines 46-49: According to one embodiment, plaintext integrity protection mechanism 110 generates AES-GCM authentication tags implemented to provide integrity protection for both plaintext and ciphertext. Fig. 3, column 9, lines 4-9: Plaintext integrity protection mechanism 110 also includes GHASH logic 314 implemented to perform a GHASH function on blocks of ciphertext and encrypt the results to generate the ciphertext authentication tag (or outer tag)).
The examiner provides the same rationale to combine prior arts Sun and Elbaum as in claim 14 above.
As per claim 16, Sun in view of Elbaum teaches:
The IME engine of claim 14, further comprising data-integrity (DI) detection logic to detect the error, wherein the error is a DI error in at least one of an encryption computation by the encryption logic, an authentication computation by the authentication logic, a static random access memory (SRAM) operation, or an input/output (I/O) operation (Sun: [n0107]: When the verification is successful, it indicates that the current uploaded fragment is legal and compliant (authentication computation)).
As per claim 17, Sun in view of Elbaum teaches:
The IME engine of claim 16, wherein the integrity-protection logic is further to: hold sending an acknowledgment signal to a sender to indicate that a current authentication iteration is completed (Sun: [n0099]: In one embodiment, when the verification passes, the server sends a first feedback message to the terminal indicating that the verification has passed, enabling the terminal to continue uploading the next fragment. When the verification fails, the server will send a second feedback message to the terminal indicating that the verification failed, so that the terminal will re-upload the fragment, i.e., the feedback message is not transmitted until the verification of the current fragment is finished);
send a request to the sender to re-send the current segment (Sun: [n0099]: When the verification fails, the server will send a second feedback message to the terminal indicating that the verification failed, so that the terminal will re-upload the fragment); and
send the acknowledgment signal to the sender responsive to a determination that the re-computation of the current intermediate state is completed (Sun: (Sun: [n0124]: In this way, the terminal continuously executes the above steps S302-S310 on the received fragment upload requests until the verification of each fragment in the target file is completed. [n0117]: S306. Perform a hash operation based on the current segment and the hash value corresponding to the previous segment stored in the global storage space to obtain the check hash value corresponding to the current segment, and verify the current hash value through the check hash value. [n0124]: Specifically, when the verification is successful, the server can send the first feedback information to the terminal. After receiving the first feedback information, the terminal can continue to upload the next segment of the target file to be uploaded).
As per claim 20, Sun in view of Elbaum teaches:
The IME engine of claim 14, wherein the integrity-protection logic comprises: an error accumulator to receive the indication of the error (Sun: [n0144]: In one embodiment, as shown in FIG5, a file verification device 500 is provided, including: … a feedback module 505. [n0124]: When the verification fails, the server can send a second feedback message to the terminal. After receiving the second feedback message, the terminal can re-upload the current fragment); and a controller to control the intermediate state storage and the packet storage in response to the error (Sun: [n0111]: In the above embodiments, when the server finds that the current hash value in the fragment upload request sent by the terminal fails the verification, it indicates that the current fragment may have been tampered with (detecting error). The server then directly notifies the terminal to retransmit the fragment. [n0148]: Storage module 504 is used to store the current fragment when the verification is successful, and to store the current hash value corresponding to the current fragment to the global storage space, i.e., the storage of the current fragment and the corresponding hash value are controlled based on detecting an error).
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Sun in view of Elbaum as applied to claim 1 above, and further in view of US 7248587 to Sharma (hereinafter Sharma).
As per claim 2, Sun in view of Elbaum teaches:
The method of claim 1, further comprising: determining an identification number of the first packet in a sequence count for the sequence of packets (Sun: [n0116]: For each fragment, the terminal can also upload a corresponding fragment identifier, such as a fragment sequence number, during the upload process. In this way, the server can associate the fragment identifier with the hash value corresponding to the fragment and store it in the global storage space);
generating the request with the identification number of the packet to send the request to the source node to re-transmit the packet (Sun: [n0109]: At this point, the server will send a second feedback message to the terminal indicating that the verification failed. Upon receiving this second feedback information, the terminal can then re-upload the current fragment until it is successfully uploaded to the server);
continuing processing incoming packets of the sequence of packets with their corresponding identification numbers and updating intermediate states corresponding to the incoming packets until the third packet arrives (Sun: [n0116]: In this way, the server can associate the fragment identifier with the hash value corresponding to the fragment and store it in the global storage space [n0107]: the server will search for the hash value corresponding to the previous shard in the global storage space to verify the current hash value, i.e., the server continually updates the global storage space with the hash values of the incoming fragments that were successfully received); and
processing the third packet and updating the first intermediate state by considering the identification number of the packet in the sequence of packets (Sun: [n0124]: After receiving the second feedback message, the terminal can re-upload the current fragment. In this way, the terminal continuously executes the above steps S302-S310 on the received fragment upload requests until the verification of each fragment in the target file is completed. [n0117]: S306. Perform a hash operation based on the current segment and the hash value corresponding to the previous segment stored in the global storage space to obtain the check hash value corresponding to the current segment, and verify the current hash value through the check hash value. [n0120]: S308: When the verification is successful, store the current fragment and store the current hash value corresponding to the current fragment in the global storage space).
Sun in view of Elbaum teaches a request to re-transmit the fragment but does not teach: generating the request with the identification number of the packet to send the request to the source node to re-transmit the packet. However, Sharma teaches:
generating the request with the identification number of the packet to send the request to the source node to re-transmit the packet (Sharma: Fig. 2, column 1, lines 43-49: The prior packet can later be re-transmitted by sending the packet's sequence number 14 to the transmitter in a re-transmit request).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Sharma in the invention of Sun in view of Elbaum to include the above limitations. The motivation to do so would be to provide a fairly robust communications protocol (Sharma: column 1, lines 50-51).
Claims 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Sun in view of Elbaum as applied to claim 14 above, and further in view of US 20100135484 to Nishikawa et al (hereinafter Nishikawa).
As per claim 18, Sun in view of Elbaum does not teach the limitations of claim 18. However, Nishikawa teaches:
wherein the authentication logic comprises a plurality of authentication units, each authentication unit of the plurality of authentication units to compute an intermediate state of a respective segment in an authentication iteration (Nishikawa: [0046] a plurality of hash value calculation units adapted to execute a hash value calculation of the input block and to output a hash intermediate value. [0048] an intermediate value storage unit adapted to store a hash intermediate value output from the active hash value calculation unit in association with a message to be processed; and [0049] an output unit adapted to output a hash intermediate value associated with all blocks of the message to be processed as a hash value of the message).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Nishikawa in the invention of Sun in view of Elbaum to include the above limitations. The motivation to do so would be to allow simultaneous execution of a plurality of hash algorithms, and to assure a small circuit scale and high security (Nishikawa: [0037]).
As per claim 19, Sun in view of Elbaum and Nishikawa teaches:
The IME engine of claim 18, wherein the integrity-protection logic comprises an additional authentication unit to re-compute the current intermediate state associated with the current segment using the last intermediate state and the current segment of the cyphertext data without the error (Sun: [n0109]: Upon receiving this second feedback information, the terminal can then re-upload the current fragment until it is successfully uploaded to the server. [n0124]: In this way, the terminal continuously executes the above steps S302-S310 on the received fragment upload requests until the verification of each fragment in the target file is completed. [n0117]: S306. Perform a hash operation based on the current segment and the hash value corresponding to the previous segment stored in the global storage space to obtain the check hash value corresponding to the current segment, and verify the current hash value through the check hash value).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US 20190207766 to Sanghvi: Embodiments of the invention are directed to a system, method, or computer program product for file transmission validation and failure location identification. The invention provides a cryptographic hashing function to generate a unique hash for each block in a file being transmitted. The hash from the previous block is included along with the contents of the next block to create the hash for the next block. Similarly the hash from the previous blocks is used with the data of that block to generate the hash forming onto a block chain. The files can only be transmitted to a select group of servers forming a private block chain network within the entity server systems after the files are transmitted to the target location. As such, the system can recalculate the hashes and match hash blocks to identify an exact file location of a transmission failure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MADHURI R HERZOG whose telephone number is (571)270-3359. The examiner can normally be reached 8:30AM-4:30PM.
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, Taghi Arani can be reached at (571)272-3787. 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.
MADHURI R. HERZOG
Primary Examiner
Art Unit 2438
/MADHURI R HERZOG/Primary Examiner, Art Unit 2438
Prosecution Insights