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 .
DETAILED ACTION
1. This Office Action is in response to the amendment filed on 11/10/2025. Claims 1-2, 4-9, 11-16 and 18-20 are pending in this application. Claims 1, 8 and 15 are independent claims. Claims 3, 10 and 17 are canceled. This Office Action is made Final.
Claim Rejections - 35 USC § 112
2. 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.
3. Claims 1-2, 4-9, 11-16 and 18-20 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 1 recites “the unique device identification”, but it’s not clear to the examiner whether “the unique device identification” refers to an immutable unique device identification or one target unique device identification in its preceding limitations.
Claims 1 and 8 recite the limitation " the single target unique device identification" in “a second hash value based on a hash of a combination of the firmware to be installed on the device and the single target unique device identification”. There is insufficient antecedent basis for this limitation in the claim.
Claim 8 recites “the firmware” in “based on the firmware”. There is insufficient antecedent basis for this limitation in the claim.
Claim 15 recites “the device” in “a method for distributing firmware to be installed on the device”. There is insufficient antecedent basis for this limitation in the claim.
Claim 15 recites at least one target device and each respective target unique device. It’s not clear to the examiner whether they refer to each other.
Claims 2, 4-7, 9, 11-14, 16 and 18-20 are also rejected for incorporating the deficiency of their independent claims 1, 8 and 15 respectively.
Claim Rejections - 35 USC § 101
4. 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.
5. Claims 1-2, 4-9, 11-16 and 18-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The independent claims 1, 8 and 15 are corresponding to one of four statutory categories including method, system, and method respectively under step 1.
The claim 1 recites “a method for authenticating a device associated with an immutable unique device identification to install firmware on the device, the method comprising: retrieving, using processing circuitry at the device, the unique device identification; receiving, at the device, a package comprising signed data based on at least one target unique device identification and based on the firmware to be installed on the device; decrypting the signed data; hashing a combination of the firmware to be installed on the device and the unique device identification to generate a first hash value, wherein: the decrypted signed data comprises a second hash value based on a hash of a combination of the firmware to be installed on the device and the single target unique device identification; authenticating, using the processing circuitry, the device based on the signed data by comparing the first hash value to the second hash value; and in response to authenticating the device, using the processing circuitry to cause the firmware to be installed on the device”.
The claim 8 recites “a device, comprising processing circuitry configured to: retrieve an immutable unique device identification; receive a package comprising signed data based on at least one target unique device identification and based on the firmware to be installed on the device; decrypt the signed data; hash a combination of the firmware to be installed on the device and the immutable unique device identification to generate a first hash value, wherein: the decrypted signed data comprises a second hash value based on a hash of a combination of the firmware to be installed on the device and the single target unique device identification; authenticate the device based on the signed data by comparing the first hash value to the second hash value; and in response being authenticated, use processing circuitry to cause the firmware to be installed on the device”.
The claim 15 recites “a method for distributing firmware to be installed on the device to at least one target device, the method comprising: determining, for each of the at least one target device, a respective target unique device identification comprises retrieving each respective target unique device identification from each respective target unique device; generating at least one package for the at least one target device, each of the at least one package comprising respective signed data based on the at least one target unique device identification and on the firmware to be installed on the device, comprises hashing a combination of the firmware to be installed on the device and a respective one of the at least one target unique device identification; and communicating the at least one package and the firmware to be installed on the device to at least the at least one target device”
The limitation of the claims 1 and 8 of “authenticating, using the processing circuitry, the device based on the signed data; and” as drafted, is a mental process that, under its broadest reasonable interpretation, covers mental processes but for the recitation of generic computer components. For example, but for the “authenticating” in the context of this claim encompasses the user may authenticate the device based on the signed data based on the analysis with a pen and paper or in a human mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea under Step 2A Prong 1.
The limitation of the claim 15 of “determining for each of the at least one target device, a respective target unique device identification comprises” as drafted, is a mental process that, under its broadest reasonable interpretation, covers mental processes but for the recitation of generic computer components. For example, but for the “determining” in the context of this claim encompasses the user may determine for each of the at least one target device, a respective target unique device identification device based on the analysis with a pen and paper or in a human mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea under Step 2A Prong 1.
The limitation of the claims 1 and 8 of “decrypting the signed data; and hashing a combination of the firmware and the unique device identification, wherein: the at least one target unique device identification comprises a single target unique device identification, the decrypted signed data comprises a hash of a combination of the firmware and the single target unique device identification, and authenticating the device based on the signed data comprises comparing the hash of the combination of the firmware and the target unique device identification with the hash of the combination of the firmware and the unique device identification” as drafted, is a mental process/mathematical operation that, under its broadest reasonable interpretation, covers mental processes but for the recitation of generic computer components. For example, but for the “decrypting”, “hashing (mathematically)”, “authenticating” and “comparing” in the context of this claim encompasses the user may decrypt the signed data; and hashing a combination of the firmware and the unique device identification, hash a combination of the firmware and the unique device identification and authenticate the device based on the signed data comprises comparing the hash of the combination of the firmware and the target unique device identification with the hash of the combination of the firmware and the unique device identification based on the analysis with a pen and paper or in a human mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping and “Mathematical Operation” groupings of abstract ideas. Accordingly, the claim recites an abstract idea under Step 2A Prong 1.
The limitation of the claim 15 of “hashing a combination of the firmware to be installed on the device and a respective one of the at least one target unique device identification” as drafted, is a mental process/mathematical operation that, under its broadest reasonable interpretation, covers mental processes but for the recitation of generic computer components. For example, but for the “hashing (mathematically)” in the context of this claim encompasses the user may hash a combination of the firmware to be installed on the device and a respective one of the at least one target unique device identification based on the analysis with a pen and paper or in a human mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping and “Mathematical Operation” groupings of abstract ideas. Accordingly, the claim recites an abstract idea under Step 2A Prong 1.
This judicial exception is not integrated into a practical application. In particular, the claims 1 and 8 recite additional elements such as “retrieving, using processing circuitry at the device, the unique device identification” and “retrieve an immutable unique device identification”.
Examiner would like to point out that with the broad reasonable interpretation, this element amounts to mere data gathering under MPEP § 2106.05(g): Insignificant Extra-Solution Activity, which does not impose any meaningful limits on practicing the mental process (insignificant additional element). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to insignificant additional elements under Step 2A Prong 2 and Step 2B.
This judicial exception is not integrated into a practical application. In particular, the claim 15 recites additional elements such as “retrieving each respective target unique device identification from each respective target unique device”.
Examiner would like to point out that with the broad reasonable interpretation, this element amounts to mere data gathering under MPEP § 2106.05(g): Insignificant Extra-Solution Activity, which does not impose any meaningful limits on practicing the mental process (insignificant additional element). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to insignificant additional elements under Step 2A Prong 2 and Step 2B.
This judicial exception is not integrated into a practical application. In particular, the claims 1 and 8 recite additional elements such as “receiving, at the device, a package comprising signed data based on at least one target unique device identification and based on the firmware”.
Examiner would like to point out that with the broad reasonable interpretation, this element amounts to mere data gathering under MPEP § 2106.05(g): Insignificant Extra-Solution Activity, which does not impose any meaningful limits on practicing the mental process (insignificant additional element). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to insignificant additional elements under Step 2A Prong 2 and Step 2B.
This judicial exception is not integrated into a practical application. In particular, the claims 1 and 11 recite additional elements such as “in response to authenticating the device, using the processing circuitry to cause the firmware to be installed on the device”.
Examiner would like to point out that with the broad reasonable interpretation, this element amounts to apply it under MPEP § 2106.05(f): Mere Instructions to Apply an Exception, which does not impose any meaningful limits on practicing the mental process (insignificant additional element). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to insignificant additional elements under Step 2A Prong 2 and Step 2B.
This judicial exception is not integrated into a practical application. In particular, the claim 15 recites additional elements such as “generating at least one package for the at least one target device, each of the at least one package comprising respective signed data based on the at least one target unique device identification and on the firmware”.
Examiner would like to point out that with the broad reasonable interpretation, this element amounts to apply it under MPEP § 2106.05(f): Mere Instructions to Apply an Exception, which does not impose any meaningful limits on practicing the mental process (insignificant additional element). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to insignificant additional elements under Step 2A Prong 2 and Step 2B.
This judicial exception is not integrated into a practical application. In particular, the claims 2 and 12 recite additional elements such as “communicating the at least one package and the firmware to at least the at least one target device”.
Examiner would like to point out that with the broad reasonable interpretation, this element amounts to apply it under MPEP § 2106.05(f): Mere Instructions to Apply an Exception, which does not impose any meaningful limits on practicing the mental process (insignificant additional element). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to insignificant additional elements under Step 2A Prong 2 and Step 2B.
This judicial exception is not integrated into a practical application. In particular, the claims 2, 9 and 16 recite additional elements such as “the package further comprises the firmware” and “wherein the processing circuitry is further configured to receive a package comprising firmware”.
Examiner would like to point out that with the broad reasonable interpretation, this element
amounts to field of use under MPEP § 2106.05(h): Field of Use and Technological Environment, which
does not impose any meaningful limits on practicing the mental process. Accordingly, this additional
element does not integrate the abstract idea into a practical application because it does not impose any
meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea under Step 2A Prong 2 and 2B.
The limitation of the claims 4, 6, 11 and 13 of “the signed data is encrypted and decrypted using a digital signature scheme” as drafted, is a mental process that, under its broadest reasonable interpretation, covers mental processes but for the recitation of generic computer components. For example, but for the “encrypting” and “decrypting” in the context of this claim encompasses the user may encrypt and decrypt the signed data using a digital signature scheme with a pen and paper or in a human mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea under Step 2A Prong 1.
The limitation of the claims 5 and 12 of “decrypting the signed data; and identifying the at least one target unique device identification from the decrypted signed data, wherein authenticating the device based on the signed data comprises comparing the at least one target unique device identification to the unique device identification” as drafted, is a mental process that, under its broadest reasonable interpretation, covers mental processes but for the recitation of generic computer components. For example, but for the “decrypting”, “identifying”, “authenticating” and “comparing” in the context of this claim encompasses the user may decrypt the signed data and identify the at least one target unique device identification from the decrypted signed data, wherein authenticating the device based on the signed data comprises comparing the at least one target unique device identification to the unique device identification with a pen and paper or in a human mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea under Step 2A Prong 1.
This judicial exception is not integrated into a practical application. In particular, the claims 7, 14 and 20 recite additional elements such as “the package further comprises data indicative of at least one of a type of the firmware or a configuration of the device” and “wherein the processing circuitry is further configured to receive a package comprising data indicative of at least one of a type of the firmware or a configuration of the device”.
Examiner would like to point out that with the broad reasonable interpretation, this element
amounts to field of use under MPEP § 2106.05(h): Field of Use and Technological Environment, which
does not impose any meaningful limits on practicing the mental process. Accordingly, this additional
element does not integrate the abstract idea into a practical application because it does not impose any
meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea under Step 2A Prong 2 and 2B.
This judicial exception is not integrated into a practical application. In particular, the claim 10 recites additional elements such as “the at least one target unique device identification comprises a single target unique device identification”.
Examiner would like to point out that with the broad reasonable interpretation, this element
amounts to field of use under MPEP § 2106.05(h): Field of Use and Technological Environment, which
does not impose any meaningful limits on practicing the mental process. Accordingly, this additional
element does not integrate the abstract idea into a practical application because it does not impose any
meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea under Step 2A Prong 2 and 2B.
The limitation of the claim 17 of “determining each respective target unique device identification comprises retrieving each respective target unique device identification from each respective target unique device” as drafted, is a mental process that, under its broadest reasonable interpretation, covers mental processes but for the recitation of generic computer components. For example, but for the “determining” in the context of this claim encompasses the user may determine each respective target unique device identification comprises retrieving each respective target unique device identification from each respective target unique device with a pen and paper or in a human mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea under Step 2A Prong 1.
This judicial exception is not integrated into a practical application. In particular, the claim 17 recites additional elements such as “generating each of the at least one package comprises hashing a combination of the firmware and a respective one of the at least one target unique device identification”.
Examiner would like to point out that with the broad reasonable interpretation, this element amounts to apply it under MPEP § 2106.05(f): Mere Instructions to Apply an Exception, which does not impose any meaningful limits on practicing the mental process (insignificant additional element). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to insignificant additional elements under Step 2A Prong 2 and Step 2B.
The limitation of the claim 18 and 19 of “encrypting each of the at least one package” and “encrypting each of the at least one packages comprises encrypting each of the at least one packages using a digital signature scheme” as drafted, is a mental process that, under its broadest reasonable interpretation, covers mental processes but for the recitation of generic computer components. For example, but for the “encrypting” in the context of this claim encompasses the user may encrypt each of the at least one packages comprises encrypting each of the at least one packages using a digital signature scheme with a pen and paper or in a human mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea under Step 2A Prong 1.
Dependent claims 2, 4-7, 9, 11-14, 16 and 18-20 are also similar rejected under same rationale as cited above wherein these claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. These claims are merely further elaborate the mental process itself or providing additional definition of process which does not impose any meaningful limits on practicing the abstract idea. Claims 2, 4-7, 9, 11-14, 16 and 18-20 are also rejected for incorporating the deficiency of their independent claims 1, 8 and 15 respectively.
Claim Rejections - 35 USC § 103
6. 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.
7. 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.
8. Claims 1, 5, 8 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Shell (US PGPub 20050132357), in view of Sood (US PGPub 20220019667), and further in view of Nozue (US PGPub 20130305394).
As per Claim 1, Shell teaches of a method for authenticating a device associated with an immutable unique device identification to install firmware on the device, the method comprising: retrieving, using processing circuitry at the device, the unique device identification; (Par 44, In order to provide an appropriately keyed image, e.g., on demand, the image to be keyed is initially stored on a server 220. Through a secure mechanism, the UUID [unique device identification] of the device is communicated to the server, where it is then used to key the image. For example, the device owner can securely send the UUID when requesting an update, or the device manufacturer can maintain an internal database of UUIDs that are authorized to receive an update. Par 13, In one implementation, a package is keyed based on the package and a universally-unique identifier (UUID) associated with the device. The UUID allows packages to be keyed to a single device or a class of devices, depending on whether the UUID corresponds to a device or a class of devices.)
receiving, at the device, a package comprising signed data based on at least one target unique device identification and based on the firmware to be installed on the device; (Fig. 2 and Par 43, In order to provide an appropriately keyed image, e.g., on demand, the image to be keyed is initially stored on a server 220. Through a secure mechanism, the UUID of the device is communicated to the server, where it is then used to key the image. For example, the device owner can securely send the UUID when requesting an update, or the device manufacturer can maintain an internal database of UUIDs that are authorized to receive an update. Par 17, In one implementation, the package data that is used in the hash corresponds to a description of the package that is maintained on the device after package installation. Par 18, Once the package is keyed and obtained at the device, the device determines whether it has a demand for keying on the package being installed.)
authenticating … based on the signed data; and (Par 57, The countersignature 206 used to key packages to a device contains a signature with a protected attribute. This protected attribute is an authenticated attribute (which is new). To determine whether a package contains a valid signature, the certificate array 204 is enumerated, and each element in the array is checked for the authenticated attribute 206. If this attribute is found, this is a keying signature.)
using the processing circuitry to cause the firmware to be installed on the device. (Fig. 3 308-> 316, Par 18, If there is a keying demand, the algorithm for computing the hash is reapplied to the package contents and the device UUID, and the results are compared with the results that were determined on the server side and stored in the package. If the results concur, the signature on the key is found to be valid, and installation is allowed. Par 56, When installing a package onto a device, the key information files in the image are enumerated.)
hashing a combination of the firmware to be installed on the device and the unique device identification to generate a first hash value, wherein: [the decrypted signed data comprises] a second hash value based on a hash of a combination of the firmware to be installed on the device and the single target unique device identification; (Par 17, In one implementation, the package data that is used in the hash corresponds to a description of the package [software/firmware] that is maintained on the device after package installation. Par 44, Once the server 220 obtains the device UUID and has access to the image, in one implementation the server applies a hashing algorithm to both entities to obtain (e.g., via concatenation) a single entity, which in turn can be signed. This can be represented essentially as a formula: Sign.sub.key(Hash(Hash(pkg data).vertline.Hash(device ID))). Par 46, As a result, the manifest file 230 serves as an excellent entity for hashing in the above formula (as the package data [firmware]) to represent the package, which as described above is then combined with the hash of the device UUID, with the result signed. Par 52, As represented in FIG. 2, each package such as the package 202 may be keyed, that is, have an associated countersignature 206, which as described above is a hash of the device ID and a hash of the package-related data (e.g., the manifest file that contains the package information). Par 17, A manifest file that accompanies the package to describe the contents of that package to the system, by including a package identifier, version number and a list of files [firmware] in the package, provides the package-related data for hashing. Par 46, The package data that is used in the hash can be based on an actual hash of the package contents. The manifest file 230 includes the package identifier, version number and a list of files in the package. Claim 3, wherein the server keys the image entity by obtaining a first hash of data corresponding to the image entity, obtaining a second hash of the UUID, combining the first and second hashes, signing the combined first and second hashes to produce a key, and associating the key with the image entity. It’s obvious that the first hash is based on the firmware information (package data, i.e. package id, version number or etc.) and the device ID and the second has is based on another firmware information (package data) and target device ID.)
Shell does not specifically teach, however Sood teaches of authenticating, using the processing circuitry, the device based on the signed data … ; and in response to authenticating the device, (Claim 30. The apparatus of claim 26, wherein the processing circuitry to authenticate the first device based on the device signature is further to: authenticate, based on the device signature, a hardware identity or a firmware identity of the first device. Claim 26, a processing circuitry to: receive, via the I/O circuitry, a device signature from a first device of the one or more devices, wherein the device signature cryptographically identifies the first device; authenticate the first device based on the device signature)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add authenticating, using the processing circuitry, the device based on the signed data; and in response to authenticating the device, as conceptually seen from the teaching of Sood, into that of Shell because this modification can help authenticate the target device for the intended firmware to be installed.
Neither Shell nor Sood specifically teaches, however Nozue teaches of the decrypted signed data comprises a second hash value; decrypting the signed data; (Par 55, The verification of the signature 504 is performed by comparing a hash value obtained by decrypting the signature 504 with the public key 505 with the hash value of information regarding the license identifier 501, the application information 502, and the device identifier 503, and determining whether or not the hash values coincide with each other. Par 56, That is, when the signature 504 is Sign, the public key 505 is Pub_KEY, and the hash value obtained by decryption is H_dec, the following expression is obtained. H_dec=P(Sign,Pub_KEY) Par 68, First, the operational system server 103 compares the device identifier 207 of the host device with the device identifier 503 of the license file 301 (802), and if both coincide with each other (YES in 803), decrypts the signature 504 of the license file 301 using the public key 505 of the license file 301 (804). Data obtained by decryption is referred to as data A (805). An encryption scheme to be used may be determined by a program in advance.)
by comparing the first hash value to the second hash value (Par 52, The signature 504 is obtained by calculating the hash value of information regarding the license identifier 501, the application information 502, and the device identifier 503, and encrypting the hash value using a secret key in the license source through a public key encryption scheme. Par 57, When the hash value of information regarding the license identifier 501, the application information 502 [firmware], and the device identifier 503 is H, the following expression is obtained. H=f(L.sub.--ID|AP.sub.--INF|ID.sub.--S) The verification of the signature 505 is performed in accordance with whether or not H and H_dec coincide with each other. Par 68, First, the operational system server 103 compares the device identifier 207 [1st hash value] of the host device with the device identifier 503 [2nd hash value] of the license file 301 (802), and if both coincide with each other (YES in 803), decrypts the signature 504 of the license file 301 using the public key 505 of the license file 301 (804). Data obtained by decryption is referred to as data A (805). An encryption scheme to be used may be determined by a program in advance. Subsequently, the hash value of information regarding the license identifier 501 of the license file 301, the application information 502, and the device identifier 503 is calculated (806), and the result is referred to as data B (807). Data A (805) and data B (807) are compared with each other (808), if both coincide with each other (YES in 809), it is determined that the validity of the license file 301 is confirmed, and the validity confirmation operation ends (811). Claim 1. calculates a second value on the basis of the acquire second device identification information, the first device identification information, and the unique information, compares the calculated second value with the first value of the first authentication key. Par 68, First, the operational system server 103 compares the device identifier 207 of the host device with the device identifier 503 of the license file 301 (802), and if both coincide with each other (YES in 803), decrypts the signature 504 of the license file 301 using the public key 505 of the license file 301 (804).)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add decrypting the signed data; the decrypted signed data comprises a second hash value; by comparing the first hash value to the second hash value, as conceptually seen from the teaching of Nozue, into that of Shell and Sood because this modification can help authenticate the target device for the intended firmware to be installed.
As per Claim 5, neither Shell nor Sood specifically teaches, however Nozue teaches of the method of claim 1, further comprising: decrypting the signed data; and identifying the at least one target unique device identification from the decrypted signed data, wherein authenticating the device based on the signed data comprises comparing the at least one target unique device identification to the unique device identification. (Par 55-56, The verification of the signature 504 is performed by comparing a hash value obtained by decrypting the signature 504 with the public key 505 with the hash value of information regarding the license identifier 501, the application information 502, and the device identifier 503, and determining whether or not the hash values coincide with each other. That is, when the signature 504 is Sign, the public key 505 is Pub_KEY, and the hash value obtained by decryption is H_dec, the following expression is obtained. H_dec=P(Sign,Pub_KEY))
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add decrypting the signed data; and identifying the at least one target unique device identification from the decrypted signed data, wherein authenticating the device based on the signed data comprises comparing the at least one target unique device identification to the unique device identification, as conceptually seen from the teaching of Nozue, into that of Shell and Sood because this modification can help authenticate the target device for the intended firmware to be installed.
As per Claim 8, Shell teaches of a device, comprising processing circuitry configured to: retrieve an immutable unique device identification; (Par 13, In one implementation, a package is keyed based on the package and a universally-unique identifier (UUID) associated with the device. The UUID allows packages to be keyed to a single device or a class of devices, depending on whether the UUID corresponds to a device or a class of devices. Par 37, As indicated above, the keying process relies on the ability to uniquely identify the device for which the image is to be keyed. To this end, each device needs to provide a universally-unique identifier (UUID) 208. To function properly, this UUID should be hardware-generated, permanent [immutable], guaranteed unique across the set of devices on which an image may be installed and cannot be set by any other mechanism.)
receive a package comprising signed data based on at least one target unique device identification and based on the firmware to be installed on the device; (Fig. 2 and Par 43, In order to provide an appropriately keyed image, e.g., on demand, the image [package] to be keyed is initially stored on a server 220. Through a secure mechanism, the UUID of the device is communicated to the server, where it is then used to key the image. For example, the device owner can securely send the UUID when requesting an update, or the device manufacturer can maintain an internal database of UUIDs that are authorized to receive an update. Par 17, In one implementation, the package data that is used in the hash corresponds to a description of the package that is maintained on the device after package installation. Par 18, Once the package is keyed and obtained at the device, the device determines whether it has a demand for keying on the package being installed.)
use processing circuitry to cause the firmware to be installed on the device. (Fig. 3 308-> 316, Par 18, If there is a keying demand, the algorithm for computing the hash is reapplied to the package contents and the device UUID, and the results are compared with the results that were determined on the server side and stored in the package. If the results concur, the signature on the key is found to be valid, and installation is allowed. Par 56, When installing a package onto a device, the key information files in the image are enumerated.)
hash a combination of the firmware to be installed on the device and the immutable unique device identification to generate a first hash value, wherein: [the decrypted signed data comprises] a second hash value based on a hash of a combination of the firmware to be installed on the device and the single target unique device identification (Par 17, In one implementation, the package data that is used in the hash corresponds to a description of the package [software/firmware] that is maintained on the device after package installation. Par 44, Once the server 220 obtains the device UUID and has access to the image, in one implementation the server applies a hashing algorithm to both entities to obtain (e.g., via concatenation) a single entity, which in turn can be signed. This can be represented essentially as a formula: Sign.sub.key(Hash(Hash(pkg data).vertline.Hash(device ID))). Par 46, As a result, the manifest file 230 serves as an excellent entity for hashing in the above formula (as the package data [firmware]) to represent the package, which as described above is then combined with the hash of the device UUID, with the result signed. Par 52, As represented in FIG. 2, each package such as the package 202 may be keyed, that is, have an associated countersignature 206, which as described above is a hash of the device ID and a hash of the package-related data (e.g., the manifest file that contains the package information). Par 17, A manifest file that accompanies the package to describe the contents of that package to the system, by including a package identifier, version number and a list of files [firmware] in the package, provides the package-related data for hashing. Par 46, The package data that is used in the hash can be based on an actual hash of the package contents. The manifest file 230 includes the package identifier, version number and a list of files in the package. Claim 3, wherein the server keys the image entity by obtaining a first hash of data corresponding to the image entity, obtaining a second hash of the UUID, combining the first and second hashes, signing the combined first and second hashes to produce a key, and associating the key with the image entity. It’s obvious that the first hash is based on the firmware information (package data, i.e. package id, version number or etc.) and the device ID and the second has is based on another firmware information (package data) and target device ID.)
Shell does not specifically teach, however Sood teaches of authenticate the device based on the signed data … ; and in response being authenticated, (Claim 30. The apparatus of claim 26, wherein the processing circuitry to authenticate the first device based on the device signature is further to: authenticate, based on the device signature, a hardware identity or a firmware identity of the first device. Claim 26, a processing circuitry to: receive, via the I/O circuitry, a device signature from a first device of the one or more devices, wherein the device signature cryptographically identifies the first device; authenticate the first device based on the device signature)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add authenticate the device based on the signed data; and in response being authenticated, as conceptually seen from the teaching of Sood, into that of Shell because this modification can help authenticate the target device for the intended firmware to be installed.
Neither Shell nor Sood specifically teaches, however Nozue teaches to decrypt the signed data; the decrypted signed data comprises a second hash value (Par 55, The verification of the signature 504 is performed by comparing a hash value obtained by decrypting the signature 504 with the public key 505 with the hash value of information regarding the license identifier 501, the application information 502, and the device identifier 503, and determining whether or not the hash values coincide with each other. Par 56, That is, when the signature 504 is Sign, the public key 505 is Pub_KEY, and the hash value obtained by decryption is H_dec, the following expression is obtained. H_dec=P(Sign,Pub_KEY) Par 68, First, the operational system server 103 compares the device identifier 207 of the host device with the device identifier 503 of the license file 301 (802), and if both coincide with each other (YES in 803), decrypts the signature 504 of the license file 301 using the public key 505 of the license file 301 (804). Data obtained by decryption is referred to as data A (805). An encryption scheme to be used may be determined by a program in advance.)
by comparing the first hash value to the second hash value (Par 52, The signature 504 is obtained by calculating the hash value of information regarding the license identifier 501, the application information 502, and the device identifier 503, and encrypting the hash value using a secret key in the license source through a public key encryption scheme. Par 57, When the hash value of information regarding the license identifier 501, the application information 502 [firmware], and the device identifier 503 is H, the following expression is obtained. H=f(L.sub.--ID|AP.sub.--INF|ID.sub.--S) The verification of the signature 505 is performed in accordance with whether or not H and H_dec coincide with each other. Par 68, First, the operational system server 103 compares the device identifier 207 [1st hash value] of the host device with the device identifier 503 [2nd hash value] of the license file 301 (802), and if both coincide with each other (YES in 803), decrypts the signature 504 of the license file 301 using the public key 505 of the license file 301 (804). Data obtained by decryption is referred to as data A (805). An encryption scheme to be used may be determined by a program in advance. Subsequently, the hash value of information regarding the license identifier 501 of the license file 301, the application information 502, and the device identifier 503 is calculated (806), and the result is referred to as data B (807). Data A (805) and data B (807) are compared with each other (808), if both coincide with each other (YES in 809), it is determined that the validity of the license file 301 is confirmed, and the validity confirmation operation ends (811). Claim 1. calculates a second value on the basis of the acquire second device identification information, the first device identification information, and the unique information, compares the calculated second value with the first value of the first authentication key. Par 68, First, the operational system server 103 compares the device identifier 207 of the host device with the device identifier 503 of the license file 301 (802), and if both coincide with each other (YES in 803), decrypts the signature 504 of the license file 301 using the public key 505 of the license file 301 (804).)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add decrypting the signed data; the decrypted signed data comprises a second hash value; by comparing the first hash value to the second hash value, as conceptually seen from the teaching of Nozue, into that of Shell and Sood because this modification can help authenticate the target device for the intended firmware to be installed.
As per Claim 12. neither Shell nor Sood specifically teach, however Nozue teaches of the device of claim 8, wherein the processing circuitry is further configured to: decrypt the signed data; identify the at least one target unique device identification from the decrypted signed data; and authenticate the device based on comparing the at least one target unique device identification to the unique device identification. (Par 55-56, The verification of the signature 504 is performed by comparing a hash value obtained by decrypting the signature 504 with the public key 505 with the hash value of information regarding the license identifier 501, the application information 502, and the device identifier 503, and determining whether or not the hash values coincide with each other. That is, when the signature 504 is Sign, the public key 505 is Pub_KEY, and the hash value obtained by decryption is H_dec, the following expression is obtained. H_dec=P(Sign,Pub_KEY))
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add decrypt the signed data; identify the at least one target unique device identification from the decrypted signed data; and authenticate the device based on comparing the at least one target unique device identification to the unique device identification, as conceptually seen from the teaching of Nozue, into that of Shell and Sood because this modification can help authenticate the target device for the intended firmware to be installed.
9. Claims 2 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Shell (US PGPub 20050132357), in view of Sood (US PGPub 20220019667), and further in view of Lau (US PGPub 20150121070).
As per Claim 2, neither Shell nor Sood specifically teaches, however Lau teaches of the method of claim 1, wherein the package further comprises the firmware. (Par 19, Additionally, this device-specific piece of information can be transmitted, along with a unique identifier for the device (e.g., an identification number or code unique to the device), to a server system that maintains a repository of authorized firmware packages for the device. When the server system subsequently sends a firmware package for installation on the device, the server system could embed the device-specific information within the firmware package. A bootloader of the device could then check the information embedded in the firmware package with the information written on the device in order to determine whether the firmware package is an authorized firmware package. For example, the bootloader could determine the firmware package is authorized if the tokens match, and otherwise could determine that the firmware is an unauthorized firmware package. Par 23, As discussed above, one embodiment provides a firmware package embedded with a token, and the bootloader component 125 of the device 110 can compare the embedded token with a previously written token on the device (e.g., written to the protected memory 115 of the device at the time of manufacture) to determine whether the firmware package is authorized for installation on the device.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the package further comprises the firmware, as conceptually seen from the teaching of Lau, into that of Shell and Sood because this modification can help authenticate the target device for the intended firmware to be installed.
As per Claim 9, neither Shell nor Sood specifically teaches, however Lau teaches of the device of claim 8, wherein the package further comprises the firmware, wherein the processing circuitry is further configured to receive a package comprising firmware. (Par 19, Additionally, this device-specific piece of information can be transmitted, along with a unique identifier for the device (e.g., an identification number or code unique to the device), to a server system that maintains a repository of authorized firmware packages for the device. When the server system subsequently sends a firmware package for installation on the device, the server system could embed the device-specific information within the firmware package. A bootloader of the device could then check the information embedded in the firmware package with the information written on the device in order to determine whether the firmware package is an authorized firmware package. For example, the bootloader could determine the firmware package is authorized if the tokens match, and otherwise could determine that the firmware is an unauthorized firmware package. Par 23, As discussed above, one embodiment provides a firmware package embedded with a token, and the bootloader component 125 of the device 110 can compare the embedded token with a previously written token on the device (e.g., written to the protected memory 115 of the device at the time of manufacture) to determine whether the firmware package is authorized for installation on the device.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the package further comprises the firmware, wherein the processing circuitry is further configured to receive a package comprising firmware, as conceptually seen from the teaching of Lau, into that of Shell and Sood because this modification can help authenticate the target device for the intended firmware to be installed.
10. Claims 4, 6, 11 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Shell (US PGPub 20050132357), in view of Sood (US PGPub 20220019667), in view of Nozue (US PGPub 20130305394), and further in view of Reus (US PGPub 20090252325).
As per Claim 4, none of Shell, Sood and Nozue specifically teaches, however Reus teaches of the method of claim 3, wherein the signed data is encrypted and decrypted using a digital signature scheme. (Par 8, A recipient of the content caches it in anticipation of future use, receives the key sometime after the key release moment, and uses the key to decrypt the encrypted content into useable content. For software updates, metadata, which also may be decrypted, may be used to install the software update. Different and/or multiple keys may be received and used to decrypt different content. Par 49, If so, then step 320 validates the publisher's signature to verify that it is published by a publisher that this system trusts, unpacks the package and installs it according to the current install policy, which may be performed at some later scheduled time. Par 49, If so, then step 320 validates the publisher's signature to verify that it is published by a publisher that this system trusts, unpacks the package and installs it according to the current install policy, which may be performed at some later scheduled time.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the signed data is encrypted and decrypted using a digital signature scheme as conceptually seen from the teaching of Reus, into that of Shell, Sood and Nozue because this modification can help authenticate the target device for the intended firmware to be installed.
As per Claim 6. none of Shell, Sood and Nozue specifically teaches, however Reus teaches of the method of claim 5, wherein the signed data is encrypted and decrypted using a digital signature scheme. (Par 8, A recipient of the content caches it in anticipation of future use, receives the key sometime after the key release moment, and uses the key to decrypt the encrypted content into useable content.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the signed data is encrypted and decrypted using a digital signature scheme as conceptually seen from the teaching of Reus, into that of Shell, Sood and Nozue because this modification can help authenticate the target device for the intended firmware to be installed.
As per Claim 11, none of Shell, Sood and Nozue specifically teaches, however Reus teaches of the device of claim 10, wherein the signed data is encrypted using a digital signature scheme, wherein the processing circuitry is further configured to decrypt the signed data using a digital signature scheme. (Par 8, A recipient of the content caches it in anticipation of future use, receives the key sometime after the key release moment, and uses the key to decrypt the encrypted content into useable content. For software updates, metadata, which also may be decrypted, may be used to install the software update. Different and/or multiple keys may be received and used to decrypt different content. Par 49, If so, then step 320 validates the publisher's signature to verify that it is published by a publisher that this system trusts, unpacks the package and installs it according to the current install policy, which may be performed at some later scheduled time. Par 49, If so, then step 320 validates the publisher's signature to verify that it is published by a publisher that this system trusts, unpacks the package and installs it according to the current install policy, which may be performed at some later scheduled time.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the signed data is encrypted using a digital signature scheme, wherein the processing circuitry is further configured to decrypt the signed data using a digital signature scheme, as conceptually seen from the teaching of Reus, into that of Shell, Sood and Nozue because this modification can help authenticate the target device for the intended firmware to be installed.
As per Claim 13, none of Shell, Sood and Nozue specifically teaches, however Reus teaches of the device of claim 12, wherein the signed data is encrypted using a digital signature scheme, wherein the processing circuitry is further configured to decrypt the signed data using a digital signature scheme. (Par 8, A recipient of the content caches it in anticipation of future use, receives the key sometime after the key release moment, and uses the key to decrypt the encrypted content into useable content.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the signed data is encrypted using a digital signature scheme, wherein the processing circuitry is further configured to decrypt the signed data using a digital signature scheme, as conceptually seen from the teaching of Reus, into that of Shell, Sood and Nozue because this modification can help authenticate the target device for the intended firmware to be installed.
11. Claims 7, 14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Shell (US PGPub 20050132357), in view of Sood (US PGPub 20220019667), in view of Ebert (US PGPub 20060064488), and further in view of Reus (US PGPub 20090252325).
As per Claim 7, neither Shell nor Sood specifically teaches, however Ebert teaches of the method of claim 1, wherein the package further comprises data indicative of at least one of a type of the firmware or (Par 66, Using this method, the key pair used for application signature is at least partially determined by the application particulars, and a different key pair may be used for a different type of application.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to data indicative of at least one of a type of the firmware as conceptually seen from the teaching of Ebert, into that of Shell and Sood because this modification can help authenticate the target device for the intended firmware to be installed.
None of Shell, Sood and Ebert specifically teaches, however Reus teaches of a configuration of the device. (Par 6, The content may be signed for verification purposes, and may be associated with metadata, such as to provide a hash value for further validation. For content comprising software updates, the metadata may include applicability information as to which type or types of systems the software update applies. Some or all of the metadata may be encrypted.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add data indicative of a configuration of the device as conceptually seen from the teaching of Reus, into that of Shell, Sood and Ebert because this modification can help authenticate the target device for the intended firmware to be installed.
As per Claim 14, neither Shell nor Sood specifically teaches, however Ebert teaches of the device of claim 8, wherein the package further comprises data indicative of at least one of a type of the firmware or … wherein the processing circuitry is further configured to receive a package comprising data indicative of at least one of a type of the firmware (Par 66, Using this method, the key pair used for application signature is at least partially determined by the application particulars, and a different key pair may be used for a different type of application.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to data indicative of at least one of a type of the firmware or … wherein the processing circuitry is further configured to receive a package comprising data indicative of at least one of a type of the firmware, as conceptually seen from the teaching of Ebert, into that of Shell and Sood because this modification can help authenticate the target device for the intended firmware to be installed.
None of Shell, Sood and Ebert specifically teaches, however Reus teaches of a configuration of the device, wherein the processing circuitry is further configured to receive a package comprising data indicative of at least one of [a type of the firmware or] a configuration of the device. (Par 6, The content may be signed for verification purposes, and may be associated with metadata, such as to provide a hash value for further validation. For content comprising software updates, the metadata may include applicability information as to which type or types of systems the software update applies. Some or all of the metadata may be encrypted.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add a configuration of the device, wherein the processing circuitry is further configured to receive a package comprising data indicative of at least one of [a type of the firmware or] a configuration of the device, as conceptually seen from the teaching of Reus, into that of Shell, Sood and Ebert because this modification can help authenticate the target device for the intended firmware to be installed.
As per Claim 20, neither Shell nor Sood specifically teaches, however Ebert teaches of the method of claim 15, wherein each of the at least one package further comprises data indicative of at least one of a type of the firmware or (Par 66, Using this method, the key pair used for application signature is at least partially determined by the application particulars, and a different key pair may be used for a different type of application.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to data indicative of at least one of a type of the firmware as conceptually seen from the teaching of Ebert, into that of Shell and Sood because this modification can help authenticate the target device for the intended firmware to be installed.
None of Shell, Sood and Ebert specifically teaches, however Reus teaches of a configuration of the device. (Par 6, The content may be signed for verification purposes, and may be associated with metadata, such as to provide a hash value for further validation. For content comprising software updates, the metadata may include applicability information as to which type or types of systems the software update applies. Some or all of the metadata may be encrypted.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add data indicative of a configuration of the device as conceptually seen from the teaching of Reus, into that of Shell, Sood and Ebert because this modification can help authenticate the target device for the intended firmware to be installed.
12. Claims 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Shell (US PGPub 20050132357), in view of Lau (US PGPub 20150121070).
As per Claim 15. Shell teaches of a method for distributing firmware to be installed on the device to at least one target device, the method comprising: determining for each of the at least one target device, a respective target unique device identification; (Par 44, In order to provide an appropriately keyed image, e.g., on demand, the image to be keyed is initially stored on a server 220. Through a secure mechanism, the UUID [unique device identification] of the device is communicated to the server, where it is then used to key the image. For example, the device owner can securely send the UUID when requesting an update, or the device manufacturer can maintain an internal database of UUIDs that are authorized to receive an update. Par 13, In one implementation, a package is keyed based on the package and a universally-unique identifier (UUID) associated with the device. The UUID allows packages to be keyed to a single device or a class of devices, depending on whether the UUID corresponds to a device or a class of devices.)
retrieving each respective target unique device identification from each respective target unique device (Par 44, In order to provide an appropriately keyed image, e.g., on demand, the image to be keyed is initially stored on a server 220. Through a secure mechanism, the UUID [unique device identification] of the device is communicated to the server, where it is then used to key the image. For example, the device owner can securely send the UUID when requesting an update, or the device manufacturer can maintain an internal database of UUIDs that are authorized to receive an update. Par 13, In one implementation, a package is keyed based on the package and a universally-unique identifier (UUID) associated with the device. The UUID allows packages to be keyed to a single device or a class of devices, depending on whether the UUID corresponds to a device or a class of devices.)
generating at least one package for the at least one target device, each of the at least one package comprising respective signed data based on the at least one target unique device identification and on the firmware; and (Par 36, As generally represented in FIG. 2, a package 202 (e.g., a .CAB compressed file) in an image has a signature array 204 including least one signature, which is used to verify that the package 202 is a valid image (e.g., update) for the device. A second signature, or countersignature, if present, is the key 206 that is used to associate that update to a particular device. This countersignature generally will be referred to herein as the "key." The provider that originally made the package and the entity that has the key information on the device (e.g., an OEM) can key a package. The key 206 is constructed using information about the package and the device ID, as described below. Par 37, As indicated above, the keying process relies on the ability to uniquely identify the device for which the image is to be keyed. To this end, each device needs to provide a universally-unique identifier (UUID) 208. Par 52, As represented in FIG. 2, each package such as the package 202 may be keyed, that is, have an associated countersignature 206, which as described above is a hash of the device ID and a hash of the package-related data (e.g., the manifest file that contains the package information). Par 17, A manifest file that accompanies the package to describe the contents of that package to the system, by including a package identifier, version number and a list of files in the package, provides the package-related data for hashing.)
communicating the at least one package [and the firmware] to at least the at least one target device. (Fig. 2 and Par 43, In order to provide an appropriately keyed image, e.g., on demand, the image [package] to be keyed is initially stored on a server 220. Through a secure mechanism, the UUID of the device is communicated to the server, where it is then used to key the image. For example, the device owner can securely send the UUID when requesting an update, or the device manufacturer can maintain an internal database of UUIDs that are authorized to receive an update. Par 17, In one implementation, the package data that is used in the hash corresponds to a description of the package that is maintained on the device after package installation. Par 18, Once the package is keyed and obtained at the device, the device determines whether it has a demand for keying on the package being installed.)
hashing a combination of the firmware to be installed on the device and a respective one of the at least one target unique device identification (Par 17, In one implementation, the package data that is used in the hash corresponds to a description of the package [software/firmware] that is maintained on the device after package installation. Par 44, Once the server 220 obtains the device UUID and has access to the image, in one implementation the server applies a hashing algorithm to both entities to obtain (e.g., via concatenation) a single entity, which in turn can be signed. This can be represented essentially as a formula: Sign.sub.key(Hash(Hash(pkg data).vertline.Hash(device ID))). Par 46, As a result, the manifest file 230 serves as an excellent entity for hashing in the above formula (as the package data [firmware]) to represent the package, which as described above is then combined with the hash of the device UUID, with the result signed. Par 52, As represented in FIG. 2, each package such as the package 202 may be keyed, that is, have an associated countersignature 206, which as described above is a hash of the device ID and a hash of the package-related data (e.g., the manifest file that contains the package information). Par 17, A manifest file that accompanies the package to describe the contents of that package to the system, by including a package identifier, version number and a list of files [firmware] in the package, provides the package-related data for hashing. Par 46, The package data that is used in the hash can be based on an actual hash of the package contents. The manifest file 230 includes the package identifier, version number and a list of files in the package. It’s obvious that the hash is based on the firmware information (package data, i.e. package id, version number or etc.) and the device ID as combination.)
Shell does not specifically teaches, however Lau teaches of communicating the at least one package and the firmware to be installed on the device to at least the at least one target device. (Par 19, Additionally, this device-specific piece of information can be transmitted, along with a unique identifier for the device (e.g., an identification number or code unique to the device), to a server system that maintains a repository of authorized firmware packages for the device. When the server system subsequently sends a firmware package for installation on the device, the server system could embed the device-specific information within the firmware package.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add communicating the at least one package and the firmware to at least the at least one target device, as conceptually seen from the teaching of Lau, into that of Shell because this modification can help authenticate the target device for the intended firmware to be installed.
As per Claim 16, Shell does not specifically teaches, however Lau teaches of the method of claim 15, wherein each of the at least one package further comprises the firmware. (Par 19, Additionally, this device-specific piece of information can be transmitted, along with a unique identifier for the device (e.g., an identification number or code unique to the device), to a server system that maintains a repository of authorized firmware packages for the device. When the server system subsequently sends a firmware package for installation on the device, the server system could embed the device-specific information within the firmware package. A bootloader of the device could then check the information embedded in the firmware package with the information written on the device in order to determine whether the firmware package is an authorized firmware package. For example, the bootloader could determine the firmware package is authorized if the tokens match, and otherwise could determine that the firmware is an unauthorized firmware package. Par 23, As discussed above, one embodiment provides a firmware package embedded with a token, and the bootloader component 125 of the device 110 can compare the embedded token with a previously written token on the device (e.g., written to the protected memory 115 of the device at the time of manufacture) to determine whether the firmware package is authorized for installation on the device.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add each of the at least one package further comprises the firmware, as conceptually seen from the teaching of Reus, into that of Shell because this modification can help authenticate the target device for the intended firmware to be installed.
As per Claim 17, Shell further teaches of the method of claim 15, wherein: determining each respective target unique device identification comprises retrieving each respective target unique device identification from each respective target unique device; and (Par 44, In order to provide an appropriately keyed image, e.g., on demand, the image to be keyed is initially stored on a server 220. Through a secure mechanism, the UUID [unique device identification] of the device is communicated to the server, where it is then used to key the image. For example, the device owner can securely send the UUID when requesting an update, or the device manufacturer can maintain an internal database of UUIDs that are authorized to receive an update. Par 13, In one implementation, a package is keyed based on the package and a universally-unique identifier (UUID) associated with the device. The UUID allows packages to be keyed to a single device or a class of devices, depending on whether the UUID corresponds to a device or a class of devices.)
generating each of the at least one package comprises hashing a combination of the firmware and a respective one of the at least one target unique device identification. (Par 17, In one implementation, the package data that is used in the hash corresponds to a description of the package [software/firmware] that is maintained on the device after package installation. Par 44, Once the server 220 obtains the device UUID and has access to the image, in one implementation the server applies a hashing algorithm to both entities to obtain (e.g., via concatenation) a single entity, which in turn can be signed. This can be represented essentially as a formula: Sign.sub.key(Hash(Hash(pkg data).vertline.Hash(device ID))). Par 46, As a result, the manifest file 230 serves as an excellent entity for hashing in the above formula (as the package data [firmware]) to represent the package, which as described above is then combined with the hash of the device UUID, with the result signed. Par 52, As represented in FIG. 2, each package such as the package 202 may be keyed, that is, have an associated countersignature 206, which as described above is a hash of the device ID and a hash of the package-related data (e.g., the manifest file that contains the package information).)
13. Claims18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Shell (US PGPub 20050132357), in view of Lau (US PGPub 20150121070), and further in view of Reus (US PGPub 20090252325).
As per Claim 18, neither Shell nor Lau specifically teaches however Reus teaches of the method of claim 15, further comprising encrypting each of the at least one package. (Par 8, A recipient of the content caches it in anticipation of future use, receives the key sometime after the key release moment, and uses the key to decrypt the encrypted content into useable content. For software updates, metadata, which also may be decrypted, may be used to install the software update. Different and/or multiple keys may be received and used to decrypt different content. Par 49, If so, then step 320 validates the publisher's signature to verify that it is published by a publisher that this system trusts, unpacks the package and installs it according to the current install policy, which may be performed at some later scheduled time. Par 49, If so, then step 320 validates the publisher's signature to verify that it is published by a publisher that this system trusts, unpacks the package and installs it according to the current install policy, which may be performed at some later scheduled time. Par 17, In one aspect, content corresponds to one or more software update packages, which in general are finished and tested days or weeks prior to the release, and thereby are able to be pre-distributed to client systems in anticipation of use on a targeted future release date. At a release moment, e.g., the same instant worldwide regardless of a client's time zone, a key package is made available, by which clients may decrypt, install and use the software update packages.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add encrypting each of the at least one package, as conceptually seen from the teaching of Reus, into that of Shell, Sood and Nozue because this modification can help authenticate the target device and the package comprising the intended firmware to be installed.
As per Claim 19, neither Shell nor Lau specifically teaches however Reus teaches of the method of claim 18, wherein encrypting each of the at least one packages comprises encrypting each of the at least one packages using a digital signature scheme. (Par 8, A recipient of the content caches it in anticipation of future use, receives the key sometime after the key release moment, and uses the key to decrypt the encrypted content into useable content.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add encrypting each of the at least one packages using a digital signature scheme, as conceptually seen from the teaching of Reus, into that of Shell, Sood and Nozue because this modification can help authenticate the target device and the package comprising the intended firmware to be installed.
Response to Arguments
14. Applicant's arguments with respect to claims 1, 8 and 15 and their dependent claims have been fully considered but they are not persuasive.
Regarding the first argument of the remark on page 7 that Shell teaches of a description of the software or firmware such as manifest file with a package identifier, version information/number and a list of files but not the firmware to be installed on the device and Sood teaches nothing on hashing and Nozue only discloses has of the device id and information, the examiner would like to point out that Shell teaches of the firmware/software information, version number as part of the package data and also in par 13 with the UUID, the keying process is able to securely associate the device's UUID with an image, such that an installer verifier and/or boot-time verifier can ensure that the keying is appropriate for that device, based on the UUID. The installer and/or boot-time verifier will then allow or disallow the image update/boot depending on whether the device is authorized for the image. Par 18, Once the package is keyed and obtained at the device, the device determines whether it has a demand for keying on the package being installed. The demand may be from within the package or may be a demand from another, previously installed package. Par 39, With such a UUID, the keying process is able to securely associate the device's UUID with an image, such that an installer verifier and/or boot-time verifier can ensure that the keying is appropriate for the device's UUID. Thus, the examiner maintains that the prior art, Shell teaches of the amendment.
Regarding the second argument of the remark on page 8 that taking hash of firmware application file and a device identification is not a task that could be performed in a human mind, the examiner would like to point out that the examiner would like to point out that with BRI hashing also can be done with a simpler algorithm as follows without requiring a computational power. So as target IDs and firmware IDs can be generated as in human-readable form. Thus, the examiner still determines the proposed amendment to be subject to 101 Abstract Idea. Assign numerical values to letters: A=1, B=2, C=3, and so on, up to Z=26. Take the input word: Let's use "HELLO". Convert letters to numbers: H = 8 E = 5 L = 12 L = 12 O = 15 Sum the numerical values: 8 + 5 + 12 + 12 + 15 = 52. In this simple example, the hash of "HELLO" is 52.
Conclusion
THIS ACTION IS MADE FINAL. 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 JAE UK JEON whose telephone number is (571)270-3649. The examiner can normally be reached 9am-6pm. 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, Chat Do can be reached at 571-272-3721. 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.
/JAE U JEON/Primary Examiner, Art Unit 2193