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 . In communications filed on 04/10/2025. Claims 1-4 are withdrawn. Claims. Claims 5-14 and amended. Claims 15-20 newly added. Claims 5-20 are pending.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. This examination is in response to US Patent Application No. 19/054,376.
Response to Restriction Requirement
In response to the Restriction Requirement dated April 7, 2026, the Applicant elects without traverse the invention of Group II, corresponding to claims 5-20, and drawn to a communication method and implementation of first device for communication between first node and second node. The Applicant elects Group II without prejudice or disclaimer.
Examiner, therefore, has examined claims 5-20 in this instant office action.
Examiner Note
Examiners encourage applicant to indicate the purpose or outcome of the independent claims 5, and 10. The claims are specific but I don’t see what is the result of all the steps you are taking, please add a limitation at the end (which has a support in your specification) to further tie the other limitations with what is the result of the steps taken in the claims.
The independent claims indicate generating messages, generating proxy signed private key, generating second message based on signed public key of the second node and sending it to inspection device and so on, however , these independent claims do not indicate any outcomes or purposes and only indicate message communication and encryption operation hence, the claims sets does not indicate a clear purpose of the invention and examiner maps the claims under broadest reasonable interpretation.
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed to.
Claim Objections
Claim 19 is objected to because of the following informalities: claim 19 depends on claim 5. Claim 5 recites “A communication method implemented by a first device and comprising: generating, ,a first message, wherein the first message comprises second node information, and wherein the second node information indicates a second node; and sending,and claim 19 recites “ The communication method of claim 18, wherein the signing comprises signing, by the first device, the second message using the proxy signed private key to generate the first message”.
In claim 5, the first device already generated the first message based on the second node information , however in claim 19 , the first device also generates a first message based on different information , the dependent claim 19 contradict the claim 5 generation of first message.
Same analysis also applies to claims 10 and 16.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL. —The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 6-9, and 11-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement.
Regarding claims 6, and 11 limitation “ sending, to a second device, a public key of the first device; and receiving, from the second device, an encrypted proxy signed private key that is based on the public key”. which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention. . specification in many paragraphs mentions the limitation above, but does not indicate if the public key of the first device used in encrypting proxy signed private key? Or how the encrypted proxy signed private is based on the first device public key? And furthermore, if the private key of the second device digitally signed by the second device private key , in other words if the private key of the second device signs the private key of the second device?
Claims 7-9, and 12-20 do not cure the deficiency of claims 6, and 11 and are rejected under 35 USC 112, 1st paragraph, for their dependency upon claims 6, and 11.
Applicant is kindly requested to show the examiner support in the original disclosure for the new or amended claims. See MPEP 714.02 and 2163.06 (“Applicant should specifically point out the support for any amendments made to the disclosure").
First Set of Rejections:
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 5, 7, 9-10, 12, 14, 17, and 20 are rejected under 35 U.S.C. 102(a) (1) as being anticipated by Nolscher ( US2020/0029209).
Regarding claims 5, and 10, Nolscher discloses A communication method implemented by a first device and comprising: generating, ,a first message, wherein the first message comprises second node information, and wherein the second node information indicates a second node; and sending,
[See Fig.1 and corresponding text , Vehicle 102 with a transceiver (TX/RX) 114, and Vehicle gateway(120], and [0025] Vehicle gateway 120 ( equated to first device) performs one or more security functions for communications sent/received ( equated to messages) from vehicle. In embodiments, small and/or local network connections are continually established between vehicle 102 ( equated to first node) and any combination of node(s) (e.g., network node(s) 160 and/or vehicle network node(s) 170)( equated to second node) For example, a local network connection may have a range of 10 meters, 100 meters, 1 kilometer, etc., and as vehicle 102 moves during operation, vehicle 102 is continuously coming within, or leaving, communication range with other network nodes capable of performing the processes discussed herein. Therefore, to ensure privacy and security in the established connections, and the data exchanged subsequent to establishing connections, for each new network connection that is to be established between vehicle 102 and another network node (160 or 170), vehicle gateway performs an initial discovery and handshaking process. In embodiments, as discussed in greater detail below, the discovery and handshaking process are used by each node (e.g., vehicle 102 and the other network nodes, such as 160 or 170) to broadcast messages ( equated to sending message) for discovering other nodes of the network, verify each other's identity ( equated to identifying information of each node), establish that each has access to certain shared information (e.g., a network encryption key), and establish session encryption keys or other connection parameters (e.g., wireless communication channel parameters) for all communications exchanged between the vehicle 102 and the network node (160 or 170) after the handshaking process is performed. Such communications can include, for example, data shared between nodes (e.g., transmission of files, software updates, firmware updates, etc.), short message (e.g., traffic warnings, diagnostic events, etc.), relaying connections between nodes and/or a connection to network 130, as well as communication of other data].
Regarding claims 7, and 12, Nolscher discloses further comprising generating, by the first device, a second message based on a signed public key of the second node and a communication list, wherein the communication list indicates that the first node and the second node need to communicate with each other.
[ see FIG. 4A and corresponding text for more details], and [0017] In embodiments, certification authority server(s) 150 are remote servers that provide certification authority services, such as issuing identifiers to network nodes, generating and distributing public/private encryption keys, issuing certificates to network nodes, signing certificates, revoking certificates, verifying data within certificates, etc. Certification authority server(s) 150 may perform any of the services typically associated with certification authority systems. Certification authority server(s) 150 may be a single server computer system or may be comprised of two or more server computer systems distributed over a network 130 (e.g., the Internet, a private network, or other network).
[0018] System 100 includes vehicle 102 communicatively coupled to any combination of network node(s) 160, vehicle network node(s) 170, and certification authority server(s) 150. In the context of this application, “communicatively coupled” means coupled in such a way that data can be exchanged, in one or both directions, between two entities or components (e.g., between the vehicle 102 and any of network node(s) 160, vehicle network node(s) 170, and certification authority server(s) 150)
[0039] However, when networking manager 224 of vehicle 202 receives a parameter proposal message from node 250 (e.g., in response to vehicles broadcast discovery message), networking manager 224 uses encryption engine 234 to perform complimentary operation to those discussed above. In embodiments, the operations can include MAC tag verification in the received message, decryption using a shared network key stored in secure data storage 226, decryption using the private key of the vehicle stored in secure data storage 226, validation of the sending node's signature (e.g., using a certificate authority and signatures/IDs in the decrypted message), generating a twice encrypted response (e.g., encrypted using a public key of node 250 and the network key) including one or more communication parameter proposal responses, and then transmitting a parameter proposal response message to node 250.
[0040] In embodiments, the network broadcast message generation and transmission, as well as receipt, can continue as communication parameters are negotiated and/or generated. In embodiments, the parameter generation can include the establishment and sharing of asymmetric session encryption keys (e.g., sharing of public keys with private keys secured by vehicle 202 and node 250). In other embodiments, the parameter generation and negotiation can include the exchange of a series of messages (e.g., a DH exchange) for the establishment and sharing of a symmetric session encryption key. In either embodiment, subsequent communications and data exchanged between vehicle 202 and node 250 may be secured using the negotiated session parameters (e.g., encryption key(s)). In embodiments, node messaging manager 222 uses the established session encryption key(s) with encryption engine 234 to encrypt/decrypt communications with node 250.
Regarding claims 9, and 14, Nolscher discloses further comprising: receiving, by the first device, a first signal from an electrical inspection device; and sending, by the first device, request information to the second node based on the first signal, wherein the request information requests the signed public key of the second node.
[ see FIG. 4A and corresponding text for more details], and [0017] In embodiments, certification authority server(s) 150 are remote servers that provide certification authority services, such as issuing identifiers to network nodes, generating and distributing public/private encryption keys, issuing certificates to network nodes, signing certificates, revoking certificates, verifying data within certificates, etc. Certification authority server(s) 150 may perform any of the services typically associated with certification authority systems. Certification authority server(s) 150 may be a single server computer system or may be comprised of two or more server computer systems distributed over a network 130 (e.g., the Internet, a private network, or other network).
[0018] System 100 includes vehicle 102 communicatively coupled to any combination of network node(s) 160, vehicle network node(s) 170, and certification authority server(s) 150. In the context of this application, “communicatively coupled” means coupled in such a way that data can be exchanged, in one or both directions, between two entities or components (e.g., between the vehicle 102 and any of network node(s) 160, vehicle network node(s) 170, and certification authority server(s) 150)
[0020-0021] In one embodiment, vehicle 102 includes one or more systems, such as components 101, each having an electronic control unit (ECU) 105, and each ECU 105 is communicatively coupled via a communications network 107 to a vehicle control unit (VCU) 106 ( equated to electrical inspection device). The communications network 107 may be a controller area network (CAN)… . VCU 106 is also communicatively coupled to a GPS unit 110, a user interface 112, and a transceiver 114. Transceiver 114, is a vehicle to anything (V2X), wireless fidelity, wide area network, or a combination of transceivers, that is communicatively coupled to an antenna 116, through which vehicle 102 can wirelessly transmit data to, and receive data from, any of certification authority server(s) 150, network node(s) 160, and vehicle network node(s) 170 using protocols for the exchange of information. In the illustrated embodiment, vehicle 102 communicates wirelessly via antenna 116 with a tower 132, which can then communicate via network 130 (e.g., a cellular communication network, a local area network, a wide area network, etc.) with certification authority server(s) 150. In embodiments, the vehicle 102 communicates with certification authority server(s) 150 and/or other remote server(s) when a wireless connection with tower 132 is available. [0021] Components 101 are generally components of the systems of the vehicle 102. For example, components 101 can include adjustable seat actuators, power inverters, window controls, electronic braking systems, etc. Vehicle control unit (VCU) 106 is a controller including a microprocessor, memory, storage, and a communication interface with which it can communicate with components 101, global positioning system (GPS) 110, user interface 112, and transceiver 114 via network 107. In one embodiment VCU 106 is the vehicle's main computer, but in other embodiments it can be a component separate from the vehicle's main or primary computer.
[0039] However, when networking manager 224 of vehicle 202 receives a parameter proposal message from node 250 (e.g., in response to vehicles broadcast discovery message), networking manager 224 uses encryption engine 234 to perform complimentary operation to those discussed above. In embodiments, the operations can include MAC tag verification in the received message, decryption using a shared network key stored in secure data storage 226, decryption using the private key of the vehicle stored in secure data storage 226, validation of the sending node's signature (e.g., using a certificate authority and signatures/IDs in the decrypted message), generating a twice encrypted response (e.g., encrypted using a public key of node 250 and the network key) including one or more communication parameter proposal responses, and then transmitting a parameter proposal response message to node 250.
[0040] In embodiments, the network broadcast message generation and transmission, as well as receipt, can continue as communication parameters are negotiated and/or generated. In embodiments, the parameter generation can include the establishment and sharing of asymmetric session encryption keys (e.g., sharing of public keys with private keys secured by vehicle 202 and node 250). In other embodiments, the parameter generation and negotiation can include the exchange of a series of messages (e.g., a DH exchange) for the establishment and sharing of a symmetric session encryption key. In either embodiment, subsequent communications and data exchanged between vehicle 202 and node 250 may be secured using the negotiated session parameters (e.g., encryption key(s)). In embodiments, node messaging manager 222 uses the established session encryption key(s) with encryption engine 234 to encrypt/decrypt communications with node 250.
Regarding claim 17 and 20, Nolscher discloses wherein the one or more processors is further configured to activate the first device using the first signal [ see FIG, 1, TX/RX (114), [0020] In one embodiment, vehicle 102 includes one or more systems, such as components 101, each having an electronic control unit (ECU) 105, and each ECU 105 is communicatively coupled via a communications network 107 to a vehicle control unit (VCU) 106. The communications network 107 may be a controller area network (CAN), an Ethernet network, a wireless communications network, another type of communications network, or a combination of different communication networks. VCU 106 is also communicatively coupled to a GPS unit 110, a user interface 112, and a transceiver 114. Transceiver 114, is a vehicle to anything (V2X), wireless fidelity, wide area network, or a combination of transceivers, that is communicatively coupled to an antenna 116, through which vehicle 102 can wirelessly transmit data to, and receive data from, any of certification authority server(s) 150, network node(s) 160, and vehicle network node(s) 170 using protocols for the exchange of information. In the illustrated embodiment, vehicle 102 communicates wirelessly via antenna 116 with a tower 132, which can then communicate via network 130 (e.g., a cellular communication network, a local area network, a wide area network, etc.) with certification authority server(s) 150.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
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 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 6, 8, 11, and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Nolscher ( US2020/0029209), and in view of LI, Chao-yang ( CN115033912A), hereinafter, “Li”.
Regarding claims 6 and 11 , Nolscher does not explicitly disclose, however, Li discloses further comprising: sending, to a second device, a public key of the first device; and receiving, from the second device, an encrypted proxy signed private key that is based on the public key.
[Page, 7 last 3 paragraphs- page 8, the new device main body member is registered as the main body group of the intelligent medical device group, the specific operation process is as follows:
S101: sending a registration information to the group manager of the main body group by the new device main body member, obtain the member certificate corresponding to the registration information is sent to the group manager of the main body group;
Specifically, the new device main body member firstly randomly selects two secret parameters wherein, is a double-peak Gaussian distribution; secondly, calculating and wherein, is a new member private key, B is a group public key; then selecting an expiration date and time and the registration information and sending to the group manager.
S102: the group manager uses the registration information of the new device main body member, generating a member certificate containing expiration date and time, and returning it to the new device main body member
the intelligent medical device group selects one member as a proxy signer, by authorization of the agent, making it represent the group to perform signature.
S202: the proxy signer uses the received proxy certificate, generating the proxy public and private key for signature;
Specifically, the proxy signature firstly verifies the validity of the proxy certificate, if the parameter in the proxy certificate satisfy and or parameter satisfy and the proxy is not successful, re-performing proxy authorization; if parameter and satisfy above requirements, and is established, the agent authorization is successful; then, the agent signer calculates M arrow H1 (WA, B), AP=Ui *MT and wherein the AP represents the proxy public key, SP represents the proxy private key.
S203: the proxy signer signs the message to be signed by using the generated proxy public and private key;
the verifier uses the system public key and proxy public key information, verifying the validity of the proxy signature.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Nolscher by incorporating “cross-device anonymous verification model”, as taught by Li . One could have been motivated to do so in order to select a proxy signer to represent the other main device privacy protection by hiding the signer information. [ Li , Abstract, background].
Regarding claims 8, and 13, Nolscher does not explicitly disclose, however, Li discloses further comprising decrypting, by the first device, the encrypted proxy signed private key using the public key, to obtain a proxy signed private key.
[ Page, 7 last 3 paragraphs- page 8, the new device main body member is registered as the main body group of the intelligent medical device group, the specific operation process is as follows:
S101: sending a registration information to the group manager of the main body group by the new device main body member, obtain the member certificate corresponding to the registration information is sent to the group manager of the main body group;
Specifically, the new device main body member firstly randomly selects two secret parameters wherein, is a double-peak Gaussian distribution; secondly, calculating and wherein, is a new member private key, B is a group public key; then selecting an expiration date and time and the registration information and sending to the group manager.
S102: the group manager uses the registration information of the new device main body member, generating a member certificate containing expiration date and time, and returning it to the new device main body member
the intelligent medical device group selects one member as a proxy signer, by authorization of the agent, making it represent the group to perform signature.
S202: the proxy signer uses the received proxy certificate, generating the proxy public and private key for signature;
Specifically, the proxy signature firstly verifies the validity of the proxy certificate, if the parameter in the proxy certificate satisfy and or parameter satisfy and the proxy is not successful, re-performing proxy authorization; if parameter and satisfy above requirements, and and is established, the agent authorization is successful; then, the agent signer calculates M arrow H1 (WA, B), AP=Ui *MT and wherein the AP represents the proxy public key, SP represents the proxy private key.
S203: the proxy signer signs the message to be signed by using the generated proxy public and private key;
the verifier uses the system public key and proxy public key information, verifying the validity of the proxy signature.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Nolscher by incorporating “cross-device anonymous verification model”, as taught by Li One could have been motivated to do so in order to select a proxy signer to represent the other main device privacy protection by hiding the signer information. [ Li , Abstract, background].
Claims 15, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Nolscher ( US2020/0029209), and in view of LI, Chao-yang ( CN115033912A), hereinafter, “Li”, and further in view of REVADIGAR, Girish Shivalingappa (CN 113748691 B) , hereinafter, “Girish”
Regarding claims 15, and 18, Nolscher, and Murray do not explicitly disclose, however, Girish discloses wherein the one or more processors is further configured to generate the first message by signing the second message.
[ Page 9, 2nd paragraph, Referring to the second aspect of the present application, the method for receiving the first signal strength sequence from the user equipment comprises: receiving a fourth instruction and a fifth instruction from the user equipment, the fourth instruction comprises an encrypted eighth message and a signed ninth message, wherein the encrypted eighth message is generated by encrypting the eighth message through the KBTUDev, the eighth message comprises the random number n, the correction data C and the command identifier of the fourth instruction, the ninth message of the signature is generated based on the signature of the ninth message through the PKI-private key KeyPriv_UDev associated with the user equipment, the first message is generated based on the hash of the encrypted eighth message through the KBTUDev, the fifth instruction comprises the encrypted second message and a signed eleventh message, wherein the encrypted second message is generated based on the encryption of the second message through the KBTUDev, the second message comprises the random number n, an XOR operation between the random string r and the user string SUDev and a command identifier of the fifth instruction, the eleventh message of the signature is generated based on the signature of the eleventh message through the PKI-private key KeyPriv_UDev associated with the user device, the eleventh message is generated by hashing the encrypted second message through the KBTUDev].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Nolscher, and Li by incorporating “instructions which comprises an encrypted message and a signed message”, as taught by Girish. One could have been motivated to do so in order to propose an authentication system and method for establishing data transmission between a vehicle and a vehicle owner mobile device, so as to establish a secure communication channel. [ Girish, Page 3, 3rd para.].
Claims 16, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Nolscher ( US2020/0029209), and in view of LI, Chao-yang ( CN115033912A), hereinafter, “Li”, and further in view of REVADIGAR, Girish Shivalingappa (CN 113748691 B) , hereinafter, “Girish”, and further in view of Hsiung ( US2022/0158824).
Regarding claims 16, and 19, Nolscher, Nurry, and Girish do not explicitly disclose, however, Hsiung discloses wherein the processor is further configured to sign the second message using the proxy signed private key to generate the first message.
[0004] According to the second method, context information of a handshake between a source entity and a target entity is received from a security proxy at a key manager. Here the key manager maintains a first private key of the security proxy. Then, a first handshake message directed to the target entity is generated at least based on the context information at the key manager. Here the first handshake message is signed with the first private key of the security proxy. Next, the first handshake message is transmitted to the security proxy.
[0064] To communicate with each other, for example, to exchange application data, a handshake between the target entity 410 and the source entity 420 is required. Due to presence of the security proxy 430, the handshake may comprise a handshake sequence between the target entity 410 and the security proxy 430 as well as another handshake sequence between the source entity 420 and the security proxy 430. One or more handshake messages communicated among the target entity 410, the security proxy 430 and the source entity 420 may need to be signed with a private key of a sender of the handshake messages. For example, a handshake message for certificate verification is required to be signed with the private key of the sender.
[0067] The key manager 440 is configured to receive context information of the handshake between the source entity 420 and the target entity 410 from the security proxy 430 and generate a handshake message at least based on the context information and the private key 450. As used herein, the term “context information” of the handshake refers to at least a part of information having been exchanged during the handshake, for example, messages having been communicated among the target entity 410, the security proxy 430 and the source entity 420.], and [ 0102].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Nolscher, Li, and Girish by incorporating “security proxy, and key manger”, as taught by Hsiung. One could have been motivated to do so in order to provide a handshake between the target entity and the source entity, where handshake messages communicated among the target entity , the security proxy and the source entity may need to be signed with a private key of a sender of the handshake messages. [ Hsiung, 0064].
Second Set of Rejections:
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 5,and 10 are rejected under 35 U.S.C. 102(a) (1) as being anticipated by Quiroga ( US22017/0308902).
Regarding claim 5, and 10, A communication method implemented by a first device and comprising: generating, a first message, wherein the first message comprises second node information, and wherein the second node information indicates a second node; and sending,
[0045] At the bank server system 110, the secure gateway 205 ( equated to first device) may in turn receive the request to issue the new electronic card from the authentication plug-in 240 running on the end user device 105 ( equated to second node). The services interface 220 may compare the information included in the request to issue the interface to previously stored account data. In some embodiments, the services interface 220 may identify the entity identifier from the request. The services interface 220 may identify the bank services interface 210 corresponding to the entity identifier. The bank services interface 210 may be another server or computing device( equated to first node) used to interface and relay information with other devices connected to the network 280. The services interface 220 ( equated to first device) may forward the request ( generating a message) to issue the electronic card to the bank services interface 210( equated to first node) identified as corresponding with the entity identifier.
Third Set of Rejections:
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 5,and 10 are rejected under 35 U.S.C. 102(a) (1) as being anticipated by Morita ( US2016/0219051).
Regarding claim 5, and 10, Morita discloses a communication method implemented by a first device and comprising: generating, a first message, wherein the first message comprises second node information, and wherein the second node information indicates a second node; and sending,
[0061] FIG. 3 is a schematic block diagram showing a configuration example of a system including a plurality of devices provided from a plurality of makers. As described in detail in a second embodiment described later, an apparatus (X) 10 is, for example, a vehicle, communication paths 4_1 to 4_5 are, for example, an in-vehicle network such as CAN (Controller Area Network), and devices A to F (1 and 3_1 to 3_5) are, for example, electronic control units (ECUs). The network and the apparatuses coupled to the network may be a network and apparatuses other than the in-vehicle network (CAN) and the electronic control units (ECUs), and can be changed to, for example, a medical network and medical instruments coupled to the medical network or an industrial network and industrial instruments coupled to the industrial network. Further, the network may have various forms of network paths regardless of wired or wireless. For example, when the network is an in-vehicle network, the network is not only CAN, but may be Flex Ray (registered trademark) or MOST (Media Oriented Systems Transport).
[0062] As described above, the number of makers that supply the MPU 11 such as a secure microcomputer mounted on each device is not limited to one. As illustrated in FIG. 3, the apparatus (X) 10 includes a gateway device A (1) made by T company, devices B and C (3_1 and 3_2) made by R company, devices D and E (3_3 and 3_4) made by S company, and a device F (3_5) made by T company( equated to second nodes). Regarding the authentication, various forms are considered such as a supply source of the mounted MPU 11 performs the authentication, a supply source of a device performs the authentication, and a maker of the apparatus (X) 10 performs the authentication. Therefore, as shown in FIG. 3, the companies have authentication servers (authentication apparatuses) 7_1 to 7_3, respectively( equated to first node). In such a case, a broker server 6 is arranged in the network 5. The broker server 6 (equated to first device) collectively receives authentication requests from the apparatus (X) 10 and then distributes authentication information to the authentication servers 7_1 to 7_3( equated to sending message) respectively. The authentication server 7_1 made by R company has a list of product IDs (bbbb and cccc) written to the devices made by R company and performs authentication of the devices made by R company. The authentication server 7_2 made by S company has a list of product IDs (dddd and eeee) written to the devices made by S company and performs authentication of the devices made by S company. The authentication server 7_3 made by T company has a list of product IDs (aaaa and ffff) written to the devices made by T company and performs authentication of the devices made by T company].
[See FIGs 7, 8 and corresponding text for more details , 0068] FIG. 7 is a sequence diagram showing an example of an authentication flow when a new lower node E (3_3) is coupled. FIG. 8 is an explanatory diagram showing an example of a message transmitted and received in the authentication flow illustrated in FIG. 7.].
Fourth Set of Rejections:
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 5,and 10 are rejected under 35 U.S.C. 102(a) (1) as being anticipated by Suzuki ( US2021/0099422).
Regarding claim 5, and 10, Suzuki discloses a communication method implemented by a first device and comprising: generating, a first message, wherein the first message comprises second node information, and wherein the second node information indicates a second node; and sending,
[ Abstract, A relay device( equated to first device) includes a communicator configured to transmit and receive a message to and from the communication device, and a processor configures to acquire a public key of a communication device( equated to second node) that is a transmission source of the message from the node and authenticates a signature included in the message with the acquired public key, wherein the processor causes, when receiving a communication message including communication data to be transmitted to a second communication device ( equated to second node) by a first communication device, the processor to perform authentication on the communication message, and the communicator transmits the communication message to the second communication device when the authentication is successful.
[ see FIG. 1, [0056-0057, The relay device 200 is a communication device that relays communication between terminal devices. Upon receiving the control message from the terminal device 100, and when the security of the received message is confirmed, the relay device 200 transmits the received control message to the terminal device 100 of the transmission destination. For example, the relay device 200 verifies a signature of the received control message with a public key to confirm the security of the received control message…].
Fifth Set of Rejections:
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 5,and 10 are rejected under 35 U.S.C. 102(a) (1) as being anticipated by Peng ( US2021/0334353).
Regarding claim 5, and 10, Peng discloses a communication method implemented by a first device and comprising: generating, a first message, wherein the first message comprises second node information, and wherein the second node information indicates a second node; and sending,
[ see FIG. 2, [0044] According to a third aspect, a third device authentication method is provided ( equated to first device). The method includes: A third device receives first information and a first certificate( equated to information from second node) from a first device( equated to second node), where the first information is used to indicate a second device, and the first certificate is a device certificate of the first device. The third device searches for the corresponding second device( equated to first node) based on the first information and sends the first information and the first certificate to the second device (equated to sending message) , where the first certificate is used by the second device to perform authentication on the first device.
[0045] The method in the third aspect may be performed by a third communications apparatus. The third communications apparatus may be a communications device or an apparatus, for example, a chip system, that can support a communications device in implementing a function described in the method. For example, the communications device is a vehicle-mounted apparatus. For example, the vehicle-mounted apparatus is an apparatus such as a gateway or a router or may be another apparatus having a routing and forwarding function. In the following description, an example in which the third communications apparatus is the third device is used.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's
disclosure.
See submitted 892 for more relevant references.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jorge Ortiz-Criado can be reached at 571-272-7624. 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.
/SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496
Prosecution Insights