3DETAILED ACTION
Notice of Pre-AIA or AIA Status
This Office Action is in response to the amendment filed on 10/23/2025 having claims 1-20 pending.
Claims 1-20 are examined and being considered on the merits.
Claims 1-2, 8-11, 16 and 20 have been amended, and all other claims are previously presented.
Claims 1-20 are submitted for examination.
Claims 1-20 are pending.
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 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.
Response to Arguments
Applicant’s amendment filed on October 23, 2025 has claims 1-2, 8-11, 16 and 20 have been amended, and all other claims are previously presented.
Applicant’s remark, filed on October 23, 2025 at page 9, indicates, “Claims 8 and 9 stand currently objected to as failing to because of alleged informalities. Applicant has amended the objected-to language from claims 8 and 9. Accordingly, withdrawal of this objection is respectfully requested.
Applicant’s argument has been considered and is found persuasive. Therefore, the previous claim objection is withdrawn.
Applicant’s remark, filed on October 23, 2025 at pages 9-10, indicates, “The Office Action acknowledges on page 21 that Loladia and Schmidt do not teach a DASP engine that stores key-value pairs in a data store, each key-value pair including a hash of a device identifier and a hash of a device protection code. Hence, Loladia and Schmidt do not disclose or suggest storing a plurality of key-value pairs in a data store, each key-value pair including a first hash of a device identifier of a first loT device of one or more loT devices and a second hash of a device protection code, as in claim 1. Thus, claim 1 is allowable, as are claims 5, 6, and 8 that depend therefrom.”
Applicant’s argument has been considered and is found persuasive. Therefore, the previous prior-art rejection is withdrawn. However, Applicant’s amendment necessitates a new ground of rejection.
Accordingly, a new ground of rejection based on the previously applied prior-art by Hughes et al. (US 2023/0185892) hereinafter Hughes, has been applied to the amendment. Specifically, Hughes discloses a method for using a pin value or one time password to protect a device from unauthorized access. The method further applies a hash function to a set of pins that are related to a device identifier. Specifically, at Parag. [0017], describes computing a hash value from input vales; wherein the input values are the pin and a device identifier. In addition, Hughes discloses that the hash function is applied to a plurality of Pins. Thus, Examiner interprets the hashed pin as the second device hashed protection code (key) and the hashed device identifier as the value to form a key-value pair that is stored at the memory. Therefore, it is submitted that the specific teaching of Hughes clearly discloses the feature limitation, “store a plurality of key-value pairs in a data store, each key-value pair including a first hash of a device identifier of a first loT device of the one or more loT devices and a second hash of the device protection code”. Please refer to the detailed prior-art rejection below.
In view of the above, Examiner respectfully submits that the new combination of Loladia, Schmidt and Hughes would render the claimed limitations of the amended independent claim 1 obvious.
Regarding amended independent claims 11 and 20, has been considered and is addressed based on the same rationale presented for the amended independent claim 1.
Applicant’s remark, filed on October 23, 2025 at page 10, indicates, “Claims 2 and 3 depend from claim 1. As explained above, the cited portions of Loladia and Schmidt do not disclose the features of claim 1. The cited portions of Perez Lafuente fail to remedy the deficiencies of Loladia and Schmidt. More particularly, the cited portions of Perez Lafuente fail to disclose or suggest storing a plurality of key-value pairs in a data store, each key-value pair including a first hash of a device identifier of a first loT device of one or more loT devices and a second hash of a device protection code, as in claim 1. Perez Lafuente discloses a system that stores a hash value of an activation ACS code and hash value of a device ID. See Perez Lafuente, paragraph [0112]. The activation code is associated with an authentication service (e.g., not an loT device). See Perez Lafuente, paragraph [0315]. As such, the hypothetical combination of Loladia, Schmidt, and Perez Lafuente fail to disclose or suggest storing a plurality of key-value pairs in a data store, each key-value pair including a first hash of a device identifier of a first loT device of one or more loT devices and a second hash of a device protection code, as in claim 1. Thus, claims 2 and 3 are allowable at least by virtue of their dependence from claim 1.”
Applicant’s argument has been considered and is found persuasive. Therefore, the previous prior-art rejection is withdrawn. However, Applicant’s argument is moot based on the newly applied reference by Hughes.
Same rationale is applied to dependent claims 16 and 19.
Regarding dependent claims 4,7, 9-10, 12-14 please refer to the aforementioned response, which addresses how the new combination of prior-art references by Loladia, Schmidt, and Hughes would render the claimed limitations obvious.
Claim Objections
Claims 1 is objected to because of the following informalities: Claim 1 recites, “… including a first hash of a device identifier of a first IoT device of the one or more IoT devices …” However, it should recite “including [[a]] the first hash of a device identifier of a first IoT device of the one or more IoT devices ...” for a proper antecedent basis. Appropriate correction is required
Claim 8 is objected to because of the following informalities: Claim 8 recites, “The system of claim 1, wherein the DASP engine comprises part of to the IoT platform.” However, it should recite “The system of claim 1, wherein the DASP engine comprises part of [[to]] the IoT platform.” Appropriate correction is required.
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 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-3, 5-6, 8, 11 and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Loladia et al. (US 10,382,203) hereinafter Loladia in view of Schmidt (US 2020/0021586) and further in view of Hughes et al. (US 2023/0185892) hereinafter Hughes.
As per Claim 1, Loladia teaches a system for secure Internet-of-Things (IoT) communications (Loladia, Col. 4, lines 41-45; “FIG. 1 illustrates an example computing environment 100 which includes a cloud computing platform 115 hosting an Internet of Things (IoT) service 120 used to pair IoT devices 110 with a service managed client ID and a companion application, according to one embodiment.” … Col. 6, lines 15-18; “Communication sessions established with the device gateway 230 may be protected from eavesdropping using secure communications protocols, such as secure sockets layer (SSL) or transport layer security (TLS).”) comprising:
an IoT platform (Loladia, Col. 4, lines 20-23; “FIG . 1 illustrates an example cloud computing platform hosting an Internet of Things (IoT) service used to pair IoT devices with a service managed client ID and a companion application, according to one embodiment.” … Col. 4, lines 51-53; “In this example, the computing platform 115 includes an IoT service 120, cloud services 125 and IoT applications 130.”);
one or more IoT devices communicatively coupled to the IoT platform (Loladia, Col. 4, lines 20-23; “FIG . 1 illustrates an example cloud computing platform hosting an Internet of Things (IoT) service used to pair IoT devices with a service managed client ID and a companion application, according to one embodiment.” … Col. 4, lines 41-45; “FIG. 1 illustrates an example computing environment 100 which includes a cloud computing platform 115 hosting an Internet of Things (IoT) service 120 used to pair IoT devices 110 with a service managed client ID and a companion application, according to one embodiment.”);
a Device Authorized Security Protocol (DASP) engine communicatively coupled to the one or more IoT devices and the IoT platform (Loladia, Col. 4, lines 20-23; “FIG . 1 illustrates an example cloud computing platform hosting an Internet of Things (IoT) service (i.e., DASP engine) used to pair IoT devices with a service managed client ID and a companion application, according to one embodiment.” … Col. 4, lines 41-45; “FIG. 1 illustrates an example computing environment 100 which includes a cloud computing platform 115 hosting an Internet of Things (IoT) service 120 (i.e., DASP engine) used to pair IoT devices 110 with a service managed client ID and a companion application, according to one embodiment.”);
wherein the DASP engine is configured to: generate an encrypted device protection code based on information associated with a first IoT device of the one or more IoT devices (Loladia, Col. 7, lines 54-63; “… the IoT device 110 sends a message to the device gateway 230 requesting a token. The token request message may include a device identifier (device ID) associated with the device 110 and the client ID received from the companion app 225. In turn, the IoT service 120 (i.e., DASP) generates a token to send back to the IoT device. The token may include the device ID, user ID a timestamp and authorization code. In one embodiment, the IoT service 120 encrypts the token using a key provided by the key service 240.”);
[store a plurality of key-value pairs in a data store, each key-value pair includinq a first hash of a device identifier of a first loT device of the one or more loT devices and a second hash of the device protection code]; and
provide the encrypted device protection code to the first IoT device (Loladia, Col. 7, lines 54-63; “… the IoT device 110 sends a message to the device gateway 230 requesting a token. The token request message may include a device identifier (device ID) associated with the device 110 and the client ID received from the companion app 225. In turn, the IoT service 120 (i.e., DASP) generates a token to send back to the IoT device. The token may include the device ID, user ID a timestamp and authorization code. In one embodiment, the IoT service 120 encrypts the token using a key provided by the key service 240.”);
wherein the first IoT device is configured to generate a communication that contains the encrypted device protection code and transmit the communication to the IoT platform (Loladia, Col. 8, lines 4-13; “Once the IoT service 120 encrypts a token, the pairing process continues by sending the encrypted token to the IoT device 110 (as a response to the token request message). The IoT device sends the token back to the companion app 225 over the local communication link. To complete the pairing process, the companion app 225 sends the copy of the encrypted token back …, along with the client ID assigned to the companion app and the device ID of the IoT device 110. The IoT service 120 can decrypt the token …”); and
wherein the IoT platform (Loladia, Col. 4, lines 20-23; “FIG . 1 illustrates an example cloud computing platform hosting an Internet of Things (IoT) service used to pair IoT devices with a service managed client ID and a companion application, according to one embodiment.” … Col. 4, lines 51-53; “In this example, the computing platform 115 includes an IoT service 120, cloud services 125 and IoT applications 130.”) is configured to
[in response to receiving the communication, extract the encrypted device protection code from the communication and provide the encrypted device protection code to the DASP engine for authentication of the first IoT device,
in response to the DASP engine authenticating the first IoT device, process the communication, and
in response to the DASP engine not authenticating the first IoT device, prevent processing of the communication].
Loladia does not expressly teaches:
store a plurality of key-value pairs in a data store, each key-value pair includinq a first hash of a device identifier of a first loT device of the one or more loT devices and a second hash of the device protection code;
in response to receiving the communication, extract the encrypted device protection code from the communication and provide the encrypted device protection code to the DASP engine for authentication of the first IoT device,
in response to receiving the communication, extract the encrypted device protection code from the communication and provide the encrypted device protection code to the DASP engine for authentication of the first IoT device,
in response to the DASP engine authenticating the first IoT device, process the communication, and
in response to the DASP engine not authenticating the first IoT device, prevent processing of the communication.
However, Schmidt teaches:
in response to receiving the communication, extract the encrypted device protection code from the communication and provide the encrypted device protection code to the DASP engine for authentication of the first IoT device (Schmidt, Parag. [0020]; “The Gateway 202 (i.e., IoT platform) can collaborate with a dedicated server, which may the Trust Broker node 204 (i.e., DASP), to establish desired trust relationships to ensure authenticity and secure device communication, concurrently. In some cases, the IoT Gateway 202 may control the communication of the IoT device 206 as long as the device is unauthenticated, so that it cannot do harm to the IoT system 200. The trust broker 204 may then authenticate the device 206, and release a secret for communication protection to the gateway 202. The device 206, the gateway 202, and other authorized entities may use this secret to protect communication to and from the device 206 on the application layer. Additionally, the trust broker 204 may release credentials to the device 206, which can be used to authenticate the device to an IoT service.” … Parag. [0024]; “The CONNECT request may be accompanied by (or may include) an authentication credential, such as an identifier/password pair or a cryptographic token for example.” … Parag. [0037]; “the gateway 202 (i.e., iot platform) may forward the connection request to the trust broker 204 (i.e., DASP) using various routing rule and proxy mechanisms. In an example, messages, for instance every message from the IoT device 206, are first captured and processed by the gateway 202 and then, if appropriate, forwarded to the trust broker.”)
in response to the DASP engine authenticating the first IoT device, process the communication (Schmidt, Parag. [0020]; “The Gateway 202 (i.e., IoT platform) can collaborate with a dedicated server, which may the Trust Broker node 204 (i.e., DASP), to establish desired trust relationships to ensure authenticity and secure device communication, concurrently. In some cases, the IoT Gateway 202 may control the communication of the IoT device 206 as long as the device is unauthenticated, so that it cannot do harm to the IoT system 200. The trust broker 204 may then authenticate the device 206, and release a secret for communication protection to the gateway 202. The device 206, the gateway 202, and other authorized entities may use this secret to protect communication to and from the device 206 on the application layer. Additionally, the trust broker 204 may release credentials to the device 206, which can be used to authenticate the device to an IoT service.” … Parag. [0024]; “The CONNECT request may be accompanied by (or may include) an authentication credential, such as an identifier/password pair or a cryptographic token for example.”), and
in response to the DASP engine not authenticating the first IoT device, prevent processing of the communication (Schmidt, Parag. [0020]; “The Gateway 202 (i.e., IoT platform) can collaborate with a dedicated server, which may the Trust Broker node 204 (i.e., DASP), to establish desired trust relationships to ensure authenticity and secure device communication, concurrently. In some cases, the IoT Gateway 202 may control the communication of the IoT device 206 as long as the device is unauthenticated, so that it cannot do harm to the IoT system 200. The trust broker 204 may then authenticate the device 206, and release a secret for communication protection to the gateway 202. The device 206, the gateway 202, and other authorized entities may use this secret to protect communication to and from the device 206 on the application layer. Additionally, the trust broker 204 may release credentials to the device 206, which can be used to authenticate the device to an IoT service.” … Parag. [0024]; “The CONNECT request may be accompanied by (or may include) an authentication credential, such as an identifier/password pair or a cryptographic token for example.”).
Loladia and Schmidt are from similar field of technology. Prior to the instant application’s effective filling date, there was a need for a provide secure communications in an IoT system.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Schmidt system into Loladia system, with a motivation to provide an IoT device authentication based on device credentials and a token/access token provided by an IoT broker (i.e., DASP) (Schmidt, Parag. [0020]).
The combination of Loladia and Schmidt does not expressly teach:
store a plurality of key-value pairs in a data store, each key-value pair includinq a first hash of a device identifier of a first loT device of the one or more loT devices and a second hash of the device protection code;
However, Hughes teaches:
store a plurality of key-value pairs in a data store, each key-value pair includinq a first hash of a device identifier of a first loT device of the one or more loT devices and a second hash of the device protection code (Hughes, Parag. [0017]; “In some implementations, computing the hash value may include applying a key derivation function to an input that represents a combination of the first PIN (i.e., protection code) and a device identifier (i.e., key-value pair combination) associated with the computing device.” … Parag. [0022]; “In some implementations, the method may further include: for each of the plurality of authorized PINs: computing a hash value based on the authorized PIN (Examiner submits that a hash will be computed for a first, second, third, PIN); encrypting the random key that is stored in association with the authorized PIN using the computed hash value; and storing, in the memory, the encrypted random key.” … Parag. [0054]; “For each of the first PINs, the computing device obtains a unique value that is based on the PIN, in operation 306. In at least some embodiments, the unique value represents a derived value that is obtained based on combining the PIN with some other static information. The static information may, for example, be device identifying information for the computing device, such as a device serial number.”).
Loladia, Schmidt and Hughes are from similar field of technology. Prior to the instant application’s effective filling date, there was a need for a provide secure communications in an IoT system.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hughes system into Loladia-Schmidt system, with a motivation to provide hash table comprising stored key-value pairs of device identifiers and protection codes (PIN value) (Hughes, Parag. [0017] and [0022]).
As per claim 2, the combination of Loladia, Schmidt and Hughes teach the system of claim 1. Loladia teaches further comprising a data store coupled to the DASP engine (Loladia, Col. 4, lines 20-23; “FIG . 1 illustrates an example cloud computing platform hosting an Internet of Things (IoT) service (i.e., DASP engine) used to pair IoT devices with a service managed client ID and a companion application, according to one embodiment.” … Col. 4, lines 41-45; “FIG. 1 illustrates an example computing environment 100 which includes a cloud computing platform 115 hosting an Internet of Things (IoT) service 120 (i.e., DASP engine) used to pair IoT devices 110 with a service managed client ID and a companion application, according to one embodiment.” … Col. 6, lines 5-8; “The IoT service 120 includes a device gateway 220, a message broker 231, IoT device shadows 233, IoT device registry 235, a rules engine 237, a security and identity manager 239, and a key service 240.” … Col. 6, lines 45-49; “The device registry 235 generally provides a device identity service within the IoT service 120. The device registry 25 stores an identifier for each device 110 and tracks device metadata, such as the attributes and capabilities of each IoT device 110.” Examiner submits that the IoT registry (i.e., data store) is part of the IoT service (i.e., DASP), therefore the registry is coupled to the DASP.)
As per claim 3, the combination of Loladia, Schmidt and Hughes teach the system of claim 2. Loladia teaches wherein the DASP engine is configured to authenticate (Loladia, Col. 4, lines 41-45; “FIG. 1 illustrates an example computing environment 100 which includes a cloud computing platform 115 hosting an Internet of Things (IoT) service 120 (i.e., DASP engine) used to pair IoT devices 110 with a service managed client ID and a companion application, according to one embodiment.” … Col. 7, lines 22-29; “In one embodiment, the identity manager 239 may assign a distinct client identifier (client ID) to each entity registered with the IoT service 120. The client ID within the IoT service 120 may correspond to a 25 user-identity authenticated by a third-party login service (e.g., an oauth service provided by social media services) when that user accesses the IOT service using the companion app 225.”)
In addition, Hughes teaches:
a received device identifier hash and a received device protection code hash by matching the received device identifier hash and the received device protection code hash to a corresponding key-value pair in the data store (Hughes, Parag. [0017]; “In some implementations, computing the hash value may include applying a key derivation function to an input that represents a combination of the first PIN (i.e., protection code) and a device identifier (i.e., key-value pair combination) associated with the computing device.” … Parag. [0022]; “In some implementations, the method may further include: for each of the plurality of authorized PINs: computing a hash value based on the authorized PIN (Examiner submits that a hash will be computed for a first, second, third, PIN); encrypting the random key that is stored in association with the authorized PIN using the computed hash value; and storing, in the memory, the encrypted random key.” … Parag. [0054]; “For each of the first PINs, the computing device obtains a unique value that is based on the PIN, in operation 306. In at least some embodiments, the unique value represents a derived value that is obtained based on combining the PIN with some other static information. The static information may, for example, be device identifying information for the computing device, such as a device serial number.”).
As per claim 5, the combination of Loladia, Schmidt and Hughes teaches the system of claim 1, Loladia further teaches wherein the DASP engine is configured to periodically generate a new device protection code for the first IoT device (Loladia, Col. 3, lines 53-61; “In response, the IoT service generates and encrypts a token to send to the IoT device over the second communication link. Note, the keys used to encrypt/decrypt the token may be held privately by the IoT service — meaning that the companion application, IoT device, user, or device manufacturer cannot recover the contents of the encrypted token. The token itself may store an authorization code identifying a policy to apply to the IoT device, a timestamp indicating a validity period of the token” … Col. 7, lines 60-67; “The token may include the device ID, user ID, a timestamp and an authorization code. In one embodiment, the IoT service 120 encrypts the token using a key provided by the key service 240. The particular key is generally known only to the IoT service 120. Further, the key service 240 may generate and store a distinct encryption key for each client ID, i.e., for each distinct user. Such encryption keys may have a relatively limited validity period (e.g., 24 hours).” … Col. 9, lines 21-23; “a pairing token 340 generated by the IoT service may have a short-lived validity period (e.g. a few minutes) as needed to complete the pairing process.” Examiner submits that a new token is required to be generated periodically once the timestamp of a current token expires (i.e., exceeds the validity period)).
As per claim 6, the combination of Loladia, Schmidt and Hughes teach the system of claim 5. Loladia further teaches wherein the DASP engine is configured to generate new device protection codes for the first IoT device at predetermined intervals (Loladia, Col. 3, lines 53-61; “In response, the IoT service generates and encrypts a token to send to the IoT device over the second communication link. Note, the keys used to encrypt/decrypt the token may be held privately by the IoT service — meaning that the companion application, IoT device, user, or device manufacturer cannot recover the contents of the encrypted token. The token itself may store an authorization code identifying a policy to apply to the IoT device, a timestamp indicating a validity period of the token” … Col. 7, lines 60-67; “The token may include the device ID, user ID, a timestamp and an authorization code. In one embodiment, the IoT service 120 encrypts the token using a key provided by the key service 240. The particular key is generally known only to the IoT service 120. Further, the key service 240 may generate and store a distinct encryption key for each client ID, i.e., for each distinct user. Such encryption keys may have a relatively limited validity period (e.g., 24 hours).” … Col. 9, lines 21-23; “a pairing token 340 generated by the IoT service may have a short-lived validity period (e.g. a few minutes) as needed to complete the pairing process.” Examiner submits that a new token is required to be generated at a predetermined intervals whenever the timestamp of a current token expires (i.e., exceeds the validity period)).
As per claim 8, the combination of Loladia, Schmidt and Hughes teach the system of claim 1. Loladia further teaches wherein the DASP engine comprises part of to the IoT platform (Loladia, Col. 4, lines 20-23; “FIG . 1 illustrates an example cloud computing platform hosting an Internet of Things (IoT) service used to pair IoT devices with a service managed client ID and a companion application, according to one embodiment.”).
As per claim 11, Loladia teaches a method for secure Internet-of-Things (IoT) communications (Loladia, Col. 4, lines 41-45; “FIG. 1 illustrates an example computing environment 100 which includes a cloud computing platform 115 hosting an Internet of Things (IoT) service 120 used to pair IoT devices 110 with a service managed client ID and a companion application, according to one embodiment.” … Col. 6, lines 15-18; “Communication sessions established with the device gateway 230 may be protected from eavesdropping using secure communications protocols, such as secure sockets layer (SSL) or transport layer security (TLS).”) comprising:
providing device information for a first IoT device to a Device Authorized Security Protocol (DASP) engine (Loladia, Col. 7, lines 54-63; “… the IoT device 110 sends a message to the device gateway 230 requesting a token. The token request message may include a device identifier (device ID) associated with the device 110 and the client ID received from the companion app 225. In turn, the IoT service 120 (i.e., DASP) generates a token to send back to the IoT device. The token may include the device ID, user ID a timestamp and authorization code. In one embodiment, the IoT service 120 encrypts the token using a key provided by the key service 240.”);
generating, at the DASP engine, a device protection code based on the provided device information (Loladia, Col. 7, lines 54-63; “… the IoT device 110 sends a message to the device gateway 230 requesting a token. The token request message may include a device identifier (device ID) associated with the device 110 and the client ID received from the companion app 225. In turn, the IoT service 120 (i.e., DASP) generates a token to send back to the IoT device. The token may include the device ID, user ID a timestamp and authorization code. In one embodiment, the IoT service 120 encrypts the token using a key provided by the key service 240.”);
[storing a plurality of key-value pairs in a data store, each key-value pair includinq a first hash of a device identifier of a first loT device and a second hash of the device protection code];
encrypting, by the DASP engine, the device protection code (Loladia, Col. 7, lines 54-63; “… the IoT device 110 sends a message to the device gateway 230 requesting a token. The token request message may include a device identifier (device ID) associated with the device 110 and the client ID received from the companion app 225. In turn, the IoT service 120 (i.e., DASP) generates a token to send back to the IoT device. The token may include the device ID, user ID a timestamp and authorization code. In one embodiment, the IoT service 120 encrypts the token using a key provided by the key service 240.”);
providing, by the DASP engine, the encrypted device protection code to the first IoT device (Loladia, Col. 7, lines 54-63; “… the IoT device 110 sends a message to the device gateway 230 requesting a token. The token request message may include a device identifier (device ID) associated with the device 110 and the client ID received from the companion app 225. In turn, the IoT service 120 (i.e., DASP) generates a token to send back to the IoT device. The token may include the device ID, user ID a timestamp and authorization code. In one embodiment, the IoT service 120 encrypts the token using a key provided by the key service 240.”);
generating, by the first IoT device, a communication containing the encrypted device protection code in a body of the communication (Loladia, Col. 8, lines 4-13; “Once the IoT service 120 encrypts a token, the pairing process continues by sending the encrypted token to the IoT device 110 (as a response to the token request message). The IoT device sends the token back to the companion app 225 over the local communication link. To complete the pairing process, the companion app 225 sends the copy of the encrypted token back …, along with the client ID assigned to the companion app and the device ID of the IoT device 110. The IoT service 120 can decrypt the token …”);
transmitting the communication to a recipient device (Loladia, Col. 8, lines 4-13; “Once the IoT service 120 encrypts a token, the pairing process continues by sending the encrypted token to the IoT device 110 (as a response to the token request message). The IoT device sends the token back to the companion app 225 over the local communication link. To complete the pairing process, the companion app 225 sends the copy of the encrypted token back …, along with the client ID assigned to the companion app and the device ID of the IoT device 110. The IoT service 120 can decrypt the token …”);
[extracting, by the recipient device, the encrypted device protection code from the communication;
providing, by the recipient device, the encrypted device protection code to the DASP engine with an identifier of the first IoT device;
authenticating, by the DASP engine, the first IoT device using the encrypted device protection code;
providing, by the DASP engine, an authentication result to the recipient device; and
processing, by the recipient device, the communication if the authentication result authenticates the first IoT device and preventing processing of the communication if the authentication result does not authenticate the first IoT device.]
Loladia does not expressly teaches:
storing a plurality of key-value pairs in a data store, each key-value pair includinq a first hash of a device identifier of a first loT device and a second hash of the device protection code;
extracting, by the recipient device, the encrypted device protection code from the communication;
providing, by the recipient device, the encrypted device protection code to the DASP engine with an identifier of the first IoT device;
authenticating, by the DASP engine, the first IoT device using the encrypted device protection code;
providing, by the DASP engine, an authentication result to the recipient device; and
processing, by the recipient device, the communication if the authentication result authenticates the first IoT device and preventing processing of the communication if the authentication result does not authenticate the first IoT device.
However, Schmidt teaches:
extracting, by the recipient device, the encrypted device protection code from the communication (Schmidt, Parag. [0020]; “The Gateway 202 (i.e., IoT platform) can collaborate with a dedicated server, which may the Trust Broker node 204 (i.e., DASP), to establish desired trust relationships to ensure authenticity and secure device communication, concurrently. In some cases, the IoT Gateway 202 may control the communication of the IoT device 206 as long as the device is unauthenticated, so that it cannot do harm to the IoT system 200. The trust broker 204 may then authenticate the device 206, and release a secret for communication protection to the gateway 202. The device 206, the gateway 202, and other authorized entities may use this secret to protect communication to and from the device 206 on the application layer. Additionally, the trust broker 204 may release credentials to the device 206, which can be used to authenticate the device to an IoT service.” … Parag. [0024]; “The CONNECT request may be accompanied by (or may include) an authentication credential, such as an identifier/password pair or a cryptographic token for example.” … Parag. [0037]; “the gateway 202 (i.e., iot platform) may forward the connection request to the trust broker 204 (i.e., DASP) using various routing rule and proxy mechanisms. In an example, messages, for instance every message from the IoT device 206, are first captured and processed by the gateway 202 and then, if appropriate, forwarded to the trust broker.”);
providing, by the recipient device, the encrypted device protection code to the DASP engine with an identifier of the first IoT device (Schmidt, Parag. [0020]; “The Gateway 202 (i.e., IoT platform) can collaborate with a dedicated server, which may the Trust Broker node 204 (i.e., DASP), to establish desired trust relationships to ensure authenticity and secure device communication, concurrently. In some cases, the IoT Gateway 202 may control the communication of the IoT device 206 as long as the device is unauthenticated, so that it cannot do harm to the IoT system 200. The trust broker 204 may then authenticate the device 206, and release a secret for communication protection to the gateway 202. The device 206, the gateway 202, and other authorized entities may use this secret to protect communication to and from the device 206 on the application layer. Additionally, the trust broker 204 may release credentials to the device 206, which can be used to authenticate the device to an IoT service.” … Parag. [0024]; “The CONNECT request may be accompanied by (or may include) an authentication credential, such as an identifier/password pair or a cryptographic token for example.” … Parag. [0037]; “the gateway 202 (i.e., iot platform) may forward the connection request to the trust broker 204 (i.e., DASP) using various routing rule and proxy mechanisms. In an example, messages, for instance every message from the IoT device 206, are first captured and processed by the gateway 202 and then, if appropriate, forwarded to the trust broker.”);
authenticating, by the DASP engine, the first IoT device using the encrypted device protection code (Schmidt, Parag. [0020]; “The Gateway 202 (i.e., IoT platform) can collaborate with a dedicated server, which may the Trust Broker node 204 (i.e., DASP), to establish desired trust relationships to ensure authenticity and secure device communication, concurrently. In some cases, the IoT Gateway 202 may control the communication of the IoT device 206 as long as the device is unauthenticated, so that it cannot do harm to the IoT system 200. The trust broker 204 may then authenticate the device 206, and release a secret for communication protection to the gateway 202. The device 206, the gateway 202, and other authorized entities may use this secret to protect communication to and from the device 206 on the application layer. Additionally, the trust broker 204 may release credentials to the device 206, which can be used to authenticate the device to an IoT service.” … Parag. [0024]; “The CONNECT request may be accompanied by (or may include) an authentication credential, such as an identifier/password pair or a cryptographic token for example.” … Parag. [0037]; “the gateway 202 (i.e., iot platform) may forward the connection request to the trust broker 204 (i.e., DASP) using various routing rule and proxy mechanisms. In an example, messages, for instance every message from the IoT device 206, are first captured and processed by the gateway 202 and then, if appropriate, forwarded to the trust broker.”);
providing, by the DASP engine, an authentication result to the recipient device (Schmidt, Parag. [0020]; “The Gateway 202 (i.e., IoT platform) can collaborate with a dedicated server, which may the Trust Broker node 204 (i.e., DASP), to establish desired trust relationships to ensure authenticity and secure device communication, concurrently. In some cases, the IoT Gateway 202 may control the communication of the IoT device 206 as long as the device is unauthenticated, so that it cannot do harm to the IoT system 200. The trust broker 204 may then authenticate the device 206, and release a secret for communication protection to the gateway 202 (Examiner submits that the authentication result is delivered when the trust broker release a secret to the gateway in order to perform secure communications with the IoT device). The device 206, the gateway 202, and other authorized entities may use this secret to protect communication to and from the device 206 on the application layer. Additionally, the trust broker 204 may release credentials to the device 206, which can be used to authenticate the device to an IoT service.”); and
processing, by the recipient device, the communication if the authentication result authenticates the first IoT device and preventing processing of the communication if the authentication result does not authenticate the first IoT device (Schmidt, Parag. [0020]; “The Gateway 202 (i.e., IoT platform) can collaborate with a dedicated server, which may the Trust Broker node 204 (i.e., DASP), to establish desired trust relationships to ensure authenticity and secure device communication, concurrently. In some cases, the IoT Gateway 202 may control the communication of the IoT device 206 as long as the device is unauthenticated, so that it cannot do harm to the IoT system 200. The trust broker 204 may then authenticate the device 206, and release a secret for communication protection to the gateway 202. The device 206, the gateway 202, and other authorized entities may use this secret to protect communication to and from the device 206 on the application layer. Additionally, the trust broker 204 may release credentials to the device 206, which can be used to authenticate the device to an IoT service.” … Parag. [0024]; “The CONNECT request may be accompanied by (or may include) an authentication credential, such as an identifier/password pair or a cryptographic token for example.”).
Loladia and Schmidt are from similar field of technology. Prior to the instant application’s effective filling date, there was a need for a provide secure communications in an IoT system.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Schmidt system into Loladia system, with a motivation to provide an IoT device authentication based on device credentials and a token/access token provided by an IoT broker (i.e., DASP) (Schmidt, Parag. [0020]).
The combination of Loladia and Schmidt does not expressly teach:
storing a plurality of key-value pairs in a data store, each key-value pair includinq a first hash of a device identifier of a first loT device and a second hash of the device protection code;
However Hughes teaches:
storing a plurality of key-value pairs in a data store, each key-value pair includinq a first hash of a device identifier of a first loT device and a second hash of the device protection code (Hughes, Parag. [0017]; “In some implementations, computing the hash value may include applying a key derivation function to an input that represents a combination of the first PIN (i.e., protection code) and a device identifier (i.e., key-value pair combination) associated with the computing device.” … Parag. [0022]; “In some implementations, the method may further include: for each of the plurality of authorized PINs: computing a hash value based on the authorized PIN (Examiner submits that a hash will be computed for a first, second, third, PIN); encrypting the random key that is stored in association with the authorized PIN using the computed hash value; and storing, in the memory, the encrypted random key.” … Parag. [0054]; “For each of the first PINs, the computing device obtains a unique value that is based on the PIN, in operation 306. In at least some embodiments, the unique value represents a derived value that is obtained based on combining the PIN with some other static information. The static information may, for example, be device identifying information for the computing device, such as a device serial number.”).
Loladia Schmidt and Hughes are from similar field of technology. Prior to the instant application’s effective filling date, there was a need for a provide secure communications in an IoT system.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hughes system into Loladia-Schmidt- system, with a motivation to provide hash table comprising stored key-value pairs of device identifiers and protection codes (PIN value) (Hughes, Parag. [0017] and [0022]).
As per claim 15, the combination of Loladia, Schmidt and Hughes teach the method of claim 11, wherein the recipient device comprises an IoT platform (Loladia, Col. 2, lines 20-23; “FIG . 1 illustrates an example cloud computing platform hosting an Internet of Things (IoT) service used to pair IoT devices with a service managed client ID and a companion application, according to one embodiment.” … Col. 4, lines 51-53; “In this example, the computing platform 115 includes an IoT service 120, cloud services 125 and IoT applications 130.”).
As per claim 16, the combination of Loladia, Schmidt and Hughes teach the method of claim 11. Hughes teaches wherein the storing of the plurality of the key-value pairs is performed by the DASP engine (Hughes, Parag. [0017]; “In some implementations, computing the hash value may include applying a key derivation function to an input that represents a combination of the first PIN (i.e., protection code) and a device identifier (i.e., key-value pair combination) associated with the computing device.” … Parag. [0022]; “In some implementations, the method may further include: for each of the plurality of authorized PINs: computing a hash value based on the authorized PIN (Examiner submits that a hash will be computed for a first, second, third, PIN); encrypting the random key that is stored in association with the authorized PIN using the computed hash value; and storing, in the memory, the encrypted random key.” … Parag. [0054]; “For each of the first PINs, the computing device obtains a unique value that is based on the PIN, in operation 306. In at least some embodiments, the unique value represents a derived value that is obtained based on combining the PIN with some other static information. The static information may, for example, be device identifying information for the computing device, such as a device serial number.”).
As per claim 17, the rejection of claim 11 is incorporated. In addition, it is method claim that recites similar features as recited in claim 5. Therefore, claim 17 is rejected using the same rationale as applied to claim 5.
As per claim 18, the rejection of claim 17 is incorporated. In addition, it is method claim that recites similar features as claimed on claim 6. Therefore, claim 18 is rejected using the same rationale as applied to claim 6.
As per claim 19, the rejection of claim 11 is incorporated. In addition, it is method claim that recites similar features as claimed on claim 3. Therefore, claim 19 is rejected using the same rationale as applied to claim 3.
As per claim 20, it is a computer program product reciting similar limitations as claimed by independent claim 11. Therefore, claim 20 is rejected using the same rationale applied to independent claim 11.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Loladia et al. (US 10,382,203) hereinafter Loladia in view of Schmidt (US 2020/0021586) and Hughes et al. (US 2023/0185892) hereinafter Hughes as applied to claim 1, and further in view of Shiner et al. (US 2022/0132298) hereinafter Shiner.
As per claim 4, the combination of Loladia, Schmidt and Hughes teach the system of claim 1.
The combination of Loladia, Schmidt and Hughes does not expressly teach:
wherein generating the encrypted device protection code comprises generating a nonce and generating the device protection code using the nonce.
However, Shiner teaches:
wherein generating the encrypted device protection code comprises generating a nonce and generating the device protection code using the nonce (Shiner, Parag. [0268]; “The request 271 can include a cryptographic nonce 267. For example, the cryptographic nonce 267 can be generated by the security server 140 in response to a request from the client server 141, or generated by the client server 141 and shared with the security server 140 for the request 271. Alternatively, the memory device 130 may generate the cryptographic nonce 267 in response to the request 271 and provide a corresponding response 273 that includes a the cryptographic nonce 267.” … Parag. [0271]; “To protect the response 273 and/or the verification code 133 from security attacks (e.g., reuse of the response 273 and/or attempts to recover the secret key 137), the verification code 133 is generated for a message 131 that includes the unique identification 111, a counter value 265, and the cryptographic nonce 267.”).
Loladia, Schmidt, Hughes and Shiner are from similar field of technology. Prior to the instant application’s effective filling date, there was a need for a provide secure communications in an IoT system.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Shiner system into Loladia-Schmidt-Hughes system, with a motivation to provide a cryptographic technique to generate the protection code (token) (Shiner, Parag. [0268]).
Claims 7 and 12-14 are rejected under 35 U.S.C. 103 as being unpatentable over Loladia et al. (US 10,382,203) hereinafter Loladia in view of Schmidt (US 2020/0021586) and Hughes et al. (US 2023/0185892) hereinafter Hughes as applied to claim 1, and further in view of Mahaffey et al. (US 2017/0142090) hereinafter Mahaffey.
As per claim 7, the combination of Loladia, Schmidt and Hughes teach the system of claim 1.
The combination of Loladia, Schmidt and Hughes does not expressly teach:
wherein the IoT platform is configured to, in response to receiving the communication and prior to extracting the encrypted device protection code from the communication, verify a password provided by the IoT device with the communication.
However, Mahaffey teaches:
wherein the IoT platform is configured to, in response to receiving the communication and prior to extracting the encrypted device protection code from the communication, verify a password provided by the IoT device with the communication (Mahaffey, Parag. [0138-0139]; “In a further embodiment, the remote access authentication credential is generated using a special remote access password. At 1701, the user sets the remote access password on the device. At 1702, when the remote access password is set on the device, the device generates verification information and a “challenge' token and transmits them to the server. The verification information includes a random salt used for password verification and the result of hashing the password with the verification salt. The “challenge” token is a second random salt used to generate the authentication credential and not equal to the first salt. At 1703, the server stores the verification information and the “challenge” token.”).
Loladia, Schmidt, Hughes and Mahaffey are from similar field of technology. Prior to the instant application’s effective filling date, there was a need for a provide secure communications in an IoT system.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Mahaffey system into Loladia-Schmidt-Hughes system, with a motivation to provide identity verification by validating a password provided by the IoT device (Mahaffey, Parag. [0138]).
As per claim 12, the combination of Loladia, Schmidt and Hughes teach the method of claim 11. Schmidt further teaches:
[further comprising authenticating, by the recipient device, the first IoT device using a first, long-term authenticator], wherein the authenticating is performed by the recipient device independently of the DASP engine authenticating the first IoT device using the device protection code (Schmidt, Parag [0022]; “the IoT device 206 can be authenticated to the gateway (GW) 202 and key agreement can be achieved in “one go," which refers to messaging that both yields device authentication as an end result and results in agreement of a shared secret key between the device and a GW. The IoT system 200 can be protected against fake/spoofed devices early on, for example by the GW 202 controlling communication during an authentication stage. In the IoT system 200, according to an example embodiment, there is a separate trust system for flexible device to server authentication.”)
The combination of Loladia, Schmidt and Hughes does not expressly teach:
further comprising authenticating, by the recipient device, the first IoT device using a first, long-term authenticator, …
However, Mahaffey teaches:
further comprising authenticating, by the recipient device, the first IoT device using a first, long-term authenticator (Mahaffey, Parag. [0138-0139]; “In a further embodiment, the remote access authentication credential is generated using a special remote access password. At 1701, the user sets the remote access password on the device. At 1702, when the remote access password is set on the device, the device generates verification information and a “challenge' token and transmits them to the server (i.e., recipient device). The verification information includes a random salt used for password verification and the result of hashing the password with the verification salt. The “challenge” token is a second random salt used to generate the authentication credential and not equal to the first salt. At 1703, the server stores the verification information and the “challenge” token.”).
Loladia, Schmidt, Hughes and Mahaffey are from similar field of technology. Prior to the instant application’s effective filling date, there was a need for a provide secure communications in an IoT system.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Mahaffey system into Loladia-Schmidt-Hughes system, with a motivation to provide a method for multistage authentication of an IoT device by verifying the password prior to allow secured communications (Mahaffey, Parag. [0138]).
As per claim 13, the combination of Loladia, Schmidt, Hughes and Mahaffey teaches the method of claim 12. Mahaffey further teaches wherein the first, long-term authenticator comprises a password provided by the first IoT device to the recipient device (Mahaffey, Parag. [0138-0139]; “In a further embodiment, the remote access authentication credential is generated using a special remote access password. At 1701, the user sets the remote access password on the device. At 1702, when the remote access password is set on the device, the device generates verification information and a “challenge' token and transmits them to the server (i.e., recipient device). The verification information includes a random salt used for password verification and the result of hashing the password with the verification salt. The “challenge” token is a second random salt used to generate the authentication credential and not equal to the first salt. At 1703, the server stores the verification information and the “challenge” token.”).
As per claim 14, the combination of Loladia, Schmidt, Hughes and Mahaffey teaches the method of claim 12. Loladia further teaches wherein the encrypted device protection code comprises a short-term authenticator which is configured to expired in a predetermined period of time (Loladia, Col. 3, lines 53-61; “In response, the IoT service generates and encrypts a token to send to the IoT device over the second communication link. Note, the keys used to encrypt/decrypt the token may be held privately by the IoT service — meaning that the companion application, IoT device, user, or device manufacturer cannot recover the contents of the encrypted token. The token itself may store an authorization code identifying a policy to apply to the IoT device, a timestamp indicating a validity period of the token” … Col. 7, lines 60-67; “The token may include the device ID, user ID, a timestamp and an authorization code. In one embodiment, the IoT service 120 encrypts the token using a key provided by the key service 240. The particular key is generally known only to the IoT service 120. Further, the key service 240 may generate and store a distinct encryption key for each client ID, i.e., for each distinct user. Such encryption keys may have a relatively limited validity period (e.g., 24 hours).” … Col. 9, lines 21-23; “a pairing token 340 generated by the IoT service may have a short-lived validity period (e.g. a few minutes) as needed to complete the pairing process.”).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Loladia et al. (US 10,382,203) hereinafter Loladia in view of Schmidt (US 2020/0021586) and Hughes et al. (US 2023/0185892) hereinafter Hughes as applied to claim 1, and further in view of Jiang et al. (US 2022/0400118) hereinafter Jiang.
As per claim 9, the combination of Loladia, Schmidt and Hughes teach the system of claim 1. The combination of Loladia, Schmidt and Hughes does not expressly teach:
wherein the DASP engine is remote from the IoT platform.
However, Jiang teaches:
wherein the DASP engine is remote from the IoT platform (Jiang, Fig. 1 and Parag. [0024]; “Further, in some examples, the authentication server 104 (i.e., DASP engine) may be implemented as an independent server (i.e., located remotely) or may be part of a cloud.).
Loladia, Schmidt, Hughes and Jiang are from similar field of technology. Prior to the instant application’s effective filling date, there was a need for a provide secure communications in an IoT system.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Jiang system into Loladia-Schmidt-Hughes system, with a motivation to implement an Authentication Server (i.e., DASP engine) external to a cloud platform in order to provide access services to connected IoT devices (Jiang, Parag. [0024-0027]).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Loladia et al. (US 10,382,203) hereinafter Loladia in view of Schmidt (US 2020/0021586) and Hughes et al. (US 2023/0185892) hereinafter Hughes as applied to claim 1, and further in view of Haque et al. (US 2021/0067341) hereinafter Haque.
As per claim 10, the combination of Loladia, Schmidt and Hughes teaches the system of claim 1. Loladia further teaches the system comprising a second IoT device of the one or more IoT devices (Loladia, Col. 4, lines 41-45; “FIG. 1 illustrates an example computing environment 100 which includes a cloud computing platform 115 hosting an Internet of Things (IoT) service 120 used to pair IoT devices 110 with a service managed client ID and a companion application, according to one embodiment.”);
wherein the DASP engine (Loladia, Col. 2, lines 20-23; “FIG . 1 illustrates an example cloud computing platform hosting an Internet of Things (IoT) service (i.e., DASP engine) used to pair IoT devices with a service managed client ID and a companion application, according to one embodiment.” … Col. 4, lines 41-45; “FIG. 1 illustrates an example computing environment 100 which includes a cloud computing platform 115 hosting an Internet of Things (IoT) service 120 (i.e., DASP engine) used to pair IoT devices 110 with a service managed client ID and a companion application, according to one embodiment.”) is configured to
[generate a second encrypted device protection code based on information associated with the IoT platform], and
[provide the second encrypted device protection code to the IoT platform];
wherein the IoT platform is configured to generate a second communication that contains the second encrypted device protection code and transmit the second communication to the second IoT device (Schmidt, Parag. [0031]; “The trust broker 204 may publish the IoT service access token or the like under the same topic as described above. Thus, the gateway 202 may capture the PUBLISH message, and extract and store the service access token or the like. In some cases, the GW may replace the payload (e.g., service access token) in the PUBLISH message with some predetermined value (e.g., "register-OK: DEV-ID”. The payload may be encrypted with the key K, so as to define a modified PUBLISH message. The modified PUBLISH message may be forwarded to the device 206.”); and
wherein the second IoT device is configured to
in response to receiving the second communication, extract the second encrypted device protection code from the communication and provide the second encrypted device protection code to the DASP engine for authentication of the IoT platform (Schmidt, Parag. [0029]; “At 3, in accordance with the illustrated example, the device 206 creates authentication response data in response to the publish message from the trust broker 204. In an example, the device 206 encrypting the challenge value received from the trust broker 204 with a secret key that the device 206 shares with the trust broker 204. The device 206 may PUBLISH the authentication response to the trust broker 204 under the same topic under which the trust broker 204 published the authentication challenge. The device 206 may also derive a secret key K, for example, using the challenge value and its own secret.”),
in response to the DASP engine authenticating the IoT platform, process the second communication (Schmidt, Parag. [0020]; “The Gateway 202 (i.e., IoT platform) can collaborate with a dedicated server, which may the Trust Broker node 204 (i.e., DASP), to establish desired trust relationships to ensure authenticity and secure device communication, concurrently. In some cases, the IoT Gateway 202 may control the communication of the IoT device 206 as long as the device is unauthenticated, so that it cannot do harm to the IoT system 200. The trust broker 204 may then authenticate the device 206, and release a secret for communication protection to the gateway 202. The device 206, the gateway 202, and other authorized entities may use this secret to protect communication to and from the device 206 on the application layer. Additionally, the trust broker 204 may release credentials to the device 206, which can be used to authenticate the device to an IoT service.” … Parag. [0024]; “The CONNECT request may be accompanied by (or may include) an authentication credential, such as an identifier/password pair or a cryptographic token for example.”), and
in response to the DASP engine not authenticating the IoT platform, prevent processing of the second communication (Schmidt, Parag. [0020]; “The Gateway 202 (i.e., IoT platform) can collaborate with a dedicated server, which may the Trust Broker node 204 (i.e., DASP), to establish desired trust relationships to ensure authenticity and secure device communication, concurrently. In some cases, the IoT Gateway 202 may control the communication of the IoT device 206 as long as the device is unauthenticated, so that it cannot do harm to the IoT system 200. The trust broker 204 may then authenticate the device 206, and release a secret for communication protection to the gateway 202. The device 206, the gateway 202, and other authorized entities may use this secret to protect communication to and from the device 206 on the application layer. Additionally, the trust broker 204 may release credentials to the device 206, which can be used to authenticate the device to an IoT service.” … Parag. [0024]; “The CONNECT request may be accompanied by (or may include) an authentication credential, such as an identifier/password pair or a cryptographic token for example.”).
The combination of Loladia, Schmidt and Hughes does not expressly teach:
generate a second encrypted device protection code based on information associated with the IoT platform, and
provide the second encrypted device protection code to the IoT platform;
However, Haque teaches:
generate a second encrypted device protection code based on information associated with the IoT platform (Haque, Parag. [0018]; “The client application may comprise, for example, an Internet of Things (IoT) platform or other mobile application. The token issuer may generate a token, encrypt sensitive data within the token body, and sign the token using a signature.” … Parag. [0029]; “The token issuer 202 may generate a key and then may encrypt sensitive data in a token using the key. The sensitive data may comprise information associated with the untrusted platform 201. The information associated with the untrusted platform 201 may comprise information indicating at least one of permissions of the untrusted platform 201, account information of the untrusted platform 201, or capabilities of the untrusted platform 201.”), and
provide the second encrypted device protection code to the IoT platform (Haque, Parag. [0018]; “The token issuer may send the signed encrypted token to the untrusted platform over the trust boundary. The signed encrypted token may comprise an encrypted key in its header, the encrypted data payload in its body, and the signature in a signature portion. The token may have an associated time for validity.”);
Loladia, Schmidt, Hughes and Haque are from similar field of technology. Prior to the instant application’s effective filling date, there was a need for a provide secure communications in an IoT system.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Haque system into Loladia-Schmidt-Hughes system, with a motivation to provide a method to generate a protection code for multiple devices in an IoT platform (Haque, Parag. [0118]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Albisu (US 2012/0144203) relates to authenticating a user of a service are disclosed. A Personal Identification Number (PIN) is generated using a plurality of variables, and a user is authenticated by comparing the PIN generated at the user's mobile device with a PIN generated on an authentication server. The authentication enables the user to access a service or resource hosted on a host server. When requesting access to the resource, the user generates a device PIN and transmits the device PIN along with their unique key into the host server. The host server forwards the device PIN and the key to the authentication server. The authentication server generates a server PIN and compares the server PIN to the device PIN. If the two PINs match, the authentication server transmits a successful authentication response to the host server. The PIN generation process is a standard hash process, such as MD5 or SHA1, and uses at least the key provided by the user, a device identifier, and a current date/time. The device identifier is one of a unique identifier of the hardware on the mobile device or a unique identifier of a communication channel. This combination of the device identifier and the key ensures that only an authorized user is allowed access to the service.
Britt et al. (US 10,171,462) relates to system and method are described for provisioning an IoT device using an association ID code. For example, one embodiment of a method comprises: generating an association between a new Internet of Things (IoT) device identification (ID) code and an association ID code; storing the association in an IoT device database of an IoT service; retrieving the association ID code from the new IoT device; transmitting the association ID code to the IoT service, the IoT service performing a lookup in the IoT device database using the association ID code to determine the device ID code; and provisioning the IoT device to communicate with the IoT service using the device ID code.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALEX D CARRASQUILLO whose telephone number is (571)270-5045. The examiner can normally be reached Monday - Friday 9:00 am - 6:00 pm.
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, Yin-Chen Shaw can be reached at 571-272-8878. 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.
/A.D.C./Examiner, Art Unit 2498
/YIN CHEN SHAW/Supervisory Patent Examiner, Art Unit 2498
Prosecution Insights