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 .
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. 202111331483.X, filed on November 11, 2021.
Claim Interpretation
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
a request sending module configured to send in claim 6
a first comparison module configured to receive in claim 6
a first determination module configured to determine in claim 6
a first encryption module configured to encrypt in claim 6
a first sending module configured to send in claim 6
a second encryption module configured to receive in claim 11
a second sending module configured to send in claim 11
a first receiving module configured to receive in claim 11
a second comparison module configured to run in claim 11
a first decryption module configured to decrypt in claim11
a second determination module configured to determine in claim 11
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-15 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 6 recites limitations of claim 6 are configured to perform the Internet-of-Things device identity authentication method according to claim 1, however limitation of claim 6 are substantially already recited and “perform the Internet-of-Things device identity authentication method according to claim 1” render claim 6 ambiguous.
Claim 11 recites limitations of claim 11 are configured to perform the Internet-of-Things device identity authentication method according to claim 7, however limitation of claim 11 are substantially already recited and “perform the Internet-of-Things device identity authentication method according to claim 7” render claim 11 ambiguous.
The term “it is” in claims 1, 2, 4, 6, 7 and 11, is a pronoun term which renders the claim indefinite. The pronoun term “it is” render the limitation ambiguous because there is not clear and definite antecedent element is referred to without ambiguity. Claims 3, 5, 8-10 and 12-15 failed to remedy the deficiencies of their respective independent claims and therefore rendered indefinite.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 14-15 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because claims 14 and 15 are directed to “a computer-readable storage medium comprising : a stored computer program” and they cover signal per se which is considered non-statutory subject matter under 35 USC 101.
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.
Claims 1-15 are rejected under 35 U.S.C. 103 as being unpatentable over Jeon et al. (US 20170344407 A1 ---hereinafter--- Jeon) in view of GUO et al. (US 20170090909 A1 ---hereinafter --- “GUO”) in further view of POCHUEV et al. (US US 20200145409 A1 ---hereinafter—"POCHUEV”)
As per claim 1: Jeon discloses an Internet-of-Things device authentication method ( [0120] An Internet of things (IoT) may refer to a network between things using wired/wireless communication. Thus, an IoT described in the present disclosure may be used as various terms such as an IoT network system, a ubiquitous sensor network (USN) communication system, a machine type communication (MTC) system, a machine oriented communication (MOC) system, a machine to machine (M2M) communication system, or a device to device (D2D) communication system. An IoT network system described in the present disclosure may be configured with an IoT device, an access point (AP), a gateway, a communication network, a server, and the like) performed by a client device and comprising:
sending authentication request information to a server device, so that the server device receives the authentication request information ([0031] The REE 110 may be implemented in hardware, software, and/or firmware and may be a platform of providing a normal execution environment. The REE 110 may include at least one application 112, an authentication agent 114, and a normal kernel 116. As used herein, an “application” (such as the application 112, the authentication agent 114, and/or the trusted application 122. [0032] The application 112 may be driven or executed on the REE 110 to provide a service to a user of the electronic device 10. If the application 112 wants to securely manage a file via a virtual file system 128 of the TEE 140, it may send a request to process the file to the authentication agent 114. For example, the application 112 may access the secure storage 200 (e.g., write/read a file in/from the secure storage 200) via the authentication agent 114),
generates a first authentication code according to a preset first encryption algorithm, and sends the first authentication code to the client device ([0034] Further, the authentication agent 114 may be implemented to assist with an operation of authenticating the application 112 on the TEE 120. The application agent 114 may generate a digital fingerprint of the application 112 and may send the generated digital fingerprint to the trusted application 122. In some embodiments, the digital fingerprint may be generated using a unique value of the application 112, for example, a code value of or corresponding to a code area of the application 112. In some embodiments, the digital fingerprint may be a value in which the code value is encrypted using a variety of methods (e.g., a hash scheme, a symmetric key scheme, an asymmetric key scheme, and the like). [0035] In some embodiments, the authentication agent 114 may generate a digital fingerprint on a periodic basis. In another embodiment, the authentication agent 114 may generate a digital fingerprint on an aperiodic basis. For example, the authentication agent 114 may generate a digital fingerprint in response to a random number),
receiving the first authentication code (0055] In step S140, the authentication agent 114 may generate a message authentication code (MAC) key for integrity of enrolling and transmitting a digital fingerprint. In some embodiments, the MAC key may be generated based on a MAC chaining scheme);
generating a second authentication code according to the first encryption algorithm, and comparing the second authentication code with the first authentication code ([0059] FIG. 3 is a drawing illustrating a process of generating a message authentication (MAC) key according to a MAC chaining scheme in an authentication agent 114 according to some embodiments. Referring to FIG. 3, an initial MAC key may be configured with least significant bits (LSB) and most significant bits (MSB). Herein, the LSB may be a first code value (HMAC code 1), and the MSB may be a second code value (HMAC code 2));
determining that an authentication of the server device is valid when it is determined that the second authentication code is consistent with the first authentication code ([0041] The TEE 120 may be configured with hardware, software, and/or firmware, and may be a secure platform for providing a level or layer of protection from a software attack on the REE 110. The TEE 120 may control access/execution of a sensitive application that may need to be separated from the REE 110, that is, the at least one trusted application 122. [0042-0044] Further, the TEE 120 may include the at least one trusted application 122 and a secure kernel 126. The trusted application 122 may be a secure application (e.g., a digital rights management (DRM) application, a bank application, a payment application, a cooperate application, and the like) that has greater security needs, driven or executed in the TEE 120. For example, the trusted application 122 may include a preloaded application, a native application, and/or a third party application. Particularly, the trusted application 122 may determine whether to authenticate an REE client. In some embodiments, the trusted application 122 may enroll and verify a digital fingerprint for authenticating the application 112 in response to a request of the authentication agent 114 of the REE 110. [0060] If the initial MAC key is generated, the second code value (HMAC code 2) may be updated to the first code value (HMAC code 1). Subsequently, the authentication agent 114 may generate a hash-based message authentication code (HMAC) value using the hash data that was encrypted in FIG. 2. In other words, the HMAC value may be a value resulting from operations in which the encrypted hash data is hashed by a hash algorithm. The generated HMAC value may be updated to the second code value (HMAC code 2). The authentication agent 114 may generate a MAC key through the above-mentioned process. Simultaneously or in parallel in some embodiments, a trusted application 122 of FIG. 1 may generate a MAC key in the same manner to verify the generated MAC key. [0064] In step S220, the trusted application 122 may generate a MAC key to check integrity of the received digital fingerprint. In some embodiments, the MAC key may be generated by a MAC chaining scheme. In step S230, the trusted application 122 may verify the MAC key of the digital fingerprint by comparing the generated MAC key with the MAC key of the digital fingerprint. If the generated MAC key is identical to the MAC key of the digital fingerprint, the trusted application 122 may determine that the digital fingerprint received from the authentication agent 114 has integrity);
encrypting the first authentication code according to a preset second encryption algorithm to generate a third authentication code after it is determined that the identity of the server device is valid (0050] The electronic device 10 according to some embodiments may perform an operation of authenticating the application 112. The authentication agent 114 of the REE 110 may generate a digital fingerprint by encrypting a reverse code value (e.g., a process identifier (PID)) of a code area of the application 112 using a PID of the application 112 and may send the generated digital fingerprint to the trusted application 122 of the TEE 120. Subsequently, the trusted application 122 may authenticate the application 112 by comparing the sent digital fingerprint with an enrolled digital fingerprint);
sending the third authentication code and a preconfigured encrypted data packet to the server device, so that the server device runs the second encryption algorithm reversely to decrypt the received third authentication code to generate a fourth authentication code ([0065] In step S240, the trusted application 122 may decrypt encrypted hash data of the digital fingerprint based on an encryption algorithm. In some embodiments, the trusted application 122 may decrypt encrypted hash data included in the digital fingerprint using a private key of the trusted application 122. In another embodiment, the trusted application 122 may encrypt the encrypted hash data included in the digital fingerprint using a secret key shared with the authentication agent 114);
compares the fourth authentication code with the first authentication code, decrypts the received encrypted data packet to obtain device authentication information when it is determined that the fourth authentication code is consistent with the first authentication code ([0076] The trusted application 122 may generate a MAC value of the encrypted hash data (RSA Enc[Hash+Time]) using the same master key which is promised or provided to the TZ Dev. 117 to verify a MAC in the digital fingerprint received from the TZ Dev. 117. In step S360, the trusted application 122 may determine whether the generated MAC value is identical to a MAC value received from the TZ Dev. 117. [0077] If the generated MAC value is identical to the MAC value received from the TZ Dev. 117, in step S370, the trusted application 122 may perform RSA decryption of the encrypted hash data (RSA_Enc[Hash +Time]) using its private key).
determines that an authentication of the client device is valid when it is determined that the device authentication information is consistent with device-specific information of the client device ([0088] FIG. 6B is a process flow diagram illustrating a method for persistent authentication of encrypted communications between the network devices of FIG. 6A according to various embodiments. At operation 660, the first network device (Device A) generates a one-time password (OTP) usable to seed a CIMAC signature. The first network device may also seed, using the one-time password, generation of a first hash value including a first contextual-identifier message authentication code (CIMAC) signature. The first CIMAC, for example, encodes, within the first hash value, a first contextual hash-based message authentication code (HMAC) and a public key. [0089] At operation 662, the first network device (Device A) transmits, to the second network device, first encrypted data signed with the first CIMAC signature, where the first CIMAC signature is to provide authentication of the first encrypted data. In one embodiment, the first CIMAC signature is appended to the first encrypted data. In another embodiment, the second CIAC signature is encoded within or combined with the encrypted data before being transmitted).
Jeon does not explicitly disclose generates an image authentication code according to a preset image generation algorithm and the first authentication code and sends the image authentication code to the client device; or receiving the image authentication code and running the image generation algorithm reversely to decrypt the image authentication code to obtain the first authentication code. GUO, in analogous art however, discloses generates an image authentication code according to a preset image generation algorithm and the first authentication code and sends the image authentication code to the client device; or receiving the image authentication code and running the image generation algorithm reversely to decrypt the image authentication code to obtain the first authentication code ([0026] Authentication of a patch code image is performed by a processor. Authentication is verification that the patch code image originates from a trusted source (e.g., based on a root-of-trust). For example, the patch code image may be authenticated based on patch information in the patch code image and on a public key stored in the SoC by the chip manufacturer. The patch code image may be authenticated during execution of PBL firmware. [0045] The processor 140 may be configured to authenticate the code images 14 during execution of PBL firmware. The code images 14 may include the patch code image 15. In other words, the PBL firmware may include authentication instructions which, when executed by the processor 140, determine an authentication status of each code image. In order to authenticate the code images 14, the processor 140 may generate a calculated digest of the patch code image using a SHA or other cryptographic hash algorithm. The SHA or other cryptographic hash algorithm used by the processor 140 is the same SHA or other cryptographic hash algorithm that was used by the server associated with the trusted source of the code image 14. The processor 140 may decrypt the digital signature using the public key 30 to generate a decrypted digest. In an example, the processor 140 may decrypt the digital signature of the patch code image 15 using the dedicated public key. The processor 140 may compare the calculated digest with the decrypted digest to determine the authentication status of the code image 14. An authentication status for the code image 14 of authenticated indicates equality between the calculated digest and the decrypted digest. The authenticated authentication status may indicate that the code image 14 and/or the patch code image 15 is unmodified since it was signed by the trusted source, and that the signer, and no one else, intentionally performed the signature operation. Conversely, inequality between the calculated digest and the decrypted digest indicates an authentication status of unauthenticated for the code image 14 and/or the patch code image 15. The unauthenticated authentication status may indicate that the signature in the code image is an untrusted signature. Further, authentication may verify the integrity of the patch code image. If the code image 14 originates from the trusted source, as indicated by the authenticated authentication status, then it is unlikely that an entity other than the trusted source has tampered with or altered the code image 14. Verification of the integrity of the code image 14 may indicate that the code image 14 has not been tampered with or altered subsequent to generation of the digest and the digital signature. Conversely, the unauthenticated code image may have been altered and/or provided to the SoC 105 by a hacker or other entity with malicious intent). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the authentication code disclosed by Jeon to include generates an image authentication code according to a preset image generation algorithm and the first authentication code and sends the image authentication code to the client device; or receiving the image authentication code and running the image generation algorithm reversely to decrypt the image authentication code to obtain the first authentication code. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide a method for securely writing patch code to the memory of the SoC includes determining an authentication status of a patch code image, if the authentication status of the patch code image is authenticated, then writing the patch code from the patch code image into a one-time programmable (OTP) memory and generating a system reset signal, and if the authentication status of the patch code image is unauthenticated, then booting the SoC without writing the patch code from the patch code image into the OTP memory as suggested by GUO ([0012]).
Jeon and GUO do not explicitly disclose the authentication request in the authentication method is an identity authentication and the determined authentication of the server is identity of the server and the determined authentication of the device is identity of the device. POCHUEV, in analogous art however, discloses the authentication request in the authentication method is an identity authentication and the determined authentication of the server is identity of the server and the determined authentication of the device is identity of the device ([0066] FIG. 5 describes messages exchanged between the entities in the exchange that combines use cases of authentication and issuance of the domain-specific identity to the device. [0067] FIG. 5 is a flow diagram illustrating a sequence 1000 of messages exchanged between the IoT device 110, the RoT authentication service 104, the device provisioning service 106, and the IoT application service 108 for authentication and identity services according to one embodiment. The sequence 1000 may start with the provisioning policy server 116 sending a redirect response 1001 to the IoT device 110 in response to an initial request from the IoT device 110 (not illustrated). The redirect response 1001 may include a nonce, a timestamp (or other time information, and a hash of a message authentication code (HMAC or hmac), including a pre-shared key (PSK) and a nonce/time. The PSK can be shared between the provisioning policy server 116 and the authentication policy server 112. The nonce may be a random value selected by the provisioning policy server 116. [0068] In response to the redirect response 1001, the IoT device 110 generates an authentication request 1003 to send to the authentication policy server 112. The authentication request 1003 may include a RoT identifier (rotID), which is an immutable root-of-trust ID), a checksum, the nonce, the time stamp, and the HMAC. The checksum (chksum) is a checksum computed over a derived root key (rotKey), rotID, the nonce, and the timestamp. The rotKey is derived using a key tree. The key tree has a base key and a path. The path defines how the base key is transformed into the rotKey. The checksum can be computing using hash1 and hash2 primitives from a CM core of the IoT device 110. Similarly, the MAC can be a combination of the hash1 and hash2 primitives. More generally, any keyed MAC (HMAC) can perform a similar operation. The idea is that rather than sharing the actual unique core (RoT) key with the backend, a solution-specific key can be derived any time the backend interacts with the core. This derivation is done by hashing the unique core key with a constant. [0070] The authentication policy server 112 receives the authentication request 1003 and sends the authentication request 1003 along to the RoT identity server 114 as authentication request 1005. The RoT identity server 114 responds with an authentication response 1007, the authentication response 1007 including the nonce, the timestamp, and the HMAC. The authentication policy server 112 receives the authentication response 1007. Assuming the authentication response 1007 validates the authentication request 1005, the authentication policy server 112 provides an identity token (idToken) 1009 to the IoT device 110. The idToken may include the nonce, the timestamp, and the HMAC, as well as claims. The attestation data (attData) may contain the data from the device describing its attributes, which is attested to by the root-of-trust within the device. [0075] FIG. 6 is a flow diagram illustrating various operations performed on each of the relevant components for the sequence 1000 of FIG. 5 according to one embodiment. The provisioning policy server 116 at block 1101, generates the nonce, records the timestamp and creates HMAC using PSK, and sends the initial response (redirect response). The application at the IoT device 110 at block 1103 sends the nonce and timestamp to a buffer of the CM core and executes a sequence to obtain the checksum result. The application, at the block 1103, also creates and sends the authentication request to the RoT identity server 114 via the authentication policy server 112. At block 1105, the RoT identity server 114 verifies the HMAC, looks up the derived rotKey using rotID, and verifies the checksum of the authentication request. The RoT identity server 114 also creates, signs, and sends the authentication response back to the authentication policy server 112. At block 1107, the authentication policy server 112 verifies the authentication request. Upon verification, the authentication policy server 112 creates, signs, and sends the identity token to the application at the IoT device 110. The application at the IoT device 110 sends the identity token back to the provisioning policy server 116, which at block 1109, verifies the signature on the identity token and checks the time against its own policy. The provisioning policy server 116 also performs the provisioning operations. [0077] In another embodiment, in addition to authenticating the device, RoT identity server 114 can provide unique identities to the devices that are valid only within the context of a particular IoT application. This may be useful when the devices need to be tracked, while preserving privacy of the device/user by not allowing the device to use the same ID across multiple services. Additionally, the protocol must not leak immutable IDs. These IDs are typically provided in the “sub” field of the ID Token, returned by the RoT authentication service 104. Instead, in another embodiment, in the privacy preserving configuration, an alias representing the device in this particular application is used in the “sub” field of the ID Token [0108]).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations disclosed by Jeon and GUO to include the authentication request in the authentication method is an identity authentication and the determined authentication of the server is identity of the server and the determined authentication of the device is identity of the device. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide establishment of device credentials in an Internet of Things (IoT) infrastructure which is directed to unifying secure credential establishment regardless of the endpoint type, thus addressing the challenge of a great diversity among IoT devices to address a challenge of initial trusted enrollment of the IoT endpoints into a secure infrastructure, which allows secure communications between the devices in the IoT environment as suggested by POCHUEV ([0025]).
As per claim 2: Jeon and GUO in view of POCHUEV disclose the Internet-of-Things device identity authentication method according to claim 1, wherein the running the preset image generation algorithm reversely to decrypt the image authentication code to obtain the first authentication code comprises: reading information of the image authentication code, and deleting preset interference information, so as to obtain a decimal numerical value; converting the decimal numerical value into a binary numerical value, and performing a reverse bitwise cyclic operation on the binary numerical value, so as to obtain an initial binary numerical value; and performing a decimal conversion on the initial binary numerical value to obtain the first authentication code (GUO [0026] Authentication of a patch code image is performed by a processor. Authentication is verification that the patch code image originates from a trusted source (e.g., based on a root-of-trust). For example, the patch code image may be authenticated based on patch information in the patch code image and on a public key stored in the SoC by the chip manufacturer. The patch code image may be authenticated during execution of PBL firmware.)
As per claim 3: Jeon and GUO in view of POCHUEV disclose the Internet-of-Things device identity authentication method according to claim 1, wherein the generating the second authentication code according to the first encryption algorithm comprises:
generating a time period number according to a preset dynamic time interval and obtained current time of the client device (POCHUEV [0070] The authentication policy server 112 receives the authentication request 1003 and sends the authentication request 1003 along to the RoT identity server 114 as authentication request 1005. The RoT identity server 114 responds with an authentication response 1007, the authentication response 1007 including the nonce, the timestamp, and the HMAC. The authentication policy server 112 receives the authentication response 1007. Assuming the authentication response 1007 validates the authentication request 1005, the authentication policy server 112 provides an identity token (idToken) 1009 to the IoT device 110. The idToken may include the nonce, the timestamp, and the HMAC, as well as claims);
performing computation on the current time of the client device, the time period number, and the dynamic time interval to obtain an initial second authentication code (POCHUEV [0070] The idToken may include the nonce, the timestamp, and the HMAC, as well as claims. The attestation data (attData) may contain the data from the device describing its attributes, which is attested to by the root-of-trust within the device. Claims, on the other hand, are attributes of the device, which are provided and attested to by the backend (RoT Authentication Server). The claims would typically include attData, but may have other information, such as how many times this device has been authenticated by the backend in the last hour. The nonce, timestamp, HMAC, and claims may be digitally signed. The IoT device 110 submits the identity token 1009 to the provisioning policy server 116 as the identity token 1011. In one embodiment, the following is an example identity token); and
processing the initial second authentication code according to a preset number of authentication code bits, so as to obtain the second authentication code (POCHUEV [0075] FIG. 6 is a flow diagram illustrating various operations performed on each of the relevant components for the sequence 1000 of FIG. 5 according to one embodiment. The provisioning policy server 116 at block 1101, generates the nonce, records the timestamp and creates HMAC using PSK, and sends the initial response (redirect response).
As per claim 4: Jeon and GUO in view of POCHUEV disclose the Internet-of-Things device identity authentication method according to claim 3, further comprising:
updating the time period number to a time period number of a previous time when it is determined for a first time that the second authentication code is inconsistent with the first authentication code, and returning to the step of performing the computation on the current time of the client device, the time period number, and the dynamic time interval to obtain the initial second authentication code, thereby obtaining an updated second authentication code; and comparing the updated second authentication code with the first authentication code (POCHUEV [0067] FIG. 5 is a flow diagram illustrating a sequence 1000 of messages exchanged between the IoT device 110, the RoT authentication service 104, the device provisioning service 106, and the IoT application service 108 for authentication and identity services according to one embodiment. The sequence 1000 may start with the provisioning policy server 116 sending a redirect response 1001 to the IoT device 110 in response to an initial request from the IoT device 110 (not illustrated). The redirect response 1001 may include a nonce, a timestamp (or other time information, and a hash of a message authentication code (HMAC or hmac), including a pre-shared key (PSK) and a nonce/time. The PSK can be shared between the provisioning policy server 116 and the authentication policy server 112. The nonce may be a random value selected by the provisioning policy server 116).
As per claim 5: Jeon and GUO in view of POCHUEV disclose the Internet-of-Things device identity authentication method according to claim 1, wherein the encrypting the first authentication code according to the preset second encryption algorithm to generate the third authentication code comprises: adding a preset encryption number to the first authentication code to generate the third authentication code (POCHUEV [0058] In some embodiments, the IoT device 110 includes a cryptographic manager (CM) core and may be referred to as a CM core device. The CM core may operate as a proxy for the device. The CM Core is a hardware core capable of executing a set of commands. Sequences may be digitally signed and/or carry other cryptographic demonstrations of validity (e.g. a MAC), which the CM Core can verify to confirm the original and validity of the sequences).
As per claim 6 it is directed to an Internet-of-Things device identity authentication apparatus, wherein the apparatus is disposed in a client device and is configured to perform the Internet-of-Things device identity authentication method according to claim 1 and therefore claim 6 is rejected with the same rationale given above to reject claim 1.
As per claims 7-13, they are directed to an Internet-of-Things device identity authentication method, performed by a server device corresponding to limitations of claims 1-6 respectively and therefore claims 7-13 are rejected with the same rationale given above to reject corresponding limitations of claims 1-6 respectively.
As per claims 14-15, a computer-readable storage medium, comprising: a stored computer program, wherein when the computer program is run, a device where the computer-readable storage medium is located is controlled to perform the Internet-of-Things device identity authentication method according to claim 1 and 7 respectively and therefore claims 14-15 are rejected with the same rationale given above to reject corresponding limitations of claims 1 and 7 respectively.
Conclusion
The prior arts made of record and not relied upon are considered pertinent to applicant's disclosure. See the notice of reference cited in form PTO-892 for additional prior arts.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TECHANE GERGISO whose telephone number is (571)272-3784. The examiner can normally be reached 9:30am to 6:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, LINGLAN EDWARDS can be reached at (571) 270-5440. 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.
/TECHANE GERGISO/ Primary Examiner, Art Unit 2408