DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
The following claim(s) is/are pending in this office action: 1, 3-9, 11-17, 19-25, 27-30
The following claim(s) is/are amended: 1, 4-5, 9, 12-13, 17, 20-21, 25, 28-29
The following claim(s) is/are cancelled: 2, 10, 18, 26
The following claim(s) is/are new: -
Claim(s) 1, 3-9, 11-17, 19-25, 27-30 is/are rejected.
Response to Arguments
Applicant’s arguments filed in the amendment filed 12/17/2025, have been fully considered but are moot in view of new grounds of rejection. The reasons set forth below.
Applicant’s Invention as Claimed
Claim Rejections - 35 USC § 103
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 of this title, 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-9, 11-17, 19-25, and 27-30 are rejected under 35 U.S.C. 103 as being unpatentable over Morita (US Pub. 2016/0219051) in view of Fu (US Pub. 2008/0046732) and further in view of Purohit (US Pub. 2016/0080416).
With respect to Claim 1, Morita teaches a method comprising: sending, to an authentication server, authentication requests of a plurality of nodes (Figs. 1, 5, paras. 50-53; Node B collects identification information of Nodes C and D and sends it to Node A. Node A sends Node A-D information to the authentication apparatus. The authentication apparatus verifies the nodes. See also Fig. 3, para. 62; broker server collectively receives the authentication requests from the apparatus and distributes them to authentication servers of the makers.)
of an in-vehicle system (Fig. 3, para. 61; in-vehicle network)
wherein the first key information comprises a registration key of the secondary authentication node, (paras. 51-60, 80, 109; Authentication apparatus with white list uses encrypted device ID and shared key which were written to the device to authenticate the device. Therefore the shared key is a registration key that is also a symmetric key.)
wherein the registration key is an encrypted symmetric key of the secondary authentication node when a key type of the secondary authentication node is a symmetric key, (paras. 51-60, 80, 109; Authentication apparatus with white list uses encrypted device ID and shared key which were written to the device to authenticate the device. Therefore the shared key is a registration key that is also a symmetric key. See also Fu, Para. 58-63; mutual authentication uses the MAC addresses and nonce values from both devices, which are first identifiers and first key information of the other node. Para. 23, 53-55; a shared secret key (SSK) for communication between two devices is created, and encrypted using the SMK and sent to the devices. i.e., a SSK for Nodes 2 and 4 is encrypted with the SMK for Node 2 and sent to Node 2, and encrypted with the SMK for Node 4 and sent to Node 4. To the extent that some dependent claims require the key itself to be transmitted rather than derived, it would have been obvious to one of ordinary skill prior to the effective filing date to simply use a shared secret key based on MAC addresses in order to avoid having to derive temporal keys.)
and wherein the registration key is a public key of the secondary authentication node when the key type is an asymmetric key; (para. 59; system may use a public key instead, which is an asymmetric key system.)
when the in-vehicle system has started; (paras. 79-81, 101-102; authentication occurs when apparatus X/Y (which are vehicles) start up.)
Obtaining, by the authentication server, second key information (paras. 51-60, 80, 109; Authentication apparatus with white list uses encrypted device ID and shared key which were written to the device to authenticate the device. Therefore the shared key is a registration key that is also a symmetric key.)
of a replacement node, wherein the replacement node is another subnode of the secondary authentication node; (Figs. 11-12, paras. 74-76; New Node E sends ticket and request to be authenticated to the authentication server. See also Fig. 7, paras. 68-69; new lower node sends authentication information to authentication apparatus. To the extent a new node is not a replacement node Examiner takes official notice of vehicle replacement parts and it would have been obvious to one of ordinary skill prior to the effective filing date to authenticate replacement parts in the same manner as new parts in order to allow for authenticated communication with the replacement parts.)
Receiving, by the authentication server, an authentication request from the replacement node; and (Figs. 1, 5, paras. 50-53; Node B collects identification information of Nodes C and D and sends it to Node A. Node A sends Node A-D information to the authentication apparatus. The authentication apparatus verifies the nodes. See also Fig. 3, para. 62; broker server collectively receives the authentication requests from the apparatus and distributes them to authentication servers of the makers.)
But Morita does not explicitly teach receiving, in response to authentication on the nodes succeeding by a primary authentication node of the nodes, and from the authentication server, a first identifier of a secondary authentication node of the nodes and first key information of the secondary authentication node; and performing, by the primary authentication node, authentication on the secondary authentication node based on the first identifier, and the first key information.
Fu, however, does teach receiving, in response to authentication on the nodes succeeding by a primary authentication node of the nodes, (Examiner asserts no teaching is necessary here since there is no structural or functional limitations. Regardless, Examiner cites para. 49; any node could be an AAA or a common trust node.)
and from the authentication server, a first identifier of a secondary authentication node of the nodes and first key information of the secondary authentication node, (Figs. 1, 4, paras. 21-22, 49-52; each node authenticates with authentication server and establishes a shared master key (SMK) with the server which is device specific. Para. 23, 53-55; a shared secret key (SSK) for communication between two devices is created, and encrypted using the SMK and sent to the devices. i.e., a SSK for Nodes 2 and 4 is encrypted with the SMK for Node 2 and sent to Node 2, and encrypted with the SMK for Node 4 and sent to Node 4. Para. 24, 56; SSK is then used to generate a temporal key to mutually authenticate nodes for communication. Para. 58-63; mutual authentication uses the MAC addresses and nonce values from both devices, which are first identifiers and first key information of the other node. See also Morita, paras. 51-60, 80, 109; Authentication apparatus with white list uses encrypted device ID and shared key which were written to the device to authenticate the device. Therefore the shared key is a registration key that is also a symmetric key. To the extent that some dependent claims require the key itself to be transmitted rather than derived, it would have been obvious to one of ordinary skill prior to the effective filing date to simply use a shared secret key based on MAC addresses in order to avoid having to derive temporal keys.)
and performing, by the primary authentication node, authentication on the secondary authentication node based on the first identifier, and the first key information (paras. 33, 56, 63; communicating devices perform mutual authentication on each other. para. 58-63; mutual authentication uses the MAC addresses and nonce values from both devices, which are first identifiers and first key information of the other node. See also Morita, paras. 51-60, 80, 109; Authentication apparatus with white list uses encrypted device ID and shared key which were written to the device to authenticate the device. para. 59; system may use a public key instead, which is an asymmetric key system.)
receiving, from the authentication server, a second identifier of a subnode of the secondary authentication node and an authentication key for the subnode to perform authentication on the subnode (Fig. 1, para. 20; nodes are one, two or three hops from the IAP, therefore some nodes are subnodes of other nodes. paras. 22-23, 53-55; Nodes authenticate with authentication server. A shared master key is created that particular node and a shared secret key is created for the communication pair. The shared secret key is encrypted with the master key so only the receiving node can read it. Therefore, using Fig. 1 as an example, if Node 2 was to communicate with Node 4, it would receive a shared secret key that it would be told to use to communicate with Node 4. In addition, since Node 4 is its subordinate, it would receive the shared secret key encrypted for Node 4 as well.)
a third identifier and (Para. 58-63; Authentication uses the MAC addresses and nonce values from both devices, which are identifiers and key information.)
Sending, by the authentication server, an authentication response for the replacement node based on the third identifier and the second key information of the replacement node. (Fig. 1, para. 20; nodes are one, two or three hops from the IAP, therefore some nodes are subnodes of other nodes. paras. 22-23, 53-55; Nodes authenticate with authentication server. A shared master key is created that particular node and a shared secret key is created for the communication pair. The shared secret key is encrypted with the master key so only the receiving node can read it. Therefore, using Fig. 1 as an example, if Node 2 was to communicate with Node 4, it would receive a shared secret key that it would be told to use to communicate with Node 4. In addition, since Node 4 is its subordinate, it would receive the shared secret key encrypted for Node 4 as well.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of Morita with the receipt of identifier and key information of the second node in order to perform mutual authentication. (Fu, para. 33)
But modified Morita does not explicitly teach wherein all subnodes of the secondary authentication node share the same authentication key.
Purohit, however, does teach wherein all subnodes of the secondary authentication node share the same authentication key. (paras. 17, 32-35, 42; node in a group receives a group key and forwards it to children. All nodes use the same group key to encrypt and decrypt payloads of packets.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of modified Morita with the subnodes sharing an authentication key in order to improve security for group addressed data packets. (Purohit, paras. 2-6) Further, a group key is a simple substitute for predictable results over using a series of pair-wise keys as in Fu, see MPEP 2143(I)(B), because both key techniques were known in the art and both provided security to messages within the devices involved.
With respect to Claim 3, modified Morita teaches the method of claim 1, and Fu also teaches further comprising: receiving, by the subnode and from the authentication server, the first identifier and the authentication key; (Para. 58-63; mutual authentication uses the MAC addresses and nonce values from both devices, which are first identifiers and first key information of the other node. It would have been obvious to one of ordinary skill prior to the effective filing date to have the authentication server rather than the secondary authentication node authenticate the secondary authentication node because it is a simple substitution for expected results (see MPEP 2143(I)(B) because both devices have access to the information. Using a common trust node is known in the art, see Fu, paras. 39-42)
and performing, by the secondary authentication node, authentication on the subnode. (paras. 33, 56, 63; communicating devices perform mutual authentication on each other.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 4, modified Morita teaches the method of claim 1, and Purohit also teaches wherein the second key information of the replacement node comprises the same authentication key (paras. 17, 32-35, 42; node in a group receives a group key and forwards it to children. All nodes use the same group key to encrypt and decrypt payloads of packets.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 5, modified Morita teaches the method of claim 1, and Fu also teaches wherein in response to authentication on the replacement node succeeding and the replacement node having a parent node, (Authentication success was previously taught. Fig. 1, para. 20; nodes are one, two or three hops from the IAP, therefore some nodes are subnodes of other nodes.)
the method further comprises: receiving, by the parent node and from the authentication server, the third identifier of the replacement node and the second key information of the replacement node; (Replacement nodes were previously taught. Fig. 1, para. 20; nodes are one, two or three hops from the IAP, therefore some nodes are subnodes of other nodes. paras. 22-23, 53-55; Nodes authenticate with authentication server. A shared master key is created that particular node and a shared secret key is created for the communication pair. The shared secret key is encrypted with the master key so only the receiving node can read it. Therefore, using Fig. 1 as an example, if Node 2 was to communicate with Node 4, it would receive a shared secret key that it would be told to use to communicate with Node 4. In addition, since Node 4 is its subordinate, it would receive the shared secret key encrypted for Node 4 as well.)
receiving, by the replacement node and from the authentication server, a fourth identifier of the parent node and third key information of the parent node; (Para. 58-63; mutual authentication uses the MAC addresses and nonce values from both devices, which are first identifiers and first key information of the other node. It would have been obvious to one of ordinary skill prior to the effective filing date to have the authentication server rather than the parent node authenticate the parent node because it is a simple substitution for expected results (see MPEP 2143(I)(B) because both devices have access to the information. Using a common trust node is known in the art, see Fu, paras. 39-42)
and performing, by the replacement node and using the third identifier, the second key information, the fourth identifier, and the third key information, two-way authentication on the parent node. (paras. 33, 56, 63; communicating devices perform mutual authentication on each other. Para. 58-63; mutual authentication uses the MAC addresses and nonce values from both devices, which are first identifiers and first key information of the other node. To the extent that some dependent claims require the key itself to be transmitted rather than derived, it would have been obvious to one of ordinary skill prior to the effective filing date to simply use a shared secret key based on MAC addresses in order to avoid having to derive temporal keys.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 6, modified Morita teaches the method of claim 5, and Fu also teaches wherein each of the second key information and the third key information comprises the authentication key in response to the replacement node being the subnode of the secondary authentication node. (Fig. 1, para. 20; nodes are one, two or three hops from the IAP, therefore some nodes are subnodes of other nodes. paras. 22-23, 53-55; Nodes authenticate with authentication server. A shared master key is created that particular node and a shared secret key is created for the communication pair. See also Purohit, paras. 17, 32-35, 42; group key.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 7, modified Morita teaches the method of claim 5, and Fu also teaches wherein in response to the two-way authentication on the parent node succeeding and the replacement node having the subnode, the method further comprises: receiving, by the replacement node and from the authentication server, a fifth identifier of the subnode and fourth key information of the subnode; (Fig. 1, para. 20; nodes are one, two or three hops from the IAP, therefore some nodes are subnodes of other nodes. paras. 22-23, 53-55; Nodes authenticate with authentication server. A shared master key is created that particular node and a shared secret key is created for the communication pair. The shared secret key is encrypted with the master key so only the receiving node can read it. Therefore, using Fig. 1 as an example, if Node 2 was to communicate with Node 4, it would receive a shared secret key that it would be told to use to communicate with Node 4. In addition, since Node 4 is its subordinate, it would receive the shared secret key encrypted for Node 4 as well.)
receiving, by the subnode and from the authentication server, the second identifier and the second key information; (Para. 58-63; mutual authentication uses the MAC addresses and nonce values from both devices, which are first identifiers and first key information of the other node. It would have been obvious to one of ordinary skill prior to the effective filing date to have the authentication server rather than the secondary authentication node authenticate the secondary authentication node because it is a simple substitution for expected results (see MPEP 2143(I)(B) because both devices have access to the information. Using a common trust node is known in the art, see Fu, paras. 39-42)
and performing, by the replacement node and using the fifth identifier, the fourth key information, the second identifier, and the second key information, two-way authentication on the subnode. (paras. 33, 56, 63; communicating devices perform mutual authentication on each other. Para. 58-63; mutual authentication uses the MAC addresses and nonce values from both devices, which are first identifiers and first key information of the other node. To the extent that some dependent claims require the key itself to be transmitted rather than derived, it would have been obvious to one of ordinary skill prior to the effective filing date to simply use a shared secret key based on MAC addresses in order to avoid having to derive temporal keys.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 8, modified Morita teaches the method of claim 7, and Fu also teaches further: comprising sending, by the replacement node and to the authentication server, an authentication complete message in response to the two-way authentication on the parent node succeeding or in response to the two-way authentication on the parent node succeeding and the two-way authentication on the subnode succeeding. (para. 63; device sends acknowledgement to indicate that setup is complete. It would have been obvious to one of ordinary skill prior to the effective filing date to inform the authentication server that setup is complete so that the server has an accurate view of the communication channels in the vehicle.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 9, it is substantially similar to Claim 1 and is rejected in the same manner, the same art and reasoning applying. Further, Morita teaches a vehicle-mounted device, comprising: a memory configured to store instructions; and a processor coupled to the memory, wherein when executed by the processor, the instructions cause the vehicle-mounted device to be configured to: (paras. 57; device has memory and processor)
With respect to Claims 11-16, they are substantially similar to Claims 3-8, respectively, and are rejected in the same manner, the same art and reasoning applying.
With respect to Claim 17, it is substantially similar to Claim 1 and is rejected in the same manner, the same art and reasoning applying. Further, Morita teaches a computer program product comprising computer-executable instructions that are stored on a non-transitory computer readable medium and that, when executed by a processor, cause an in-vehicle system to: (para. 57; device with memory, processor, ROM and storage apparatus.)
With respect to Claims 19-24, they are substantially similar to Claims 3-8, respectively, and are rejected in the same manner, the same art and reasoning applying.
With respect to Claim 25, Morita teaches an authentication server comprising: (paras. 50-53, 62; authentication servers. See also Fu, Figs. 1, 4, paras. 21-22, 49-52; each node authenticates with authentication server)
a memory configured to store instructions; and a processor coupled to the memory, wherein when executed by the processor, the instructions cause the authentication server to be configured to: (paras. 57; device has memory and processor)
obtain information about a plurality of nodes of an in-vehicle system; receive, from the nodes, authentication requests; when the in-vehicle system has started: perform authentication on the nodes; (Fig. 3, para. 61; in-vehicle network. Figs. 1, 5, paras. 50-53; Node B collects identification information of Nodes C and D and sends it to Node A. Node A sends Node A-D information to the authentication apparatus. The authentication apparatus verifies the nodes. See also Fig. 3, para. 62; broker server collectively receives the authentication requests from the apparatus and distributes them to authentication servers of the makers. paras. 79-81, 101-102; authentication occurs when apparatus X/Y (which are vehicles) start up.)
to a primary authentication node of the nodes, (Examiner asserts no teaching is necessary here since there is no structural or functional limitations. Regardless, Examiner cites para. 49; any node could be an AAA or a common trust node.)
wherein the first key information comprises a registration key of the secondary authentication node, (paras. 51-60, 80, 109; Authentication apparatus with white list uses encrypted device ID and shared key which were written to the device to authenticate the device. Therefore the shared key is a registration key that is also a symmetric key.)
wherein the registration key is an encrypted symmetric key of the secondary authentication node when a key type of the secondary authentication node is a symmetric key, (paras. 51-60, 80, 109; Authentication apparatus with white list uses encrypted device ID and shared key which were written to the device to authenticate the device. Therefore the shared key is a registration key that is also a symmetric key. See also Fu, Para. 58-63; mutual authentication uses the MAC addresses and nonce values from both devices, which are first identifiers and first key information of the other node. Para. 23, 53-55; a shared secret key (SSK) for communication between two devices is created, and encrypted using the SMK and sent to the devices. i.e., a SSK for Nodes 2 and 4 is encrypted with the SMK for Node 2 and sent to Node 2, and encrypted with the SMK for Node 4 and sent to Node 4. To the extent that some dependent claims require the key itself to be transmitted rather than derived, it would have been obvious to one of ordinary skill prior to the effective filing date to simply use a shared secret key based on MAC addresses in order to avoid having to derive temporal keys.)
and wherein the registration key is a public key of the secondary authentication node when the key type is an asymmetric key; (para. 59; system may use a public key instead, which is an asymmetric key system.)
when the in-vehicle system has been started. (paras. 79-81, 101-102; authentication occurs when apparatus X/Y (which are vehicles) start up.)
Obtain second key information (paras. 51-60, 80, 109; Authentication apparatus with white list uses encrypted device ID and shared key which were written to the device to authenticate the device. Therefore the shared key is a registration key that is also a symmetric key.)
of the replacement node; (Figs. 11-12, paras. 74-76; New Node E sends ticket and request to be authenticated to the authentication server. See also Fig. 7, paras. 68-69; new lower node sends authentication information to authentication apparatus. To the extent a new node is not a replacement node Examiner takes official notice of vehicle replacement parts and it would have been obvious to one of ordinary skill prior to the effective filing date to authenticate replacement parts in the same manner as new parts in order to allow for authenticated communication with the replacement parts.)
Receive an authentication request from the replacement node; and (Figs. 1, 5, paras. 50-53; Node B collects identification information of Nodes C and D and sends it to Node A. Node A sends Node A-D information to the authentication apparatus. The authentication apparatus verifies the nodes. See also Fig. 3, para. 62; broker server collectively receives the authentication requests from the apparatus and distributes them to authentication servers of the makers.)
But Morita does not explicitly teach send, to a primary authentication node of the nodes and when the authentication succeeds, a first identifier of a secondary authentication node of the nodes and first key information of the secondary authentication node; and perform authentication on the secondary authentication node based on the first identifier and the first key information.
Fu, however, does teach and send, to a primary authentication node of the nodes and when the authentication succeeds, a first identifier of a secondary authentication node of the nodes and first key information of the secondary authentication node; and (Figs. 1, 4, paras. 21-22, 49-52; each node authenticates with authentication server and establishes a shared master key (SMK) with the server which is device specific. Para. 23, 53-55; a shared secret key (SSK) for communication between two devices is created, and encrypted using the SMK and sent to the devices. i.e., a SSK for Nodes 2 and 4 is encrypted with the SMK for Node 2 and sent to Node 2, and encrypted with the SMK for Node 4 and sent to Node 4. Para. 24, 56; SSK is then used to generate a temporal key to mutually authenticate nodes for communication. Para. 58-63; mutual authentication uses the MAC addresses and nonce values from both devices, which are first identifiers and first key information of the other node. See also Morita, paras. 51-60, 80, 109; Authentication apparatus with white list uses encrypted device ID and shared key which were written to the device to authenticate the device. Therefore the shared key is a registration key that is also a symmetric key. To the extent that some dependent claims require the key itself to be transmitted rather than derived, it would have been obvious to one of ordinary skill prior to the effective filing date to simply use a shared secret key based on MAC addresses in order to avoid having to derive temporal keys.)
perform authentication on the secondary authentication node based on the first identifier, and the first key information (paras. 33, 56, 63; communicating devices perform mutual authentication on each other. para. 58-63; mutual authentication uses the MAC addresses and nonce values from both devices, which are first identifiers and first key information of the other node. See also Morita, paras. 51-60, 80, 109; Authentication apparatus with white list uses encrypted device ID and shared key which were written to the device to authenticate the device. para. 59; system may use a public key instead, which is an asymmetric key system.)
generate an authentication key for a subnode of the secondary authentication node and a second identifier of the subnode; and send the second identifier and the authentication key to the secondary authentication node to perform authentication on the subnode; (Fig. 1, para. 20; nodes are one, two or three hops from the IAP, therefore some nodes are subnodes of other nodes. paras. 22-23, 53-55; Nodes authenticate with authentication server. A shared master key is created that particular node and a shared secret key is created for the communication pair. The shared secret key is encrypted with the master key so only the receiving node can read it. Therefore, using Fig. 1 as an example, if Node 2 was to communicate with Node 4, it would receive a shared secret key that it would be told to use to communicate with Node 4. In addition, since Node 4 is its subordinate, it would receive the shared secret key encrypted for Node 4 as well.)
a third identifier of a replacement node and (Para. 58-63; Authentication uses the MAC addresses and nonce values from both devices, which are identifiers and key information.)
Send an authentication response for the replacement node based on the third identifier and the second key information. (Fig. 1, para. 20; nodes are one, two or three hops from the IAP, therefore some nodes are subnodes of other nodes. paras. 22-23, 53-55; Nodes authenticate with authentication server. A shared master key is created that particular node and a shared secret key is created for the communication pair. The shared secret key is encrypted with the master key so only the receiving node can read it. Therefore, using Fig. 1 as an example, if Node 2 was to communicate with Node 4, it would receive a shared secret key that it would be told to use to communicate with Node 4. In addition, since Node 4 is its subordinate, it would receive the shared secret key encrypted for Node 4 as well.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the server of Morita with the sending of identifier and key information of the second node in order to perform mutual authentication. (Fu, para. 33)
But modified Morita does not explicitly teach wherein subnodes of the secondary authentication node share the same authentication key.
Purohit, however, does teach wherein subnodes of the secondary authentication node share the same authentication key. (paras. 17, 32-35, 42; node in a group receives a group key and forwards it to children. All nodes use the same group key to encrypt and decrypt payloads of packets.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of modified Morita with the subnodes sharing an authentication key in order to improve security for group addressed data packets. (Purohit, paras. 2-6) Further, a group key is a simple substitute for predictable results over using a series of pair-wise keys as in Fu, see MPEP 2143(I)(B), because both key techniques were known in the art and both provided security to messages within the devices involved.
With respect to Claim 27, modified Morita teaches the authentication server of claim 25, and Fu also teaches wherein when executed by the processor, the instructions further cause the authentication server to be configured to send the first identifier and the authentication key to the subnode. (Para. 58-63; mutual authentication uses the MAC addresses and nonce values from both devices, which are first identifiers and first key information of the other node. It would have been obvious to one of ordinary skill prior to the effective filing date to have the authentication server rather than the secondary authentication node authenticate the secondary authentication node because it is a simple substitution for expected results (see MPEP 2143(I)(B) because both devices have access to the information. Using a common trust node is known in the art, see Fu, paras. 39-42)
The same motivation to combine as the independent claim applies here.
With respect to Claim 28, modified Morita teaches the authentication server of claim 25, and Purohit also teaches wherein the second key information of the replacement node comprises the same authentication key (paras. 17, 32-35, 42; node in a group receives a group key and forwards it to children. All nodes use the same group key to encrypt and decrypt payloads of packets.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 29, modified Morita teaches the authentication server of claim 25, and Fu also teaches wherein in response to the authentication on the replacement node succeeding and the replacement node having a parent node, (Authentication success was previously taught. Fig. 1, para. 20; nodes are one, two or three hops from the IAP, therefore some nodes are subnodes of other nodes.)
when executed by the processor, the instructions further cause the authentication server to be configured to: send the second identifier and the second key information to the parent node; (Replacement nodes were previously taught. Fig. 1, para. 20; nodes are one, two or three hops from the IAP, therefore some nodes are subnodes of other nodes. paras. 22-23, 53-55; Nodes authenticate with authentication server. A shared master key is created that particular node and a shared secret key is created for the communication pair. The shared secret key is encrypted with the master key so only the receiving node can read it. Therefore, using Fig. 1 as an example, if Node 2 was to communicate with Node 4, it would receive a shared secret key that it would be told to use to communicate with Node 4. In addition, since Node 4 is its subordinate, it would receive the shared secret key encrypted for Node 4 as well.)
and send a fourth identifier of the parent node and third key information of the parent node to the replacement node. (Para. 58-63; mutual authentication uses the MAC addresses and nonce values from both devices, which are first identifiers and first key information of the other node. It would have been obvious to one of ordinary skill prior to the effective filing date to have the authentication server rather than the parent node authenticate the parent node because it is a simple substitution for expected results (see MPEP 2143(I)(B) because both devices have access to the information. Using a common trust node is known in the art, see Fu, paras. 39-42)
The same motivation to combine as the independent claim applies here.
With respect to Claim 30, modified Morita teaches the authentication server of claim 29, and Fu also teaches wherein each of the second key information and the third key information comprises the authentication key. (Fig. 1, para. 20; nodes are one, two or three hops from the IAP, therefore some nodes are subnodes of other nodes. paras. 22-23, 53-55; Nodes authenticate with authentication server. A shared master key is created that particular node and a shared secret key is created for the communication pair. See also Purohit, paras. 17, 32-35, 42; group key.)
The same motivation to combine as the independent claim applies here.
Alternate Grounds
Claims 1, 3-9, 11-17, 19-25, and 27-30 are rejected under 35 U.S.C. 103 as being unpatentable over Morita (US Pub. 2016/0219051) in view of Fu (US Pub. 2008/0046732) in view of Purohit (US Pub. 2016/0080416) and further in view of Baghdasaryan (US Pub. 2014/0189828).
With respect to Claim 1, Morita, Fu and Purohit teach as above, but under this ground of rejection do not explicitly teach wherein the first key information comprises a registration key of the secondary authentication node, wherein the registration key is an encrypted symmetric key of the secondary authentication node when a key type of the secondary authentication node is a symmetric key, and wherein the registration key is a public key of the secondary authentication node when the key type is an asymmetric key.
Baghdasaryan, however, does teach wherein the first key information comprises a registration key of the secondary authentication node, wherein the registration key is an encrypted symmetric key of the secondary authentication node when a key type of the secondary authentication node is a symmetric key, and wherein the registration key is a public key of the secondary authentication node when the key type is an asymmetric key. (para. 44, 60, 78; registration involves creating encrypted symmetric or asymmetric key including public key if asymmetric type.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of modified Morita with the symmetric and asymmetric registration key in order to improve authentication by provisioning or authenticating multiple devices at the same time. (Baghdasaryan, paras. 23-25)
The same teaching would apply, mutatis mutandis, to all other claims.
Claims 1, 3-9, 11-17, 19-25, and 27-30 are rejected under 35 U.S.C. 103 as being unpatentable over Morita (US Pub. 2016/0219051) in view of Fu (US Pub. 2008/0046732) in view of Purohit (US Pub. 2016/0080416) and further in view of Segawa (US Pub. 2017/0099201).
With respect to Claim 1, Morita, Fu and Purohit teach as above, but under this ground of rejection do not explicitly teach a replacement node.
Segawa, however, does teach a replacement node (para. 27; communication nodes such as ECUs may be replaced for repair. Paras. 37-38; an ECU may be newly added to the vehicle communication network. paras. 6, 78-79, 94-96; authentication of a newly connected ECU.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of modified Morita with replacement node in order to compensate for nodes needing repair. (Segawa, para. 27)
The same teaching would apply, mutatis mutandis, to all other claims.
Remarks
Applicant argues at Remarks, pg. 14 that the amended independent claims strike the language that Examiner considered new matter and that the 112a rejection should be withdrawn. Examiner agrees and withdraws the rejection.
Applicant argues at Remarks, pgs. 14-18 that the claims are nonobvious because “Morita does not disclose a replacement node.” Applicant acknowledges that Morita discloses “the onboarding of a newly coupled node.” Applicant argues that Morita does not disclose “treating the newly coupled node as a replacement for an existing authenticated node.”
Examiner maintains the rejection. Applicant acknowledges that Morita discloses onboarding a new node. The authentication for a new node is similar to the authentication for an existing node in Morita. Fu similarly makes no mention of a treating replacement devices differently vis-à-vis authentication than original devices. Applicant’s claim does the same – In the claim, the subnode of a secondary authentication node had “a second identifier” and “an authentication key, where all subnodes of the secondary authentication node share the same authentication key.” The claim then claims “a replacement node…wherein the replacement node is another subnode of the secondary authentication node.” That node is also limited to its own identifier (“a third identifier”) and the same key group key (“second key information”). See Claim 6; “wherein each of the second key information and the third key information comprises the authentication key in response to the replacement node being the subnode of the secondary authentication node.” Therefore, both the claims and the prior art treat a replacement node in the same manner they treat any other subnode, i.e. devices are authenticated similarly whether they are existing devices or new devices.
Consequently, the only thing missing from the prior art teaching is the notion that the new node “replaces” an existing node, which Examiner takes as a removal of a previous node and the inserting of a new node that performs a same or similar function. As an initial point, Examiner fails to see how the word works any untaught limitation on the claim at all. Presumably, one embodiment of a replacement node is subnode with the same structure as a previous subnode. Examiner previously taught a subnode, and if there is no structural difference Examiner fails to see how the system structure has changed. A system claim is judged by the structure and a system with the same structure is no less obvious than the previous one. In other words, Applicant does not dispute the teaching of an identifier and an authentication key for a subnode in the earlier limitation, and Applicant does not explain how the identifier, key, or structure of a replacement node differs from that of a subnode.
Regardless, this part of Applicant’s argument is nonresponse to the rejection. Examiner took official notice of replacement devices. Therefore the fact that Morita fails to teach them is nonresponsive to the rejection. Examiner found that one of ordinary skill would have recognized that replacement parts would be authenticated in the same manner as new parts.
At Remarks, pg. 18, Applicant discusses the official notice. Applicant’s only argument in response to the replacement part notice is that Examiner’s assertion “is inadequate” and that “replacement parts in a hierarchical authentication system require authentication.” But as explained above, Morita teaches authentication of subnodes in a hierarchical authentication system, and as Examiner found, a person of ordinary skill both (i) knew of replacement parts (which Applicant does not seem to dispute) and (ii) would recognize that replacement parts could be authenticated in the same manner as new subnodes as taught by Morita, because replacement subnodes are a subset of new subnodes.
To compact prosecution, Examiner will create an alternate ground citing Segawa that specifically teaches replacement nodes.
All claims remain rejected.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS P CELANI whose telephone number is (571)272-1205. The examiner can normally be reached on M-F 9-5.
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, Vivek Srivastava can be reached on 571-272-7304. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/NICHOLAS P CELANI/Examiner, Art Unit 2449