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 .
Specification
The abstract of the disclosure is objected to because the abstract contains phrase that should be avoided such as “document describes”. A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is: a hash manager configured to in claim 16.
Because this claim limitation(s) is being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it is being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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 1-14 and 16-21 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.
Re. claims 1-14, the claims recite “loading a first input message into an input buffer”, “loading at least a portion of the digest message directly to a configurable position in the input buffer” and “repeating the hash computation for a predetermined number of iterations, each of the repeated hash computations resulting in at least a portion of a digest message loaded directly into said configurable position in the input buffer for use as input to be used by a later iteration of the repeated hash computation”. The BRI of the claim requires the functional language that a device must somehow loading a first input message into an input buffer”, “loading at least a portion of the digest message directly to a configurable position in the input buffer” and “repeating the hash computation for a predetermined number of iterations, each of the repeated hash computations resulting in at least a portion of a digest message loaded directly into said configurable position in the input buffer for use as input to be used by a later iteration of the repeated hash computation”. The recited functions do not flow from the structure recited in the claim. The function language are not performed by any element in the claim.
The boundaries of the functional language is unclear because the claim does not provide a discernable boundary on what performs the function. It is unclear whether the function requires structure or simply a result. Thus, one of ordinary skill in the art would not be able to draw a clear boundary between what is and is not covered by the claim. Please see MPEP 2173.05(g)
Re. claims 1, 5, 8, 16, 18 and 21; The claim language “configurable position” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. Unclear what position of the input buffet would be “configurable” to load a digest message. For the purpose of examination, the claim interpretation is being interpreted as loading the digest message in the input buffer.
Claims 2-14 and 17-21 fall together accordingly as they do not cure the deficiencies of the independent claims.
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 1-3, 5, 9, 16 and 18 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Schultz (US 20130166514).
Re. claim 1, Schultz discloses a computer-implemented method comprising: loading a first input message into an input buffer (Schultz discloses a hash value calculation module 136 included in a media player application (e.g., Flash.RTM. player application) 138 calculates an output hash value for the received player file using the input key value and the input hash value. As described below, the output hash value can be generated through iterative modifications to the input hash value. Throughout these iterations, the input, intermediate, and output hash values can be stored in a hash buffer 137 included, for example, within the hash value calculation module 136 [0021][0027] Fig. 2, inputs are stored into the buffer); computing, by a hash engine and using the first input message as an input, a hash computation, the hash computation resulting in a digest message (Schultz discloses a hash value calculation module 136 included in a media player application (e.g., Flash.RTM. player application) 138 calculates an output hash value for the received player file using the input key value and the input hash value. As described below, the output hash value can be generated through iterative modifications to the input hash value. Throughout these iterations, the input, intermediate, and output hash values can be stored in a hash buffer 137 included, for example, within the hash value calculation module 136 [0021][0022] Fig. 2, hash value calculation module as the hash engine hashing the input); loading at least a portion of the digest message directly to a configurable position in the input buffer (Schultz discloses a hash value calculation module 136 included in a media player application (e.g., Flash.RTM. player application) 138 calculates an output hash value for the received player file using the input key value and the input hash value. As described below, the output hash value can be generated through iterative modifications to the input hash value. Throughout these iterations, the input, intermediate, and output hash values can be stored in a hash buffer 137 included, for example, within the hash value calculation module 136 [0021] Fig. 2, output hash value stored in the buffer); and repeating the hash computation for a predetermined number of iterations, each of the repeated hash computations resulting in at least a portion of a digest message loaded directly into said configurable position in the input buffer for use as input to be used by a later iteration of the repeated hash computation (Schultz discloses the output hash value can be generated through iterative modifications to the input hash value. Throughout these iterations, the input, intermediate, and output hash values can be stored in a hash buffer 137 included [0021][00027] Fig. 2 repeating the hash for a predetermined number of iterations, the results stored in the buffer).
Re. claim 2, Schultz discloses the computer-implemented method as recited in claim 1, wherein the hash engine is a cryptographic processor implementing a cryptographic hash function (Schultz [0021][0022]).
Re. claim 3, Schultz discloses the computer-implemented method as recited in claim 1, wherein the digest message is 32 bytes in length (Schultz [0043]).
Re. claim 5, Schultz discloses the computer-implemented method as recited in claim 1, wherein loading at least a portion of the digest message directly into the configurable position in the input buffer is implemented without loading the digest message to memory external to the hash engine (Schultz [0021]).
Re. claim 9, Schultz discloses the computer-implemented method as recited in claim 1 wherein the repeating the hash computation executes as many as 256 times (Schultz discloses the algorithm 200 can include a particular number of processing rounds 204 (e.g., two, three, five, ten, or any other number of processing rounds) [0032]).
Re. claim 16, Schultz discloses an integrated circuit (Schultz discloses digital electronic circuitry [0049]) comprising: an input buffer with a configurable position input (Schultz discloses hash buffer [0021]; a hash engine configured to compute hash values (Schultz discloses hash value calculation module [0021]); and a hash manager (Schultz discloses a processor [0053-0054]) configured to: load a first input message into the input buffer (Schultz discloses a hash value calculation module 136 included in a media player application (e.g., Flash.RTM. player application) 138 calculates an output hash value for the received player file using the input key value and the input hash value. As described below, the output hash value can be generated through iterative modifications to the input hash value. Throughout these iterations, the input, intermediate, and output hash values can be stored in a hash buffer 137 included, for example, within the hash value calculation module 136 [0021][0027] Fig. 2, inputs are stored into the buffer); compute, with the hash engine and using the first input message as an input, a hash computation, the hash computation resulting in a digest message (Schultz discloses a hash value calculation module 136 included in a media player application (e.g., Flash.RTM. player application) 138 calculates an output hash value for the received player file using the input key value and the input hash value. As described below, the output hash value can be generated through iterative modifications to the input hash value. Throughout these iterations, the input, intermediate, and output hash values can be stored in a hash buffer 137 included, for example, within the hash value calculation module 136 [0021][0022] Fig. 2, hash value calculation module as the hash engine hashing the input); load at least a portion of the digest message directly to the configurable position in the input buffer (Schultz discloses a hash value calculation module 136 included in a media player application (e.g., Flash.RTM. player application) 138 calculates an output hash value for the received player file using the input key value and the input hash value. As described below, the output hash value can be generated through iterative modifications to the input hash value. Throughout these iterations, the input, intermediate, and output hash values can be stored in a hash buffer 137 included, for example, within the hash value calculation module 136 [0021] Fig. 2, output hash value stored in the buffer); and repeating the hash computation for a predetermined number of iterations, each of the repeated hash computations resulting in at least a portion of a digest message loaded directly into the configurable position in the input buffer for use as input to be used by a later iteration of the repeated hash computation (Schultz discloses the output hash value can be generated through iterative modifications to the input hash value. Throughout these iterations, the input, intermediate, and output hash values can be stored in a hash buffer 137 included [0021][00027] Fig. 2 repeating the hash for a predetermined number of iterations, the results stored in the buffer).
Re. claim 18, rejection of claim 16 is included and claim 18 is rejected with the same rationale as applied in claim 5 above.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 4 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Schultz (US 20130166514) in view of Cao (CN 105335331).
Re. claim 4, Schultz discloses the computer-implemented method as recited in claim 1, Schultz discloses input buffer and hash engine, Schultz does not explicitly teach but Cao teaches wherein the input buffer is a register file of the hash engine (Cao teaches register file [0013][0014][0019][0020]).
Therefore, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to modify the method and system disclosed by Schultz to include register file as disclosed by Cao. One of ordinary skill in the art would have been motivated for the purpose of ensuring large-scale data exchange and parallel computation in 256Sha (Cao [0013][0029]).
Re. claim 17, rejection of claim 16 is included and claim 17 is rejected with the same rationale as applied in claim 4 above.
Claims 6 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Schultz (US 20130166514) in view of Nelson (US 20220231839).
Re. claim 6, Schultz discloses the computer-implemented method as recited in claim 1, Schultz discloses first input message, Schultz do not explicitly teach but Nelson teaches wherein the first input message is a bit-string including a concatenation of a prefix, a counter, and a secret seed (Nelson teaches a message that includes the unique identification (UID) 122, a counter value 225, and the cryptographic nonce 227. The counter value 225 is obtained from a counter 221 in the memory device 130 [0111]).
Therefore, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to modify the method and system disclosed by Schultz to include a messages containing a prefix, a counter, and a secret seed as disclosed by Nelson. One of ordinary skill in the art would have been motivated for the purpose of using these information for authentication (Nelson [0040]).
Re. claim 19, rejection of claim 16 is included and claim 19 is rejected with the same rationale as applied in claim 6 above.
Claims 7 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Schultz (US 20130166514) in view of Nelson (US 20220231839) and in further view of Ciet et al. (US 20160119133, hereinafter Ciet).
Re. claim 7, Schultz-Nelson teach the computer-implemented method as recited in claim 6, Schultz-Nelson do not explicitly teach but Ciet teaches the first input message is 56 bytes in length (Ciet [0048]).
Therefore, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to modify the method and system disclosed by Schultz-Nelson to include a messages with 56 byte in length as disclosed by Ciet. One of ordinary skill in the art would have been motivated for the purpose of ensured that input message has a length that is a multiple of a specified block size (Ciet [0048]).
Re. claim 20, rejection of claim 19 is included and claim 20 is rejected with the same rationale as applied in claim 7 above.
Claims 8 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Schultz (US 20130166514) in view of Yap et al. (US 20090141887, hereinafter Yap).
Re. claim 8, Schultz discloses the computer-implemented method as recited in claim 1, Schultz does not explicitly teach but Yap teaches wherein the first input message comprises a secret seed loaded into said configurable position in the input buffer, and loading at least a portion of the digest message directly into the configurable position in the input buffer replaces the secret seed (Yap teaches the HMAC function 306-1 computes HMAC(secret, A(1)+seed) to provide P_hash out1 [0041][0049][053]).
Therefore, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to modify the method and system disclosed by Schultz to include wherein the first input message comprises a secret seed loaded into said configurable position in the input buffer, and loading at least a portion of the digest message directly into the configurable position in the input buffer replaces the secret seed as disclosed by Yap. One of ordinary skill in the art would have been motivated for the purpose of accelerate hashing algorithm (Yap [0021]).
Re. claim 21, rejection of claim 19 is included and claim 21 is rejected with the same rationale as applied in claim 8 above.
Claims 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over Schultz (US 20130166514) in view of Tomonaga et al. (US 20160142315, hereinafter Tomonaga).
Re. claim 10, Schultz discloses the computer-implemented method as recited in claim 1, Schultz does not explicitly teach but Tomonaga teaches further comprising: decrementing an iteration counter; and incrementing a 1-byte counter if an input message to the repeated hash computation includes a 1-byte counter (Tomonaga teaches entry counter is incremented by 1 and decremented by 1 [0191][0211]).
Therefore, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to modify the method and system disclosed by Schultz to include decrementing an iteration counter; and incrementing a 1-byte counter if an input message to the repeated hash computation includes a 1-byte counter as disclosed by Tomonaga. One of ordinary skill in the art would have been motivated for the purpose of correctly disable the entry and check the presene or absence of unused hash functions (Tomonaga [0203][0365]).
Re. claim 11, Schultz-Tomonaga teach the computer-implemented method as recited in claim 10, Tomonaga further teaches wherein the iteration counter is assigned a value in a range of 0 to 255 at initialization (Tomonaga teaches an initial value of the entry counter may be 0 [0192]).
Therefore, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to modify the method and system disclosed by Schultz to include wherein the iteration counter is assigned a value in a range of 0 to 255 at initialization as disclosed by Tomonaga. One of ordinary skill in the art would have been motivated for the purpose of correctly disable the entry and check the present or absence of unused hash functions (Tomonaga [0203][0365]).
Claims 12-14 are rejected under 35 U.S.C. 103 as being unpatentable over Schultz (US 20130166514) in view of Tomonaga et al. (US 20160142315, hereinafter Tomonaga) and in further view of Sarangdhar et al. (US 20130159727, hereinafter Sarangdhar).
Re. claim 12, Schultz-Tomonaga teach the computer-implemented method as recited in claim 11, Schultz-Tomonaga do not explicitly teach but Sarangdhar teaches wherein the iteration counter is loaded into a register of the hash engine (Sarangdhar teaches HMAC key register 411 may store one or more HMAC keys received from Manageability Engine (ME) logic 420 and processor 430 (described below). Said HMAC keys may be associated with a specific monotonic counter [0054]).
Therefore, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to modify the method and system disclosed by Schultz-Tomonaga to include wherein the iteration counter is assigned a value in a range of 0 to 255 at initialization as disclosed by Sarangdhar. One of ordinary skill in the art would have been motivated for the purpose of protecting threats from accessing the counter (Sarangdhar [0053]).
Re. claim 13, Schultz-Tomonaga teach the computer-implemented method as recited in claim 10, Schultz-Tomonaga do not explicitly teach but Sarangdhar teaches wherein the 1-byte counter starts at a value configured for hash-based signature verification (Sarangdhar teaches if the command is authenticated (e.g., if it includes the correct signature signed using the HMAC key), the counter value is returned to the platform interconnect, along with the aforementioned authentication credentials (e.g., a nonce, signature), 340. The platform interconnect may use the counter value in a secure ME firmware execution environment if the nonce and signature are verified to be correct, 350 again using the Operational HMAC Key [0046]).
Therefore, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to modify the method and system disclosed by Schultz-Tomonaga to include wherein the 1-byte counter starts at a value configured for hash-based signature verification as disclosed by Sarangdhar. One of ordinary skill in the art would have been motivated for the purpose of protecting threats from accessing the counter (Sarangdhar [0053]).
Re. claim 14, Schultz-Tomonaga teach the computer-implemented method as recited in claim 13 Schultz-Tomonaga do not explicitly teach but Sarangdhar teaches wherein the 1-byte counter monotonically increases (Sarangdhar teaches monotonic counters may also be configured to count (e.g., increment or decrement) when requested to do so, and to produce a monotonic count value in response to a read operation [0055][0054][0020]).
Therefore, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to modify the method and system disclosed by Schultz-Tomonaga to include wherein the 1-byte counter monotonically increases as disclosed by Sarangdhar. One of ordinary skill in the art would have been motivated for the purpose of protecting threats from accessing the counter (Sarangdhar [0053]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Suresh (US 20190319799) discloses apply a hash-based signature scheme to the message using a private key to generate the signature comprising a public key, or a verification logic to verify a signature received in association with the message, the verification logic to apply the hash-based signature scheme to verify the signature using the public key, and an accelerator logic to apply a structured order to at least one set of inputs to the hash-based signature scheme.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KEVIN A AYALA whose telephone number is (571)270-3912. The examiner can normally be reached Monday-Thursday 8AM-5PM; Friday: Variable EST.
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, Jorge Ortiz-Criado can be reached at 571-272-7624. 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.
/KEVIN AYALA/Primary Examiner, Art Unit 2496