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 .
Response to Amendment
This office action is in reply to Applicant’s Response dated 12/03/2025. Claims 1, 9, 14 and 21 are amended. Claims 18-20 are canceled. Claims 1-17 and 21-22 remain pending in the application.
Response to Arguments
In response to the Applicant’s argument (see page 8) with respect to the rejection under 35 U.S.C. 101, the rejection under 35 U.S.C. 101 has been withdrawn in view of the amendment made to claim 21.
The Applicant argues (see pages 8-9) that Amended claim 1 includes at least: "wherein the authentication flow is a process in which the main control device is authenticated by the management server of the target device when the main control device performs network configuration to the target device". The Office alleges that Tikhomirov discloses "(the main control device) receiving device description information transmitted by a target device" and "(the main control device) performing an authentication flow indicated by the flow information based on the device configuration information". Applicant respectfully disagrees. Park also fails to teach this feature.
In response to the Applicant’s argument, the Examiner respectfully disagrees. First, the claim fails to recite limitation that explain how the main control device performs network configuration to the target device. The limitation “network configuration” is not defined in the claim or specification. Park teaches that the IoT device 110 requests the security module 120 to generate a key (302). Under the broadest reasonable interpretation, a request to generate a key is a request to perform network configuration. Park further teaches that the security module 120 may transmit the generated public key to the IoT device 110 (306) and the public key is sent to the authentication server, and the authentication server verifies the public key and the device ID and generates a signed certificate by signing the generated certificate, which is transmitted to the IoT device and stored by the security module (Park, see fig. 3; see paragraphs 0057-0058, 0060 and 0062-0064).
Therefore, Park teaches “wherein the authentication flow is a process in which the main control device (security module which generates the public key) is authenticated by the management server (authenticating or verifying the security module’s public key is authenticating the security module by the authentication server) of the target device (IoT device) when the main control device (security module) performs network configuration (generating the public key and storing the certificate) to the target device (IoT device); and” (Park, see fig. 3; see paragraphs 0057-0058, 0060 and 0062-0064).
The Applicant argues (see page 10) that Independent claim 9 is amended to include the feature "the authentication information is configured for the management server to authenticate the main control device", which is similar to the amendment made to independent claim 1.
In response to the Applicant’s argument, the Examiner respectfully disagrees. The limitation “the authentication information is configured for the management server to authenticate the main control device" required by claim 9 pertains to the authentication information and not the authentication flow which is a “process” as required by claim 1.
Tikhomirov teaches “the authentication information is configured for the management server to authenticate the main control device" (Tikhomirov, see figs. 9 and 13; see paragraph 0279 sends its connection ID (authentication information) to the network, after which it will be recognized (authenticated) by the hub 310 (obtains the status of the powered-on device and the device will be included in the security domain of untrusted devices)...; see paragraphs 0299-0300)
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 8-12, 14, 16-17 and 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over Tikhomirov et al. (U.S. PGPub 2022/0294854) in view of Park et al. (U.S. PGPub 2021/0152545).
Regarding claims 1, 21 and 22, Tikhomirov teaches A device network configuration method applied to a main control device and comprising: receiving device description information transmitted by a target device, and the device description information comprises device configuration information and flow information; (Tikhomirov, see figs. 9 and 13; see paragraphs 0299-0300 where device data is collected by means of the hub 310. The data can include the device ID and series, the device name, data on the manufacturer, a set of specifications (such as parameters of the device itself), MAC address, and other data...the information security domain of the IoT device is determined. In particular, domains include trusted, untrusted, and insecure devices...; see paragraphs 0018-0019 where packets intended for changing the parameters of the IoT device...parameters for indicating a protocol type; parameters for indicating a network address or domain name; parameters for indicating a port number; parameters for indicating IPv4 or IPv6; parameters for indicating ID of device from or to which traffic is directed; and parameters for indicating an application; see paragraph 0380 the device data is collected...)
performing an authentication flow indicated by the flow information based on the device configuration information and (Tikhomirov, see figs. 9 and 13; see paragraph 0380 where the device data is collected to generate the device profile (performing authentication flow)...The profile can be generated as soon as a device is discovered, or as long as it takes to collect enough data for specific fields of the profile...)
However, Tikhomirov does not explicitly teach obtaining signature information generated by a management server of the target device in response that authentication of the main control device by the management server passes;
wherein the authentication flow is a process in which the main control device is authenticated by the management server of the target device when the main control device performs network configuration to the target device; and
transmitting the signature information to the target device to perform network configuration processing on the target device after the signature information is validated by the target device.
Park teaches obtaining signature information generated by a management server of the target device in response that authentication of the main control device by the management server passes; (Park, see fig. 3; see paragraph 0058 where transmit a certificate generation request including a device ID and the public key to the authentication server 150 (308)…; see paragraph 0060 where the authentication server 150 may verify the public key and the device ID included in the certificate generation request...The authentication server 150 may verify the validity of a corresponding device by comparing the device ID received from the cloud 160...; see paragraph 0060 where the authentication server 150 may generate a certificate (310)...)
wherein the authentication flow is a process in which the main control device is authenticated by the management server of the target device when the main control device performs network configuration to the target device; and (Park, see fig. 3; see paragraph 0035 a system 100 for performing device authentication in an IoT cloud may include at least one IoT device 110, an authentication center 140, an authentication server 150, a cloud 160, an IoT service (or an IoT service server) 170, a gateway 130, and a security module 120...; see paragraph 0057 start when the IoT device 110 requests the security module 120 to generate a key (302) (to perform network configuration)...transmit the generated public key to the IoT device 110 (306); see paragraph 0065 received certificate and private key to the security module 120 and store the received certificate and private key in the security module 120 (314 and 316)...)
transmitting the signature information to the target device to perform network configuration processing on the target device after the signature information is validated by the target device. (Park, see fig. 3; see paragraph 0064-0065 where authentication server 150 may transmit the generated certificate to the IoT device 110 (312)...transmit the received certificate and private key to the security module 120 and store the received certificate and private key in the security module 120 (314 and 316)...)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Tikhomirov and Park to provide the technique of obtaining signature information generated by a management server of the target device in response that authentication of the main control device by the management server passes, wherein the authentication flow is a process in which the main control device is authenticated by the management server of the target device when the main control device performs network configuration to the target device, and transmitting the signature information to the target device to perform network configuration processing on the target device after the signature information is validated by the target device of Park in the system Tikhomirov in order to provide a strengthened environment in terms of device authentication (Park, see paragraph 0094).
Regarding claim 2, Tikhomirov-Park teaches wherein the performing of the authentication flow indicated by the flow information based on the device configuration information and the obtaining of the signature information generated by the management server of the target device in response that the authentication of the main control device by the management server passes comprises: (Tikhomirov, see figs. 9 and 13; see paragraph 0380 where the device data is collected to generate the device profile (performing authentication flow)...The profile can be generated as soon as a device is discovered, or as long as it takes to collect enough data for specific fields of the profile...; see paragraph 0440 where the device profile is hashed. The hash is created...; note that the hash is created in response to the completion of the device profile)
querying device management information of the target device from a common server based on the device configuration information; and (Tikhomirov, see figs. 9 and 13; see paragraphs 0299-0300 where device data is collected by means of the hub 310. The data can include the device ID and series, the device name, data on the manufacturer, a set of specifications (such as parameters of the device itself), MAC address, and other data...the information security domain of the IoT device is determined. In particular, domains include trusted, untrusted, and insecure devices...; see paragraph 0499 where when an unknown device is identified, the hub 310 reads the manufacturer ID and sends a request to the security service 1010 to search (query) for similar device profiles from that manufacturer.)
performing an authentication operation corresponding to the device management information and obtaining the signature information generated by the management server of the target device in response that the authentication of the main control device by the management server passes. (Park, see fig. 3; see paragraph 0058 where transmit a certificate generation request including a device ID and the public key to the authentication server 150 (308)…; see paragraph 0060 where the authentication server 150 may verify the public key and the device ID included in the certificate generation request...The authentication server 150 may verify the validity of a corresponding device by comparing the device ID received from the cloud 160...; see paragraph 0060 where the authentication server 150 may generate a certificate (310)...) The motivation regarding to the obviousness to claim 1 is also applied to claim 2.
Regarding claim 8, Tikhomirov-Park teaches wherein the device configuration information comprises a device manufacturer identification and a device model of the target device, (Tikhomirov, see figs. 9 and 13; see paragraphs 0299-0300 where device data is collected by means of the hub 310. The data can include the device ID and series, the device name, data on the manufacturer, a set of specifications (such as parameters of the device itself), MAC address, and other data...the information security domain of the IoT device is determined. In particular, domains include trusted, untrusted, and insecure devices...)
the querying of the device management information of the target device from the common server based on the device configuration information comprises: querying the device management information uploaded by a device manufacturer of the target device from the common server based on the device manufacturer identification and the device model of the target device. (Tikhomirov, see figs. 9 and 13; see paragraphs 0299-0300 where device data is collected by means of the hub 310. The data can include the device ID and series, the device name, data on the manufacturer, a set of specifications (such as parameters of the device itself), MAC address, and other data...the information security domain of the IoT device is determined. In particular, domains include trusted, untrusted, and insecure devices...; see paragraph 0499 where when an unknown device is identified, the hub 310 reads the manufacturer ID and sends a request to the security service 1010 to search for similar device profiles from that manufacturer.)
Regarding claim 9, Tikhomirov teaches A device network configuration method applied to a management server for managing a target device and comprising: receiving authentication information uploaded by a main control device, (Tikhomirov, see figs. 9 and 13; see paragraphs 0299-0300 where device data is collected by means of the hub 310. The data can include the device ID and series, the device name, data on the manufacturer, a set of specifications (such as parameters of the device itself), MAC address, and other data...the information security domain of the IoT device is determined. In particular, domains include trusted, untrusted, and insecure devices...; see paragraphs 0018-0019 where packets intended for changing the parameters of the IoT device...parameters for indicating a protocol type; parameters for indicating a network address or domain name; parameters for indicating a port number; parameters for indicating IPv4 or IPv6; parameters for indicating ID of device from or to which traffic is directed; and parameters for indicating an application; see paragraph 0380 the device data is collected...)
wherein the authentication information is configured for the management server to authenticate the main control device; (Tikhomirov, see figs. 9 and 13; see paragraph 0279 sends its connection ID to the network, after which it will be recognized (authenticated) by the hub 310 (obtains the status of the powered-on device and the device will be included in the security domain of untrusted devices)...; see paragraphs 0299-0300)
However, Tikhomirov does not explicitly teach generating signature information in response that authentication of the main control device passes based on the authentication information; and
transmitting the signature information to the target device through the main control device to perform network configuration processing on the target device by the main control device after the signature information is verified by the target device.
Park teaches generating signature information in response that authentication of the main control device passes based on the authentication information; and (Park, see fig. 3; see paragraph 0058 where transmit a certificate generation request including a device ID and the public key to the authentication server 150 (308)…; see paragraph 0060 where the authentication server 150 may verify the public key and the device ID included in the certificate generation request...The authentication server 150 may verify the validity of a corresponding device by comparing the device ID received from the cloud 160...; see paragraph 0060 where the authentication server 150 may generate a certificate (310)...)
transmitting the signature information to the target device through the main control device to perform network configuration processing on the target device by the main control device after the signature information is verified by the target device. (Park, see fig. 3; see paragraph 0064-0065 where authentication server 150 may transmit the generated certificate to the IoT device 110 (312)...transmit the received certificate and private key to the security module 120 and store the received certificate and private key in the security module 120 (314 and 316)...)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Tikhomirov and Park to provide the technique of generating signature information in response that authentication of the main control device passes based on the authentication information and transmitting the signature information to the target device through the main control device to perform network configuration processing on the target device by the main control device after the signature information is verified by the target device of Park in the system Tikhomirov in order to provide a strengthened environment in terms of device authentication (Park, see paragraph 0094).
Regarding claim 10, Tikhomirov-Park teaches wherein the generating of the signature information comprises: generating random signature information as the signature information. (Park, see paragraph 0062 where generate a certificate... the certificate may include...a random number…; see also paragraph 0071) The motivation regarding to the obviousness to claim 9 is also applied to claim 10.
Regarding claim 11, Tikhomirov-Park teaches wherein the authentication information comprises management account information of the target device; (Park, see figs. 3-4; see paragraph 0069 where verify the public key and the service ID (management account information) included in the certificate generation request received from the authentication center 140. For example, information (e.g., a service ID) on a service provided by the IoT service 170 may be registered in the cloud 160 in advance...)
the generating of the random signature information as the signature information comprises: storing the signature information and the management account information associatively. (Park, see figs. 3-4; see paragraph 0069 where verify the public key and the service ID (management account information) included in the certificate generation request received from the authentication center 140. For example, information (e.g., a service ID) on a service provided by the IoT service 170 may be registered in the cloud 160 in advance...; see paragraph 0074 where store the received certificate and private key (414).) The motivation regarding to the obviousness to claim 9 is also applied to claim 11.
Regarding claim 12, Tikhomirov-Park teaches wherein the generating of the signature information comprises: receiving device configuration information of the target device uploaded by the main control device; and (Tikhomirov, see figs. 9 and 13; see paragraphs 0299-0300 where device data is collected by means of the hub 310. The data can include the device ID and series, the device name, data on the manufacturer, a set of specifications (such as parameters of the device itself), MAC address, and other data...the information security domain of the IoT device is determined. In particular, domains include trusted, untrusted, and insecure devices...; see paragraph 0499 where when an unknown device is identified, the hub 310 reads the manufacturer ID and sends a request to the security service 1010 to search for similar device profiles from that manufacturer.)
generating the signature information based on the authentication information and the device configuration information. (Park, see fig. 3; see paragraph 0058 where transmit a certificate generation request including a device ID and the public key to the authentication server 150 (308)…; see paragraph 0060 where the authentication server 150 may verify the public key and the device ID included in the certificate generation request...The authentication server 150 may verify the validity of a corresponding device by comparing the device ID received from the cloud 160...; see paragraph 0060 where the authentication server 150 may generate a certificate (310)...) The motivation regarding to the obviousness to claim 9 is also applied to claim 12.
Regarding claim 14, Tikhomirov teaches A device network configuration method applied to a target device and comprising: transmitting device description information comprising device configuration information and flow information to a main control device, (Tikhomirov, see figs. 9 and 13; see paragraphs 0299-0300 where device data is collected by means of the hub 310. The data can include the device ID and series, the device name, data on the manufacturer, a set of specifications (such as parameters of the device itself), MAC address, and other data...the information security domain of the IoT device is determined. In particular, domains include trusted, untrusted, and insecure devices...; see paragraphs 0018-0019 where packets intended for changing the parameters of the IoT device...parameters for indicating a protocol type; parameters for indicating a network address or domain name; parameters for indicating a port number; parameters for indicating IPv4 or IPv6; parameters for indicating ID of device from or to which traffic is directed; and parameters for indicating an application; see paragraph 0380 the device data is collected...)
so that the main control device performs an authentication flow indicated by the flow information based on the device configuration information and (Tikhomirov, see figs. 9 and 13; see paragraph 0380 where the device data is collected to generate the device profile (performing authentication flow)...The profile can be generated as soon as a device is discovered, or as long as it takes to collect enough data for specific fields of the profile...)
However, Tikhomirov does not explicitly teach obtains signature information generated by a management server of the target device in response that authentication of the main control device by the management server passes;
wherein the authentication flow is a process in which the main control device is authenticated by the management server of the target device when the main control device performs network configuration to the target device;
receiving the signature information transmitted by the main control device; and verifying the signature information so that network configuration processing is performed on the target device by the main control device after the signature information is verified.
Park teaches obtains signature information generated by a management server of the target device in response that authentication of the main control device by the management server passes; (Park, see fig. 3; see paragraph 0058 where transmit a certificate generation request including a device ID and the public key to the authentication server 150 (308)…; see paragraph 0060 where the authentication server 150 may verify the public key and the device ID included in the certificate generation request...The authentication server 150 may verify the validity of a corresponding device by comparing the device ID received from the cloud 160...; see paragraph 0060 where the authentication server 150 may generate a certificate (310)...)
wherein the authentication flow is a process in which the main control device is authenticated by the management server of the target device when the main control device performs network configuration to the target device; (Park, see fig. 3; see paragraph 0035 a system 100 for performing device authentication in an IoT cloud may include at least one IoT device 110, an authentication center 140, an authentication server 150, a cloud 160, an IoT service (or an IoT service server) 170, a gateway 130, and a security module 120...; see paragraph 0057 start when the IoT device 110 requests the security module 120 to generate a key (302) (to perform network configuration)...transmit the generated public key to the IoT device 110 (306); see paragraph 0065 received certificate and private key to the security module 120 and store the received certificate and private key in the security module 120 (314 and 316)...)
receiving the signature information transmitted by the main control device; and verifying the signature information so that network configuration processing is performed on the target device by the main control device after the signature information is verified. (Park, see fig. 3; see paragraph 0064-0065 where authentication server 150 may transmit the generated certificate to the IoT device 110 (312)...transmit the received certificate and private key to the security module 120 and store the received certificate and private key in the security module 120 (314 and 316)...; see paragraph 0074 where Checking the certificate may be for checking the correspondence between information included in the certificate (e.g., the service ID) and information included in the certificate generation request signal by comparing the pieces of information with each other...)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Tikhomirov and Park to provide the technique of obtaining signature information generated by a management server of the target device in response that authentication of the main control device by the management server passes, wherein the authentication flow is a process in which the main control device is authenticated by the management server of the target device when the main control device performs network configuration to the target device, and receiving the signature information transmitted by the main control device and verifying the signature information so that network configuration processing is performed on the target device by the main control device after the signature information is verified of Park in the system Tikhomirov in order to provide a strengthened environment in terms of device authentication (Park, see paragraph 0094).
Regarding claim 16, Tikhomirov-Park teaches wherein the signature information is generated based on a target signature algorithm, and (Park, see fig. 3; see paragraph 0058 where transmit a certificate generation request including a device ID and the public key to the authentication server 150 (308)…; see paragraph 0060 where the authentication server 150 may verify the public key and the device ID included in the certificate generation request...The authentication server 150 may verify the validity of a corresponding device by comparing the device ID received from the cloud 160...; see paragraph 0060 where the authentication server 150 may generate a certificate (310)...)
the verifying of the signature information comprises: verifying the signature information based on the target signature algorithm. (Park, see fig. 3; see paragraph 0049 where Checking the certificate may be for checking the correspondence between information included in the certificate (e.g., the UID) and information included in the certificate generation request signal by comparing the pieces of information with each other...; see also paragraphs 0065 and 0074) The motivation regarding to the obviousness to claim 14 is also applied to claim 16.
Regarding claim 17, Tikhomirov-Park teaches wherein the verifying of the signature information so that the network configuration processing is performed on the target device by the main control device after the signature information is verified comprises: obtaining a network configuration parameter transmitted by the main control device; and (Park, see fig. 3; see paragraph 0049 where Checking the certificate may be for checking the correspondence between information included in the certificate (e.g., the UID) and information included in the certificate generation request signal by comparing the pieces of information with each other...; see also paragraphs 0065 and 0074)
verifying the signature information, to perform the network configuration processing on the target device based on the network configuration parameter after verifying the signature information. (Park, see fig. 3; see paragraph 0049 where Checking the certificate may be for checking the correspondence between information included in the certificate (e.g., the UID) and information included in the certificate generation request signal by comparing the pieces of information with each other...; see also paragraphs 0065 and 0074) The motivation regarding to the obviousness to claim 14 is also applied to claim 17.
Claims 3-4 and 6-7 are rejected under 35 U.S.C. 103 as being unpatentable over Tikhomirov-Park in view of Kim et al. (U.S. PGPub 2016/0142402).
Regarding claim 3, Tikhomirov-Park teaches wherein the device management information comprises a target network address, and (Tikhomirov, see figs. 9 and 13; see paragraph 0380 where the device data is collected to generate the device profile...The profile can be generated as soon as a device is discovered, or as long as it takes to collect enough data for specific fields of the profile...; see paragraphs 0428-0430 where if the parameters are in the form of IP addresses...describing the given IP addresses...; see paragraph 0468 where the first 3 octets of IP addresses to which traffic from the device is sent...; see paragraph 0352 where specific identifiers can be used to identify and track the device, such as a MAC address or factory identifier (DeviceID))
the performing of the authentication operation corresponding to the device management information and the obtaining of the signature information generated by the management server of the target device in response that the authentication of the main control device by the management server passes comprises: (Park, see fig. 3; see paragraph 0058 where transmit a certificate generation request including a device ID and the public key to the authentication server 150 (308)…; see paragraph 0060 where the authentication server 150 may verify the public key and the device ID included in the certificate generation request...The authentication server 150 may verify the validity of a corresponding device by comparing the device ID received from the cloud 160...; see paragraph 0060 where the authentication server 150 may generate a certificate (310)...)
receiving the signature information returned by the management server. (Park, see fig. 3; see paragraph 0058 where transmit a certificate generation request including a device ID and the public key to the authentication server 150 (308)…; see paragraph 0060 where the authentication server 150 may verify the public key and the device ID included in the certificate generation request...The authentication server 150 may verify the validity of a corresponding device by comparing the device ID received from (queried from) the cloud 160 (common server)...; see paragraph 0060 where the authentication server 150 may generate a certificate (310)...) The motivation regarding to the obviousness to claim 1 is also applied to claim 3.
However, Tikhomirov-Park does not explicitly teach performing the authentication operation based on the target network address so that the management server performs an authenticate operation on the main control device and generates the signature information in response that the authentication passes; and
Kim teaches performing the authentication operation based on the target network address so that the management server performs an authenticate operation on the main control device and generates the signature information in response that the authentication passes; and (Kim, see figs. 2-4; see paragraph 0099 where the authentication information may correspond to any information that the server 130 has generated...compare the MAC address received from the control device 105 to the MAC address received from the gateways 120 and 140 of the control areas and stored in advance, and then may determine whether to authenticate the control device 105..., when completing the authentication on the control device 105, an authentication identification message to the gateways 120 and 140 of the control areas.)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Tikhomirov-Park and Kim to provide the technique of performing the authentication operation based on the target network address so that the management server performs an authenticate operation on the main control device and generates the signature information in response that the authentication passes of Kim in the system of Tikhomirov-Park in order to prevent control and/or hacking by an unauthorized user (Kim, see paragraph 0008).
Regarding claim 4, Tikhomirov-Park-Kim teaches wherein the performing of the authentication operation based on the target network address so that the management server performs the authenticate operation on the main control device and generates the signature information in response that the authentication passes comprises: (Kim, see figs. 2-4; see paragraph 0099 where the authentication information may correspond to any information that the server 130 has generated...compare the MAC address received from the control device 105 to the MAC address received from the gateways 120 and 140 of the control areas and stored in advance, and then may determine whether to authenticate the control device 105..., when completing the authentication on the control device 105, an authentication identification message to the gateways 120 and 140 of the control areas.)
performing the authentication operation based on the target network address, so as to perform bidirectional authentication of a hyper text transfer protocol over secure socket layer with the management server and so as to trigger the management server to authenticate the main control device and to generate the signature information in response that the authentication passes. (Kim, see figs. 2-4; see paragraph 0099 where the authentication information may correspond to any information that the server 130 has generated...compare the MAC address received from the control device 105 to the MAC address received from the gateways 120 and 140 of the control areas and stored in advance, and then may determine whether to authenticate the control device 105..., when completing the authentication on the control device 105, an authentication identification message to the gateways 120 and 140 of the control areas.; It is noted that the limitations following the phrase "so as to" are not positively recited, but rather merely indicate the intentions of the preceding limitation) The motivation regarding to the obviousness to claim 3 is also applied to claim 4.
Regarding claim 6, Tikhomirov-Park-Kim teaches wherein the performing of the authentication operation based on the target network address so that the management server performs an authenticate operation on the main control device and generates the signature information in response that the authentication passes comprises: (Kim, see figs. 2-4; see paragraph 0099 where the authentication information may correspond to any information that the server 130 has generated...compare the MAC address received from the control device 105 to the MAC address received from the gateways 120 and 140 of the control areas and stored in advance, and then may determine whether to authenticate the control device 105..., when completing the authentication on the control device 105, an authentication identification message to the gateways 120 and 140 of the control areas.)
performing the authentication operation based on the target network address, so as to transmit management account information of the target device to the management server, and so as to trigger the management server to authenticate the main control device based on the management account information and to generate the signature information in response that the authentication passes. (Kim, see figs. 2-4; see paragraph 0099 where the authentication information may correspond to any information that the server 130 has generated...compare the MAC address received from the control device 105 to the MAC address received from the gateways 120 and 140 of the control areas and stored in advance, and then may determine whether to authenticate the control device 105..., when completing the authentication on the control device 105, an authentication identification message to the gateways 120 and 140 of the control areas.; It is noted that the limitations following the phrase "so as to" are not positively recited, but rather merely indicate the intention of the preceding limitation) The motivation regarding to the obviousness to claim 3 is also applied to claim 6.
Regarding claim 7, Tikhomirov-Park-Kim teaches wherein the performing of the authentication operation based on the target network address comprises: enabling a target application program based on the target network address; and (Kim, see figs. 2-4; see paragraph 0099 where the authentication information may correspond to any information that the server 130 has generated...compare the MAC address received from the control device 105 to the MAC address received from the gateways 120 and 140 of the control areas and stored in advance, and then may determine whether to authenticate the control device 105..., transmit (enabling an application program), when completing the authentication on the control device 105, an authentication identification message to the gateways 120 and 140 of the control areas.)
performing the authentication operation based on the target application program. (Kim, see figs. 2-4; see paragraph 0150 where grants a control authority for the control device 400, based on the received authentication identification message. That is, if the authentication method of the control area is an equipment authentication, the control gateway 420 may determine the number of equipment to be authenticated in the control area....) The motivation regarding to the obviousness to claim 3 is also applied to claim 7.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Tikhomirov-Park-Kim in view of Hershberg et al. (U.S. PGPub 2014/0165147).
Regarding claim 5, Tikhomirov-Park-Kim teaches all of the features of claim 4. However, Tikhomirov-Park-Kim does not explicitly teach wherein the performing of the bidirectional authentication of the hyper text transfer protocol over secure socket layer with the management server comprises: performing the bidirectional authentication of the hyper text transfer protocol over secure socket layer with the management server based on a device certificate of the main control device,
wherein a validity period of the device certificate is less than a preset threshold value, and the device certificate is generated by an ecological server of the main control device.
Hershberg teaches wherein the performing of the bidirectional authentication of the hyper text transfer protocol over secure socket layer with the management server comprises: performing the bidirectional authentication of the hyper text transfer protocol over secure socket layer with the management server based on a device certificate of the main control device, (Hershberg, see figs. 2-3; see paragraph 0071 where part of the SSL handshake for establishing the HTTPS connection, the client device 102 sends the session certificate associated to the web server 112 to authenticate the user...Upon receiving the session certificate, the web server sends a query to an AAA server to validate the session certificate (505)...that the session certificate is not valid.)
wherein a validity period of the device certificate is less than a preset threshold value, and the device certificate is generated by an ecological server of the main control device. (Hershberg, see figs. 2-3; see paragraph 0054 where stores the certificate expiry time or validity period of the session certificate associated with the entry. If the certificate expiry time of the associated session certificate is a time that is in the past compared to the present time, then the session certificate has expired.; see paragraph 0071 where the CA who generated the session certificate...the query when the pre-determined validity period indicated on the session certificate has not expired...)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Tikhomirov-Park-Kim and Hershberg to provide the technique of the performing of the bidirectional authentication of the hyper text transfer protocol over secure socket layer with the management server comprises performing the bidirectional authentication of the hyper text transfer protocol over secure socket layer with the management server based on a device certificate of the main control device, and a validity period of the device certificate is less than a preset threshold value, and the device certificate is generated by an ecological server of the main control device of Hershberg in the system of Tikhomirov-Park-Kim in order to increase security for establishing secure connections (Hershberg, see paragraph 0037).
Claims 13 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Tikhomirov-Park in view of Hershberg et al. (U.S. PGPub 2014/0165147).
Regarding claim 13, Tikhomirov-Park teaches the generating of the signature information based on the authentication information and the device configuration information comprises: performing signature processing on the authentication parameter and the device configuration information based on a target signature algorithm to generate the signature information. (Park, see fig. 3; see paragraph 0058 where transmit a certificate generation request including a device ID and the public key to the authentication server 150 (308)…; see paragraph 0060 where the authentication server 150 may verify the public key and the device ID included in the certificate generation request...The authentication server 150 may verify the validity of a corresponding device by comparing the device ID received from the cloud 160...; see paragraph 0060 where the authentication server 150 may generate a certificate (310)...) The motivation regarding to the obviousness to claim 9 is also applied to claim 13.
However, Tikhomirov-Park does not explicitly teach wherein the authentication information comprises an authentication parameter used when the main control device performs bidirectional authentication of a hyper text transfer protocol over secure socket layer with the management server;
Hershberg teaches wherein the authentication information comprises an authentication parameter used when the main control device performs bidirectional authentication of a hyper text transfer protocol over secure socket layer with the management server; (Hershberg, see figs. 2-3; see paragraph 0071 where part of the SSL handshake for establishing the HTTPS connection, the client device 102 sends the session certificate associated to the web server 112 to authenticate the user...Upon receiving the session certificate, the web server sends a query to an AAA server to validate the session certificate (505)...that the session certificate is not valid.)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Tikhomirov-Park and Hershberg to provide the technique of the authentication information comprises an authentication parameter used when the main control device performs bidirectional authentication of a hyper text transfer protocol over secure socket layer with the management server of Hershberg in the system of Tikhomirov-Park in order to increase security for establishing secure connections (Hershberg, see paragraph 0037).
Regarding claim 15, Tikhomirov-Park teaches all of the features of claim 14. However, Tikhomirov-Park does not explicitly teach wherein the verifying of the signature information comprises: validating the signature information through the management server.
Hershberg teaches wherein the verifying of the signature information comprises: validating the signature information through the management server. (Hershberg, see figs. 2-3; see paragraph 0071 where part of the SSL handshake for establishing the HTTPS connection, the client device 102 sends the session certificate associated to the web server 112 to authenticate the user...Upon receiving the session certificate, the web server sends a query to an AAA server to validate the session certificate (505)...that the session certificate is not valid.)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Tikhomirov-Park and Hershberg to provide the technique of the verifying of the signature information comprises validating the signature information through the management server of Hershberg in the system of Tikhomirov-Park in order to increase security for establishing secure connections (Hershberg, see paragraph 0037).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MENG VANG whose telephone number is (571)270-7023. The examiner can normally be reached M-F 8AM-2PM, 3PM-5PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, NICHOLAS TAYLOR can be reached at (571) 272-3889. 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.
/MENG VANG/Primary Examiner, Art Unit 2443