DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim status in the amendment received on 4/2/2026:
Claims 1, 9, 14, 17 and 19-20 have been amended.
Claim 21 has been canceled.
New claim 34 has been added.
Claims 1-6, 9-11, 13-15, 17-20, 24 and 32-34 are pending.
Response to Amendments
Applicant’s amendments have been considered and in response to the amendments:
The previous 112(b) rejections have been withdrawn.
Response to Arguments
Applicant’s arguments have been considered but they are not persuasive.
With respect to claims 1 and 9, the limitation “a number of second servers” is given a broadest reasonable interpretation which covers any number of second servers (zero, one or more). In other words, since the claim does not explicitly define what the number is, the “number” reads on any number of second servers.
With respect to claim 17, please see how the prior art is applied for the amendments in the rejections below.
Claim Objections
Claims 1 is objected to because of the following informalities.
As to claims 1, the limitation “the second server”, in the last limitation, should be “the at least one second server” in order to be consistent with the antecedent basis.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 5 and 24 is/are rejected under 35 U.S.C. 103 as being unpatentable over Amada et al. (Pub. No.: US 20020120872 A1) in view of Foti et al. (Pub. No.: US 20210044628 A1).
As to claim 1, Amada teaches an authentication method, being applicable to an Internet of Things (IoT) device, comprising:
determining a first address of a first server preset to be connectable with the IoT device (fig. 2, S0203, “@domainidentification” teaches a first address, “contracted company A RADIUS” teaches a first server, user device teaches an IoT device) and a second address of at least one second server not preset to be connectable with the IoT device (fig. 2, “uncontracted company B RADIUS” teaches at least one second server, and fig. 1, 0106b “10.10.3.2” teaches a second address); and
sending a first authentication request to the at least one second server, wherein the first authentication request at least carries authentication information of the IoT device and the first address (fig. 2, “request (S0202)” and paragraph [0062], i.e. user name and password); wherein the at least one second server comprises a plurality of second servers (fig. 1, 0106a and 0106b).
Even though Amada teaches an address for the second server (fig. 1, 0106b/0106a) and the connection between the user device and the second server is an IP based connection (based on the shown IP addresses), Amada does not explicitly tach that the authentication request is sent according to the second address and receiving an indication and determining an allowed servers to connect to.
However, for a request to reach a target device in an IP network a destination address must be used.
Therefore, it would have been obvious to an ordinary skill in the art, before the effective filing date of the claimed invention, to send the first authentication request to the second server according to the second address in order to make sure that the request will be routed to the second server and to confirm to network standard.
Amada does not explicitly teach receiving an indication and determining an allowed servers to connect to.
However, in the same field of endeavor (computer networks) Foti teaches receiving indication information sent by a first server (paragraph [0008], “…The SMF provides the identities (e.g., network addresses or FQDNs) of one or more of the candidate servers from the list to the UE…”); and
determining a number of second servers that the IoT device is allowed to communicate with at the same time according to the indication information (paragraph [0008], “…The SMF provides the identities (e.g., network addresses or FQDNs) of one or more of the candidate servers from the list to the UE, and establishes a data session used by the UE to communicate with a selected one of the candidate servers in the external data network…”, a “number” of second servers reads on 0 or more second servers); or sending information communicated with each of the plurality of second servers to a gateway, generating with the gateway a container of the IoT device for the second server.
Based on Amada in view of Foti, it would have been obvious to an ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate receiving an indication and determining an allowed servers to connect to (taught by Foti) with sending the first authentication request to the second server according to the second address with authentication devices to a new network (taught by Amada) in order to make sure that the request will be routed to the second server and to confirm to network standards, and in order to dynamically configure the device to connect to a desired server.
As to claim 5, Foti further teaches receiving priority information of the plurality of second servers sent by the first server (paragraph [0066], “received order of priority”); and
selecting a target server from the plurality of second servers according to the priority information (paragraph [0066], “selecting the server from the list of one or more candidates in accordance with the received order of priority”). The limitations of claim 5 are rejected in view of the analysis of claim 1 above, and the rationale to combine, as discussed in claim 1, applies here as well.
As to claim 24, Amada further teaches an authentication system (fig. 1), comprising an Internet of Things (IoT) device, a first server and at least one second server, wherein the IoT device, the first server and the at least one second server are configured to cooperatively implement the steps in the authentication method according to claim 1 (fig. 2).
Claim(s) 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Amada et al. (Pub. No.: US 20020120872 A1) in view of James et al. (Pub. No.: US 20160205078 A1).
As to claim 17, Amada teaches an authentication method comprising:
receiving, with a second server, a first authentication request, the first authentication request being sent by the IoT device to a gateway (fig. 2, S0202, “uncontracted company B RADIUS” teaches a second server user device initiating the request teaches IoT device, “company B AS” teaches a gateway); and
performing authentication on the IoT device in cooperation with a first server (fig. 2, S0204),
wherein the first server is a server preset to be connectable with the IoT device (fig. 2, “contracted company A RADIUS”), and the second server is a server not preset to be connectable with the IoT device (fig. 2, “uncontracted company B RADIUS”).
Amada does not explicitly teach implementing a container in the gateway for sending or receiving information for the IoT device.
However, in the same field of endeavor (computer network) James teaches
receiving, with a second server, a first request from a container for an Internet of Things (IoT) device and corresponding to the second server, the first request being sent by the IoT device to the container, the container being in a gateway (paragraph [0028], “…the IoT services container can be included in the gateway device 215…” and in fig. 1, traffic flow between 105, 110 and 120); and
sending information to the container so that the IoT device receives the information from the container, wherein the respective container is in a gateway; or receiving from the container information sent by the IoT device (paragraph [0028], “…the IoT service can be implemented as an IoT services container. An IoT services container provides one or more services to an IoT device via one or more APIs. The one or more services can include, but are not limited to, an administrative service, a datameeter service, a crawler service, a messaging service, a DNS service…” and in fig. 1, traffic flow between 105, 110 and 120).
Based on Amada in view of James, it would have been obvious to an ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate implementing a container in the gateway for sending or receiving information for the IoT device (taught by James) with authentication devices to a new network (taught by Amada) in order to utilize the container to provide administrative and metering services to the device as motivated by James (paragraph [0028]).
Claim(s) 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Amada et al. (Pub. No.: US 20020120872 A1) in view of Foti et al. (Pub. No.: US 20210044628 A1) and further in view of Messer et al. (Pub. No.: US 20140280469 A1).
As to claim 2, Amada further teaches wherein determining the first address and the second address comprises: receiving the first address prestored in an application for controlling the IoT device (paragraph [0048], “adding "@domain name" after a user ID manually or automatically”).
Amada in view of Foti does not explicitly teach the second address entered by a user.
However, in the same field of endeavor (computer network) Messer teaches receiving a second address entered by a user in the application (fig. 3A).
Based on Amada in view of Foti and further in view of Messer, It would have been obvious to an ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate second address entered by a user (taught by Messer) with receiving an indication and determining an allowed servers to connect to (taught by Foti) with sending the first authentication request to the second server according to the second address with authentication devices to a new network (taught by Amada) in order to make sure that the request will be routed to the second server and to confirm to network standards, and in order to dynamically configure the device to connect to a desired server, and in order to allow the user to enter or change desired address.
Claim(s) 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Amada et al. (Pub. No.: US 20020120872 A1) in view of Foti et al. (Pub. No.: US 20210044628 A1) and further in view of Kamath et al. (Pub. No.: US 20110007077 A1).
As to claim 3, Amada in view of Foti does not explicitly teach the authentication information comprises a device name, a product key or both.
However, in the same field of endeavor (computer networks) Kamath teaches the authentication information comprises a device name, a product key or both (paragraph [0046], “Authentication request 505 may include a mobile directory number (MDN) associated with user 105-1, a key (e.g., a hash token), a network address (e.g., an IP address from user device 110-1, and a device type (e.g., a user device name)”).
Based on Amada in view of Foti and further in view of Kamath, It would have been obvious to an ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate authentication information comprises a device name, a product key or both (taught by Kamath) with receiving an indication and determining an allowed servers to connect to (taught by Foti) with sending the first authentication request to the second server according to the second address with authentication devices to a new network (taught by Amada) in order to make sure that the request will be routed to the second server and to confirm to network standards, and in order to dynamically configure the device to connect to a desired server, and in order to enhance the security of the authentication.
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Amada et al. (Pub. No.: US 20020120872 A1) in view of Foti et al. (Pub. No.: US 20210044628 A1) and further in view of Zhou et al. (Pub. No.: US 20060224890 A1).
As to claim 4, Amada in view of Foti does not explicitly teach sending a connection request using a received device key.
However, in the same field of endeavor (computer networks) Zhou teaches
receiving a device key sent by the at least one second server (fig. 2, 206, 208); and
sending a connection request to the at least one second server, wherein the connection request is configured to request a communication connection with the at least one second server and carries the device key (paragraph [0036], “The authentication may determine the device key…”).
Based on Amada in view of Foti and further in view of Zhou, It would have been obvious to an ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate sending a connection request using a received device key (taught by Zhou) receiving an indication and determining an allowed servers to connect to (taught by Foti) with sending the first authentication request to the second server according to the second address with authentication devices to a new network (taught by Amada) in order to make sure that the request will be routed to the second server and to confirm to network standards, and in order to dynamically configure the device to connect to a desired server, and in order to automate the authentication process.
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Amada et al. (Pub. No.: US 20020120872 A1) in view of Foti et al. (Pub. No.: US 20210044628 A1) and further in view of Sasso et al. (Pub. No.: US 20120099855 A1).
As to claim 6, Amada teaches wherein the at least one second server comprises a plurality of second servers (fig. 1, 0106a and 0106b).
Amada in view of Foti does not explicitly teach connecting with servers through time sharing strategy.
However, in the same field of endeavor (computer networks) Sasso teaches
a plurality of second servers, and after establishing communication connections with the plurality of second servers respectively, the method further comprises: respectively communicating with the plurality of second servers through a time- sharing strategy (paragraph [0012], “… For example, switch 20(1) connects to a plurality of host (servers) 30(1)-30(N). Moreover, the switch 20(1) is configured to connect to servers in different run-time domains …”).
Based on Amada in view of Sasso, It would have been obvious to an ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate connecting with servers through time sharing strategy (taught by Sasso) with receiving an indication and determining an allowed servers to connect to (taught by Foti) with sending the first authentication request to the second server according to the second address with authentication devices to a new network (taught by Amada) in order to make sure that the request will be routed to the second server and to confirm to network standards, and in order to dynamically configure the device to connect to a desired server, and in order to achieve load balancing.
Claim(s) 9-10 and 14-15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Amada et al. (Pub. No.: US 20020120872 A1) in view of Tie et al. (Pub. No.: US 20060143458 A1) and further in view of Foti et al. (Pub. No.: US 20210044628 A1).
As to claim 9, Amada teaches an authentication method comprising:
receiving a second authentication request sent by at least one second server, wherein the second authentication request at least carries authentication information of an Internet of Things (IoT) device (fig. 2, S0204),
the first server is a server preset to be connectable with the IoT device (fig. 2, “contracted company A RADIUS”), and the at least one second server is a server not preset to be connectable with the IoT device (fig. 2, “uncontracted company B RADIUS”);
performing authentication on the IoT device according to the authentication information (fig. 2, S0205); and
sending an authentication response to the at least one second server according to a result of authentication (fig. 2, S0206); and
sending transaction information, wherein the transaction information is that the first server transfers a service management authority of the IoT device to the at least one second server (fig. 2, S0207, i.e. addition to user information database and paragraph [0065]).
Amada does not explicitly teach authentication using a certificate and sending an indication and determining an allowed servers to connect to.
However, in the same field of endeavor (computer networks) Tie teaches receiving a second authentication request sent by at least one second server, wherein the second authentication request at least carries a certificate of the at least one second server (paragraph [0010], “… after AP receives said access authentication request message, it adds the AP certificate to the message, then sends to AS the certificate authentication request message …”),
performing authentication on the at least one second server according to the certificate (paragraph [0010], “… after AS receives said certificate authentication request message, AS authenticates the AP certificate …”).
Based on Amada in view of Tie, it would have been obvious to an ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate authentication using a certificate (taught by Tie) with sending the first authentication request to the second server (taught by Amada) in order to verify identity of the entity requesting authentication.
Amada in view of Tie does not explicitly teaches sending an indication and determining an allowed servers to connect to.
However, in the same field of endeavor (computer networks) Foti teaches sending indication information to the IoT device, wherein the indication information is configured to indicate a number of second servers that the IoT device is allowed to communicate with at the same time (paragraph [0008], “…The SMF provides the identities (e.g., network addresses or FQDNs) of one or more of the candidate servers from the list to the UE, and establishes a data session used by the UE to communicate with a selected one of the candidate servers in the external data network…”).
Based on Amada in view of Tie and further in view of Foti, it would have been obvious to an ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate sending an indication and determining an allowed servers to connect to (taught by Foti) with authentication using a certificate (taught by Tie) with sending the first authentication request to the second server (taught by Amada) in order to verify identity of the entity requesting authentication, and in order to dynamically configure the device to connect to a desired server.
As to claim 10, Tie further teaches in response to the authentication of the at least one second server being successful and the authentication of the IoT device being successful, the authentication response is an authentication success response (paragraph [0010], “… AS authenticates the AP certificate and MT certificate in said message, and then sends back to AP the certificate authentication response message …”); and
in response to the authentication of the at least one second server being usuccessful or the authentication of the IoT device being unsuccessful, the authentication response is an authentication failure response (paragraph [0010], “… AS authenticates the AP certificate and MT certificate in said message, and then sends back to AP the certificate authentication response message …”). The limitations of claim 10 are rejected in view of the analysis of claim 9 above, and the rationale to combine, as discussed in claim 9, applies here as well.
As to claim 14, Foti further teaches at least one second server comprises a plurality of second servers, determining priority information of the plurality of second servers (paragraph [0066], “received order of priority”); and
sending the priority information to the IoT device, wherein the priority information is configured to instruct the IoT device to select a target server from the plurality of second servers to receive a device key (paragraph [0066], “selecting the server from the list of one or more candidates in accordance with the received order of priority”); or the method further comprises: sending indication information to the IoT device, wherein the indication information is configured to indicating a number of second servers that the IoT device is allowed to connect to or a number of second servers that the IoT device is allowed to communicate with at the same time, or both. The limitations of claim 14 are rejected in view of the analysis of claim 9 above, and the rationale to combine, as discussed in claim 9, applies here as well
As to claim 15, Foti further teaches determining the priority information of the plurality of second servers comprises: determining the priority information of the plurality of second servers according to services or response speeds provided by the plurality of second servers, or both (paragraph [0048], “…an order of priority from which the UE 100 can select a P-CSCF 85 based on priority…”). The limitations of claim 15 are rejected in view of the analysis of claim 14 above, and the rationale to combine, as discussed in claim 14, applies here as well.
Claim(s) 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Amada et al. (Pub. No.: US 20020120872 A1) in view of James et al. (Pub. No.: US 20160205078 A1) and further in view of Won et al. (Pub. No.: US 20180183587 A1).
As to claim 18, Amada further teaches wherein the first authentication request at least carries authentication information of the IoT device, and performing the authentication on the IoT device in cooperation with the first server (paragraph [0059]).
Amada in view of James does not explicitly teach authentication based on product key and associated hash value stored in a block chain.
However, in the same field of endeavor (computer network) Won teaches
obtaining transaction information from a blockchain, wherein the transaction information comprises a product name of the IoT device and a first hash value obtained by the first server according to a product key of the IoT device (paragraph [0005]);
obtaining a second hash value according to a product key in the authentication information (paragraph [0006]); and
determining whether the authentication of the IoT device is successful according to the first hash value and the second hash value (paragraph [0006])
Based on Amada in view of James and further in view of Won, it would have been obvious to an ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate authentication based on product key and associated hash value stored in a block chain (taught by Won) with receiving information sent by the IoT device from a respective container in the gateway (taught by James) with authentication devices to a new network (taught by Amada) in order to utilize the container to provide administrative and metering services to the device as motivated by James (paragraph [0028]), and in order to provide temper evident data storage as motivated by Won (paragraph [0088]).
Claim(s) 32 is/are rejected under 35 U.S.C. 103 as being unpatentable over Amada et al. (Pub. No.: US 20020120872 A1) in view of James et al. (Pub. No.: US 20160205078 A1) and further in view of Tie et al. (Pub. No.: US 20060143458 A1).
As to claim 32, Amada teaches wherein the first authentication request at least carries authentication information of the IoT device (fig. 2, S0204), and performing the authentication on the IoT device in cooperation with the first server comprises:
determining a first address of the first server (paragraph [0048]);
sending a second authentication request to the first server according to the first address, wherein the second authentication request at least carries the authentication information of the IoT device (paragraph [0048]);
receiving an authentication response sent by the first server to determine whether the authentication of the IoT device by the first server are successful according to the authentication response (fig. 2, S0206).
Amada in view of James does not explicitly teach authentication using a certificate.
However, in the same field of endeavor (computer networks) Tie teaches sending a second authentication request to the first server, wherein the second authentication request at least carries the authentication information of the IoT device and a certificate of the second server (paragraph [0010], “… after AP receives said access authentication request message, it adds the AP certificate to the message, then sends to AS the certificate authentication request message …”); and
receiving an authentication response sent by the first server to determine whether an authentication of the second server by the first server are successful according to the authentication response (paragraph [0010], “… after AS receives said certificate authentication request message, AS authenticates the AP certificate …”).
Based on Amada in view of James and further in view of Tie, it would have been obvious to an ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate authentication using a certificate (taught by Tie) with receiving information sent by the IoT device from a respective container in the gateway (taught by James) with authentication devices to a new network (taught by Amada) in order to utilize the container to provide administrative and metering services to the device as motivated by James (paragraph [0028]), and in order to verify identity of the entity requesting authentication.
Claim(s) 33 is/are rejected under 35 U.S.C. 103 as being unpatentable over Amada et al. (Pub. No.: US 20020120872 A1) in view of Foti et al. (Pub. No.: US 20210044628 A1) and further in view of Won et al. (Pub. No.: US 20180183587 A1).
As to claim 33, Amada further teaches after receiving an authentication success response from the second server, sending by the IoT device transaction information to a database, wherein the transaction information is that the IoT device is connected to the second server (fig. 2, S0207 and paragraph [0065]).
Amada does not explicitly teach blockchain.
However, in the same field of endeavor (network security) Won teaches sending by an IoT device transaction information to a blockchain (paragraph [0016], “registering and authenticating Internet of things (IoT) devices. In one embodiment, an IoT device is registered in a blockchain name/value storage”).
Based on Amada in view of Foti and further in view of Won, it would have been obvious to an ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate blockchain (taught by Won) with receiving an indication and determining an allowed servers to connect to (taught by Foti) with sending the first authentication request to the second server according to the second address with authentication devices to a new network (taught by Amada) in order to make sure that the request will be routed to the second server and to confirm to network standards, and in order to dynamically configure the device to connect to a desired server, and in order to provide temper evident data storage as motivated by Won (paragraph [0088]).
Claim(s) 34 is/are rejected under 35 U.S.C. 103 as being unpatentable over Amada et al. (Pub. No.: US 20020120872 A1) in view of Foti et al. (Pub. No.: US 20210044628 A1) and further in view of James et al. (Pub. No.: US 20160205078 A1).
As to claim 34, Amada does not explicitly teach receiving information sent by the IoT device from a respective container.
However, in the same field of endeavor (computer network) James teaches receiving from a respective container for an IoT device and corresponding to one second server of a second servers information sent by the second server (paragraph [0028]).
Based on Amada in view of Foti and further in view of James, it would have been obvious to an ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate receiving information sent by the IoT device from a respective container (taught by James) with receiving an indication and determining an allowed servers to connect to (taught by Foti) with sending the first authentication request to the second server according to the second address with authentication devices to a new network (taught by Amada) in order to make sure that the request will be routed to the second server and to confirm to network standards, and in order to dynamically configure the device to connect to a desired server, and in order to utilize the container to provide administrative and metering services to the device as motivated by James (paragraph [0028]).
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Amada et al. (Pub. No.: US 20020120872 A1) in view of Tie et al. (Pub. No.: US 20060143458 A1) and Foti et al. (Pub. No.: US 20210044628 A1) and further in view of Won et al. (Pub. No.: US 20180183587 A1).
As to claim 11, Amada in view of Tie and further in view of Foti does not teach sending product name and hash value to a blockchain.
However, in the same field of endeavor (computer network) Won teaches sending a product name of the IoT device and a first hash value obtained according to a product key of the IoT device to a blockchain as transaction information; or any combination thereof (abstract “…a blockchain wallet in the installation devices generates a blockchain transaction which adds the received ID and hash of the public key as a name and value pair in a name/value storage (NVS)…”).
Based on Amada in view of Tie and Foti and further in view of Won, it would have been obvious to an ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate sending product name and hash value to a blockchain (taught by Won) with sending an indication and determining an allowed servers to connect to (taught by Foti) with authentication using a certificate (taught by Tie) with sending the first authentication request to the second server (taught by Amada) in order to verify identity of the entity requesting authentication, and in order to dynamically configure the device to connect to a desired server, and in order to provide temper evident data storage as motivated by Won (paragraph [0088]).
Claim(s) 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Amada et al. (Pub. No.: US 20020120872 A1) in view of Tie et al. (Pub. No.: US 20060143458 A1) and Foti et al. (Pub. No.: US 20210044628 A1) and further in view of Suffling et al. (Pub. No.: US 20120260329 A1).
As to claim 13, Amada further teaches wherein the at least one second server comprises a plurality of second servers (fig. 1, 0106b and 0106a), and receiving the second authentication request sent by the at least one second server comprises: receiving the second authentication request sent by any one of the plurality of second servers (fig. 2, S0205).
Amada in view of Tie and further in view of Foti does not teach stop receiving authentication requests.
However, in the same field of endeavor (computer networks) Suffling teaches after receiving the second authentication request sent by any one of the plurality of second servers, stop receiving second authentication requests sent by remaining second servers (paragraph [0029] “…if the authentication request is determined not to have been received from any device with which any verified pre-authentication request is associated, discarding the authentication request…”).
Based on Amada in view of Tie and Foti and further in view of Suffling, it would have been obvious to an ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate stop receiving authentication requests (taught by Suffling) with sending an indication and determining an allowed servers to connect to (taught by Foti) with authentication using a certificate (taught by Tie) with sending the first authentication request to the second server (taught by Amada) in order to verify identity of the entity requesting authentication, and in order to dynamically configure the device to connect to a desired server, and in order to enhance the security of the authentication process.
Claim(s) 19-20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Amada et al. (Pub. No.: US 20020120872 A1) in view of James et al. (Pub. No.: US 20160205078 A1) and Tie et al. (Pub. No.: US 20060143458 A1) and further in view of Zhou et al. (Pub. No.: US 20060224890 A1).
As to claim 19, Amada further teaches determining that the authentication of the second server and the authentication of the IoT device are successful (paragraph [0065]).
Amada in view of James and further in view of Tie does not explicitly teach sending a device key to the device.
However, in the same field of endeavor (computer networks) Zhou teaches in response to determining that the authentication is successful, sending a device key to the IoT device (fig. 2, 206, 208), wherein the device key is configured to establish a communication connection between the IoT device and the second server (paragraph [0036], “The authentication may determine the device key…”); or
sending first transaction information to a blockchain, wherein the first transaction information is that the second server obtains a service management authority of the IoT device, and second transaction information recorded in the blockchain is that the first server transfers the service management authority to the second server; or
any combination thereof.
Based on Amada in view of James and Tie and further in view of Zhou, it would have been obvious to an ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate sending a device key to the device (taught by Zhou) with authentication using a certificate (taught by Tie) with receiving information sent by the IoT device from a respective container in the gateway (taught by James) with authentication devices to a new network (taught by Amada) in order to utilize the container to provide administrative and metering services to the device as motivated by James (paragraph [0028]), and in order to verify identity of the entity requesting authentication, and in order to automate the authentication process.
As to claim 20, Zhou further teaches receiving a connection request sent by the IoT device, wherein the connection request at least carries the device key (paragraph [0036], “The authentication may determine the device key…”);
performing authentication on the IoT device according to the device key (paragraph [0036], “The authentication may determine the device key…”); and
in response to the authentication of the IoT device being successful, establishing the communication connection with the IoT device (paragraph [0038], “authentication is successful…”). The limitations of claim 20 are rejected in view of the analysis of claim 19 above, and the rationale to combine, as discussed in claim 19, applies here as well.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDULKADER M ALRIYASHI whose telephone number is (313)446-6551. The examiner can normally be reached Monday - Friday, 8AM - 5PM Alt, Friday, EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, JOON HWANG can be reached at (571)272-4036. 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.
/Abdulkader M Alriyashi/Primary Examiner, Art Unit 2447 6/14/2026
Prosecution Insights