DETAILED ACTION
This Office Action has been issued in response to Applicant's Amendment filed February 2, 2026.
Claims 1, 19, and 20 have been amended. Claims 1-3 and 5-20 have been examined and are pending.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant's arguments filed February 2, 2026 have been fully considered but they are not persuasive.
Applicant argues Lindskog does not disclose a PUF library and working on different hardware. Firstly the latter limitation of working on different hardware is an intended use and does not claim the aspect functionally. Secondly, Paragraph [0011] of Lindskog discloses a rule module configured to compare the received measurement to at least one rule that implements the policy and to enter a policy state on the basis of the comparison. The management module further comprises a control module configured to configure the PUF in accordance with a policy state entered by the rule module. Paragraph [0014] of Lindskog discloses each state that may be entered by the management module enforces the PUF to use certain sub functions. A security component comprising a PUF, which component is effectively “aware” of the environment in which it is operating. That is, the security component is operable to modify its behavior according to components booted on its device and a policy. The management module of the security component evaluates the environment in which it operates by comparing measurements (such as hash values) of booted components or of the hardware state to a predefined policy.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-3 and 5-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. The independent claims recite “wherein the plurality of hardware PUF methods enable the PUF key to be generated on a variety of different hardware types without modification to the adaptive hardware PUF library.” Examiner was unable to find support for ‘without modification to the adaptive hardware PUF library.’
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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 1-3, 5-9, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US Pub. No. 2023/0351057 to Lindskog et al. (hereinafter “Lindskog”) and further in view of US Pub. No. 2013/0051552 to Handschuh et al. (hereinafter “Handschuh”).
As to Claim 1, Lindskog discloses a method for generating a physical unclonable function (PUF) key, comprising:
obtaining a hardware output of a unique identifier of a hardware source by reading the hardware source (Paragraph [0011] of Lindskog discloses measurement module configured to receive, from a device boot process, at least one of a measurement of a component on the device, or a measurement of a hardware state of the device);
selecting one of a plurality of hardware PUF methods stored in an adaptive hardware PUF library, each of the plurality of hardware PUF methods adapted to a respective [error rate], based on the [error rate] of the hardware source, the [error rate] of the hardware source determined based on a mapping table mapping a hardware type of the hardware source to the [error rate] (Paragraph [0011] of Lindskog discloses a rule module configured to compare the received measurement to at least one rule that implements the policy and to enter a policy state on the basis of the comparison. The management module further comprises a control module configured to configure the PUF in accordance with a policy state entered by the rule module. Paragraph [0014] of Lindskog discloses each state that may be entered by the management module enforces the PUF to use certain sub functions. A security component comprising a PUF, which component is effectively “aware” of the environment in which it is operating. That is, the security component is operable to modify its behavior according to components booted on its device and a policy. The management module of the security component evaluates the environment in which it operates by comparing measurements (such as hash values) of booted components or of the hardware state to a predefined policy. Modifying behavior according to the booted components is understood to be adapting to the types of components. Paragraph [0083] of Lindskog discloses the error correction module may also or alternatively comprise bit selection functions in which unreliable bits in the PUF response are removed. The bit selection functions may operate on the basis of knowledge of the characteristics of a particular PUF); and
generating the PUF key by processing the hardware output using the selected hardware PUF method (Paragraph [0002] of Lindskog discloses a PUF response may be used to create a unique device identity or a device unique key)
wherein each of the plurality of hardware PUF methods is configured to receive the hardware output as input and generate a hardware PUF value as output, the PUF key generated based on the hardware PUF value (Paragraph [0082] of Lindskog discloses the error correction module 519 takes the PUF response as input and outputs a corrected response to the one way function 554)
wherein the plurality of hardware PUF methods enable the PUF key to be generated on a variety of different hardware types without modification to the adaptive hardware PUF library (Paragraph [0011] of Lindskog discloses a rule module configured to compare the received measurement to at least one rule that implements the policy and to enter a policy state on the basis of the comparison. The management module further comprises a control module configured to configure the PUF in accordance with a policy state entered by the rule module. Paragraph [0014] of Lindskog discloses each state that may be entered by the management module enforces the PUF to use certain sub functions. A security component comprising a PUF, which component is effectively “aware” of the environment in which it is operating. That is, the security component is operable to modify its behavior according to components booted on its device and a policy. The management module of the security component evaluates the environment in which it operates by comparing measurements (such as hash values) of booted components or of the hardware state to a predefined policy. Modifying behavior according to the booted components is understood to be adapting to the types of components.).
Lindskog does not explicitly disclose based on an error rate.
Paragraph [0126] of Handschuh discloses Error correcting code construction algorithms may be used to tailor an error correcting code to the parameters of the PUF, in particular its error rate and the number of output bits.
It would have been obvious to one of ordinary skill in the art before the effective filing of the invention to combine the PUF system as disclosed by Lindskog, with adjusting based on an error rate as disclosed by Handschuh. One of ordinary skill in the art would have been motivated to combine to apply a known technique to a known device. Lindskog and Handschuh are directed toward PUF Systems and as such it would be obvious to use the techniques of one in the other. Paragraph [0083] of Lindskog discloses the error correction module may also or alternatively comprise bit selection functions in which unreliable bits in the PUF response are removed. The bit selection functions may operate on the basis of knowledge of the characteristics of a particular PUF. Paragraph [0126] of Handschuh discloses Error correcting code construction algorithms may be used to tailor an error correcting code to the parameters of the PUF, in particular its error rate and the number of output bits.
As to Claim 2, Lindskog-Handschuh discloses the method of claim 1, further comprising detecting a hardware type of the hardware source (Paragraph [0014] of Lindskog discloses a security component comprising a PUF, which component is effectively “aware” of the environment in which it is operating. That is, the security component is operable to modify its behavior according to components booted on its device and a policy. The management module of the security component evaluates the environment in which it operates by comparing measurements (such as hash values) of booted components or of the hardware state to a predefined policy).
As to Claim 3, Lindskog-Handschuh discloses the method of claim 1, wherein the plurality of hardware PUF methods are stored in the mapping table (Paragraph [0011] of Lindskog discloses a rule module configured to compare the received measurement to at least one rule that implements the policy and to enter a policy state on the basis of the comparison. Paragraph [0083] of Lindskog discloses the error correction module may also or alternatively comprise bit selection functions in which unreliable bits in the PUF response are removed. The bit selection functions may operate on the basis of knowledge of the characteristics of a particular PUF. The rules, policies, and knowledge of characteristics are mappings).
As to Claim 5, Lindskog-Handschuh discloses the method of claim 1, wherein the plurality of hardware PUF methods comprise a first hardware PUF method with an error tolerance of less than a first threshold, a second hardware PUF method with an error tolerance of less than a second threshold, a third hardware PUF method with an error tolerance of less than a third threshold, and a fourth hardware PUF method with an error tolerance of less than a fourth threshold (Paragraph [0014] of Lindskog discloses each state that may be entered by the management module enforces the PUF to use certain sub functions. A security component comprising a PUF, which component is effectively “aware” of the environment in which it is operating. That is, the security component is operable to modify its behavior according to components booted on its device and a policy. The management module of the security component evaluates the environment in which it operates by comparing measurements (such as hash values) of booted components or of the hardware state to a predefined policy. Modifying behavior according to the booted components is understood to be adapting to the types of components. Paragraph [0083] of Lindskog discloses the error correction module may also or alternatively comprise bit selection functions in which unreliable bits in the PUF response are removed. The bit selection functions may operate on the basis of knowledge of the characteristics of a particular PUF. Paragraph [0126] of Handschuh discloses Error correcting code construction algorithms may be used to tailor an error correcting code to the parameters of the PUF, in particular its error rate and the number of output bits. Where tailoring an error correcting code is understood to be multiple levels).
Examiner recites the same rationale to combine used for claim 1.
As to Claim 6, Lindskog-Handschuh discloses the method of claim 5, wherein the first, second, third, and fourth thresholds are 10%, 20%, 30%, and 40%, respectively Paragraph [0014] of Lindskog discloses each state that may be entered by the management module enforces the PUF to use certain sub functions. A security component comprising a PUF, which component is effectively “aware” of the environment in which it is operating. That is, the security component is operable to modify its behavior according to components booted on its device and a policy. The management module of the security component evaluates the environment in which it operates by comparing measurements (such as hash values) of booted components or of the hardware state to a predefined policy. Modifying behavior according to the booted components is understood to be adapting to the types of components. Paragraph [0083] of Lindskog discloses the error correction module may also or alternatively comprise bit selection functions in which unreliable bits in the PUF response are removed. The bit selection functions may operate on the basis of knowledge of the characteristics of a particular PUF. Paragraph [0126] of Handschuh discloses Error correcting code construction algorithms may be used to tailor an error correcting code to the parameters of the PUF, in particular its error rate and the number of output bits. Where tailoring an error correcting code is understood to be multiple levels and the specific levels are arbitrary design choice).
Examiner recites the same rationale to combine used for claim 1.
As to Claim 7, Lindskog-Handschuh discloses the method of claim 5, wherein the fourth threshold is greater than each of the first, second, and third thresholds; and wherein the selected hardware PUF method is the fourth hardware PUF method if the hardware type is not detected (Paragraph [0014] of Lindskog discloses each state that may be entered by the management module enforces the PUF to use certain sub functions. A security component comprising a PUF, which component is effectively “aware” of the environment in which it is operating. That is, the security component is operable to modify its behavior according to components booted on its device and a policy. The management module of the security component evaluates the environment in which it operates by comparing measurements (such as hash values) of booted components or of the hardware state to a predefined policy. Modifying behavior according to the booted components is understood to be adapting to the types of components. Paragraph [0083] of Lindskog discloses the error correction module may also or alternatively comprise bit selection functions in which unreliable bits in the PUF response are removed. The bit selection functions may operate on the basis of knowledge of the characteristics of a particular PUF. Paragraph [0126] of Handschuh discloses Error correcting code construction algorithms may be used to tailor an error correcting code to the parameters of the PUF, in particular its error rate and the number of output bits. Where tailoring an error correcting code is understood to be multiple levels).
Examiner recites the same rationale to combine used for claim 1.
As to Claim 8, Lindskog-Handschuh discloses the method of claim 1, wherein the selected hardware PUF method is selected by a user (Paragraph [0090] of Lindskog discloses a policy is uploaded to the rule interpreter 904. Where uploading a policy is understood to be done by a user).
As to Claim 9, Lindskog-Handschuh discloses the method of claim 1, wherein the hardware output is an initial power-on value of the hardware source (Paragraph [0011] of Lindskog discloses measurement module configured to receive, from a device boot process, at least one of a measurement of a component on the device, or a measurement of a hardware state of the device).
As to Claim 19, Lindskog discloses a non-transitory computer-readable medium comprising computer program code stored thereon for generating a physical unclonable function (PUF) key, wherein the code, when executed by one or more processors, causes the one or more processors to perform a method comprising:
obtaining a hardware output of a unique identifier of a hardware source by reading the hardware source (Paragraph [0011] of Lindskog discloses measurement module configured to receive, from a device boot process, at least one of a measurement of a component on the device, or a measurement of a hardware state of the device);
selecting one of a plurality of hardware PUF methods stored in an adaptive hardware PUF library, each of the plurality of hardware PUF methods adapted to a respective [error rate], based on the [error rate] of the hardware source, the [error rate] of the hardware source determined based on a mapping table mapping a hardware type of the hardware source to the [error rate] (Paragraph [0011] of Lindskog discloses a rule module configured to compare the received measurement to at least one rule that implements the policy and to enter a policy state on the basis of the comparison. The management module further comprises a control module configured to configure the PUF in accordance with a policy state entered by the rule module. Paragraph [0014] of Lindskog discloses each state that may be entered by the management module enforces the PUF to use certain sub functions. A security component comprising a PUF, which component is effectively “aware” of the environment in which it is operating. That is, the security component is operable to modify its behavior according to components booted on its device and a policy. The management module of the security component evaluates the environment in which it operates by comparing measurements (such as hash values) of booted components or of the hardware state to a predefined policy. Modifying behavior according to the booted components is understood to be adapting to the types of components. Paragraph [0083] of Lindskog discloses the error correction module may also or alternatively comprise bit selection functions in which unreliable bits in the PUF response are removed. The bit selection functions may operate on the basis of knowledge of the characteristics of a particular PUF); and
generating the PUF key by processing the hardware output using the selected hardware PUF method (Paragraph [0002] of Lindskog discloses a PUF response may be used to create a unique device identity or a device unique key)
wherein each of the plurality of hardware PUF methods is configured to receive the hardware output as input and generate a hardware PUF value as output, the PUF key generated based on the hardware PUF value (Paragraph [0082] of Lindskog discloses the error correction module 519 takes the PUF response as input and outputs a corrected response to the one way function 554))
wherein the plurality of hardware PUF methods enable the PUF key to be generated on a variety of different hardware types without modification to the adaptive hardware PUF library (Paragraph [0011] of Lindskog discloses a rule module configured to compare the received measurement to at least one rule that implements the policy and to enter a policy state on the basis of the comparison. The management module further comprises a control module configured to configure the PUF in accordance with a policy state entered by the rule module. Paragraph [0014] of Lindskog discloses each state that may be entered by the management module enforces the PUF to use certain sub functions. A security component comprising a PUF, which component is effectively “aware” of the environment in which it is operating. That is, the security component is operable to modify its behavior according to components booted on its device and a policy. The management module of the security component evaluates the environment in which it operates by comparing measurements (such as hash values) of booted components or of the hardware state to a predefined policy. Modifying behavior according to the booted components is understood to be adapting to the types of components.).
Lindskog does not explicitly disclose based on an error rate.
Paragraph [0126] of Handschuh discloses Error correcting code construction algorithms may be used to tailor an error correcting code to the parameters of the PUF, in particular its error rate and the number of output bits.
Examiner recites the same rationale to combine used for claim 1.
As to Claim 20, Lindskog discloses a computing device comprising one or more processors operable to perform a method for generating a physical unclonable function (PUF) key, wherein the method comprises:
obtaining a hardware output of a unique identifier of a hardware source by reading the hardware source to (Paragraph [0011] of Lindskog discloses measurement module configured to receive, from a device boot process, at least one of a measurement of a component on the device, or a measurement of a hardware state of the device);
selecting one of a plurality of hardware PUF methods stored in an adaptive hardware PUF library, each of the plurality of hardware PUF methods adapted to a respective [error rate], based on the [error rate] of the hardware source, the [error rate] of the hardware source determined based on a mapping table mapping a hardware type of the hardware source to the [error rate] (Paragraph [0011] of Lindskog discloses a rule module configured to compare the received measurement to at least one rule that implements the policy and to enter a policy state on the basis of the comparison. The management module further comprises a control module configured to configure the PUF in accordance with a policy state entered by the rule module. Paragraph [0014] of Lindskog discloses each state that may be entered by the management module enforces the PUF to use certain sub functions. A security component comprising a PUF, which component is effectively “aware” of the environment in which it is operating. That is, the security component is operable to modify its behavior according to components booted on its device and a policy. The management module of the security component evaluates the environment in which it operates by comparing measurements (such as hash values) of booted components or of the hardware state to a predefined policy. Modifying behavior according to the booted components is understood to be adapting to the types of components. Paragraph [0083] of Lindskog discloses the error correction module may also or alternatively comprise bit selection functions in which unreliable bits in the PUF response are removed. The bit selection functions may operate on the basis of knowledge of the characteristics of a particular PUF); and
generating the PUF key by processing the hardware output using the selected hardware PUF method (Paragraph [0002] of Lindskog discloses a PUF response may be used to create a unique device identity or a device unique key)
wherein each of the plurality of hardware PUF methods is configured to receive the hardware output as input and generate a hardware PUF value as output, the PUF key generated based on the hardware PUF value (Paragraph [0082] of Lindskog discloses the error correction module 519 takes the PUF response as input and outputs a corrected response to the one way function 554)
wherein the plurality of hardware PUF methods enable the PUF key to be generated on a variety of different hardware types without modification to the adaptive hardware PUF library (Paragraph [0011] of Lindskog discloses a rule module configured to compare the received measurement to at least one rule that implements the policy and to enter a policy state on the basis of the comparison. The management module further comprises a control module configured to configure the PUF in accordance with a policy state entered by the rule module. Paragraph [0014] of Lindskog discloses each state that may be entered by the management module enforces the PUF to use certain sub functions. A security component comprising a PUF, which component is effectively “aware” of the environment in which it is operating. That is, the security component is operable to modify its behavior according to components booted on its device and a policy. The management module of the security component evaluates the environment in which it operates by comparing measurements (such as hash values) of booted components or of the hardware state to a predefined policy. Modifying behavior according to the booted components is understood to be adapting to the types of components.).
Lindskog does not explicitly disclose based on an error rate.
Paragraph [0126] of Handschuh discloses Error correcting code construction algorithms may be used to tailor an error correcting code to the parameters of the PUF, in particular its error rate and the number of output bits.
Examiner recites the same rationale to combine use for claim 1.
Claims 10-13 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Lindskog-Handschuh and further in view of US Pub. No. 2022/0294644 to Liu et al. (hereinafter “Liu).
As to Claim 10, Lindskog-Handschuh discloses the method of claim 1. Lindskog-Handschuh does not explicitly disclose further comprising passing the PUF key to a key management service.
However, Liu discloses this. Paragraph [0079] of Liu discloses the customer may submit a replacement public key (SHSRK) to a key management server.
It would have been obvious to one of ordinary skill in the art before the effective filing of the invention to combine the PUF system as disclosed by Lindskog, with sending keys to a key management service as disclosed by Liu. One of ordinary skill in the art would have been motivated to combine to apply a known technique to a known device. Lindskog and Liu are directed toward PUF systems and as such it would be obvious to use the techniques of one in the other. Lindskog would be improved by Liu’s techniques to increase functionality of Lindskog’s generated keys.
As to Claim 11, Lindskog-Handschuh discloses the method of claim 1. Lindskog-Handschuh does not explicitly disclose wherein the PUF key comprises a PUF symmetric key and a PUF asymmetric key, wherein the PUF asymmetric key comprises a public key and a private key.
However, Liu discloses this. Paragraph [0013] of Liu discloses a first set of asymmetric keys are generated using a physically unclonable function (PUF). Paragraph [0052] of Liu discloses a physical unclonable function (PUF) may be used to generate a symmetric key on the device.
Examiner recites the same rationale to combine used for claim 10.
As to Claim 12, Lindskog-Handschuh-Liu discloses the method of claim 11, further comprising using the PUF symmetric key to securely store local user data (Paragraph [0032] of Liu discloses encryption operations).
Examiner recites the same rationale to combine used for claim 10.
As to Claim 13, Lindskog-Handschuh-Liu discloses the method of claim 11, further comprising using the PUF asymmetric key to securely communicate with a remote computer on a computer network (Paragraph [0013] of Liu discloses this public key can thus be used to ensure that only authorized parties issue commands to the device, thereby hardening the device from unauthorized access).
Examiner recites the same rationale to combine used for claim 10.
As to Claim 18, Lindskog-Handschuh-Liu discloses the method of claim 11, further comprising generating a device certificate for device authentication using the PUF asymmetric key (Paragraph [0055] of Liu discloses an operation of certificate generation 157 is performed to generate a certificate 165 that contains a digital signature 169 signed using the device ID private key 160).
Examiner recites the same rationale to combine used for claim 10.
Claims 14-17 are rejected under 35 U.S.C. 103 as being unpatentable over Lindskog-Handschuh-Liu and further in view of US Pub. No. 2019/0138753 to Wallrabenstein (hereinafter “Wallrabenstein”).
As to Claim 14, Lindskog-Handschuh-Liu discloses the method of claim 11. Lindskog-Handschuh-Liu does not explicitly disclose further comprising using the PUF asymmetric key to join a secret sharing group comprising a plurality of computers.
However, Wallrabenstein discloses this. Paragraph [0106] of Wallrabenstein discloses PUF based techniques are adapted to secret or private key or secret sharing to permit threshold cryptography for use with a PUF device.
It would have been obvious to one of ordinary skill in the art before the effective filing of the invention to combine the PUF system as disclosed by Lindskog, with using secret sharing as disclosed by Wallrabenstein. One of ordinary skill in the art would have been motivated to combine to apply a known technique to a known device. Lindskog and Wallrabenstein are directed toward PUF systems and as such it would be obvious to use the techniques of one in the other. Lindskog would be improved by Wallrabenstein’s techniques to increase functionality of Lindskog’s generated keys.
As to Claim 15, Lindskog-Handschuh-Liu-Wallrabenstein discloses the method of claim 14, further comprising: encrypting data, by a first computer in the secret sharing group, using an encryption key; splitting, by the first computer in the secret sharing group, the encryption key using a secret sharing method into a plurality of encryption key parts; and sending, by the first computer, the encryption key parts to at least one other computer of the plurality of computers in the secret sharing group; encrypting, by the at least one other computer of the plurality of computers in the secret sharing group, the encryption key part using the PUF symmetric key (Paragraph [0085] of Wallrabenstein discloses Shamir’s secret sharing scheme may be used to split a key. These steps are known steps of the scheme).
Examiner recites the same rationale to combine used for claim 14.
As to Claim 16, Lindskog-Handschuh-Liu-Wallrabenstein discloses the method of claim 15, further comprising: decrypting, by the at least one other computer of the plurality of computers in the secret sharing group, the encryption key part using the PUF symmetric key; retrieving, by the first computer, one or more of the plurality of encryption key parts from the at least one other computer of the plurality of computers in the secret sharing group; combining, by the first computer, the encryption key parts to recover the encryption key using the secret sharing method; and decrypting, by the first computer, the data using the encryption key (Paragraph [0085] of Wallrabenstein discloses Shamir’s secret sharing scheme may be used to split a key. These steps are known steps of the scheme).
Examiner recites the same rationale to combine used for claim 14.
As to Claim 17, Lindskog-Handschuh-Liu-Wallrabenstein discloses the method of claim 16, wherein the first computer sends m encryption key parts, wherein the first computer retrieves n encryption key parts, wherein n is less than m, and wherein n is equal to or greater than a threshold required to recover the encryption key using the secret sharing method (Paragraph [0085] of Wallrabenstein discloses Shamir’s secret sharing scheme may be used to split a key such that the key can be recovered through polynomial interpolation using individual shares of the key or secret. These steps are known steps of the scheme).
Examiner recites the same rationale to combine used for claim 14.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Kevin S Mai whose telephone number is (571)270-5001. The examiner can normally be reached Monday to Friday 9AM to 5PM.
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, Philip Chea can be reached on 5712723951. 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 S MAI/Primary Examiner, Art Unit 2499
Prosecution Insights