DETAILED ACTION
This communication is in response to applicant’s Amendment which is filed on March 27, 2026.
An amendment to amend the claims 1, 3, 5, 6, 8, 10, 11, 13 and 15 has been entered and made of record .
Claims 4, 9, and 14 are cancelled.
A new set of claims 16-23 is introduced.
Claims 1-3, 5-8, 10-13 and 15-23 are now pending in the application.
Response to Arguments
In view of applicant’s amendment to amend the Specification for the Cross-Reference section, therefore, examiner has withdrawn the objection of the Specification.
Applicant's arguments with respect to claims 1-3, 5-8, 10-13 and 15-23, filed on March 27, 2026, have been fully considered but are moot in view of the new ground(s) of rejection.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 6 and 11 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being incomplete for omitting essential structural cooperative relationships of elements, such omission amounting to a gap between the necessary structural connections. See MPEP § 2172.01. The omitted structural cooperative relationships are: the method of replacing the software stack with a new version of the software stack from a backup software system at least when a failure of the integrity check is determined as recited in the original is unrelated to the method of generating a first message digest according to control commands sent to the vehicle; receiving, from the vehicle, a second message digest generated according to control commands received by the vehicle and generating an indicator for a security breach at least when the first message digest is different from the second message digest that are amended. The amended claim includes limitations that are operated independently and as being incomplete for omitting essential structural cooperative relationships of elements. Art rejection is applied as best understood in light of the rejection under 35 U.S.C. 112 discussed above.
Referring to claims 2, 3, 5, 7, 8, 10, 12, 13 and 15-23 are rejected as being dependent upon a rejected Claims 1, 6 and 11 above.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
Claims 1-3, 5-8, 10-13, 15 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Zuo et al. (CN 107948307A) in view of Takemori et al. (WO 2018/029905).
Referring to claim 1, Zuo et al. disclose a method for providing security for a vehicular monitoring system (page 1 paragraph 0002; see Figures 1 to 14), comprising:
periodically performing, by a monitor server, an integrity check on a software stack associated with control or operation of a vehicle (i.e. the smart vehicle-mounted device 100 or the corresponding APP application 300 is abbreviated as a client in the following, and the four-time communication interaction protocol specifically includes the following steps:
Step 1 : In the client request authentication phase, the client sends a MESSAGE packet authentication request message to the server 200. The MESSAGE packet includes the following parts: the protocol type sequence number STYPE having a value of 1; the message type sequence number MTYPE having a value of 1; and the service data DATA composed of a user's unique identifier UID and a public key PUBLICKEY stored at the client. Defines the message digest generated by the hash hash function KHASH for messages.
Step 2 : The server returns a signature random code phase. After receiving the client authentication request message, the server 200 first verifies the validity of the sent MESSAGE packet, and uses the custom hash function KHASH of the service end 200 to The new message digest obtained by hash calculation of the protocol type sequence number STYPE, the message type sequence number MTYPE, and the service data DATA in the MESSAGE packet is compared with the message digest in the sent MESSAGE packet.
If the comparison is the same, then the MESSAGE packet is considered legal, and then the server 200 generates a random code RANDCODE packet sent back to the client, and records the client connection CONID value and the public key PUBLICKEY value and random code RANDCODE value;
If the comparison is inconsistent, the server 200 returns an error ERROR packet to the client and ends the authentication operation) (see paragraphs 0091 to 0097; see Figure 8).
However, Zuo et al. did not explicitly disclose replacing the software stack with a new version of the software stack from a backup software system at least when a failure of the integrity check is determined;
wherein the method further comprises:
generating a first message digest according to control commands sent to the vehicle (100) (i.e. the server sends the control command to the intelligent vehicle device…, the control command packet format comprises the following parts: a value of 3 protocol type number STYPE, order number MTYPE, a specific command parameter data DATA using user-defined hash hash function KHASH the message generated by the message abstract) (page 11 lines 28; see Figures 8 and 10-11);
receiving, from the vehicle, a second message digest generated according to control commands received by the vehicle (i.e. the APP application 300 transmits a control command to the server 200, the application APP 300 in the form of APP application control command packet sending some control command request to the server 200, the server 200 receives the request and then it is connected with channel by the application APP 300 CONNID find intelligent vehicle device corresponding to 100, and judging whether the intelligent vehicle device 100 completes the authentication operation (page 12 lines 8 to 12).. The APP application control command packet format comprises following parts: protocol type number STYPE value of 5, control command number MTYPE, operation command specific content DATA, hash function KHASH generates the message using a defined hash message digest, the control command number MTYPE begins allocation from the number 1 and no upper limit requirement, a control command number represents one of the APP application 300 to the control command of the intelligent vehicle device 100) (page 12 line 19 to 26; see Figures 14); and
generating an indicator for a security breach at least when the first message digest is different from the second message digest (i.e. the smart vehicle-mounted device 100 or the supporting APP application 300 is hereinafter referred to as the client ... Step 1. In the client request authentication stage, the client sends MESSAGE packet authentication request information to the server 200 ... After receiving the authentication request message from the client, the server 200 first verifies the legitimacy of the MESSAGE packet sent, and uses the custom hash function KHASH of the server 200 to verify the new message digest obtained by hashing the protocol type sequence number STYPE, message type sequence number MTYPE, and business data DATA in the MESSAGE packet is compared with the message digest in the sent MESSAGE packet.", where server verifies the new message digest obtained by hashing the protocol type sequence number STYPE and message type sequence number MTYPE, i.e., the server 200 verifies the APP control command packet sent to the server that includes the protocol type serial number STYPE with a value of 5 and the operation command number MTYPE with the server control command packet sent by the server that includes the protocol type serial number STYPE with a value of 3 and command number MTYPE) (page 9 line 28 to page 10 line 2; see Figure 8). If the comparison is inconsistent, the server 200 returns an error ERROR packet to the client and ends the authentication operation) (page 12 lines 17 to 18; see Figure 8).
However, Zuo et al. did not explicitly disclose replacing the software stack with a new version of the software stack from a backup software system at least when a failure of the integrity check is determined.
In the same field of endeavor of a vehicle security monitoring system, Takemori et al. teach that replacing the software stack with a new version of the software stack from a backup software system at least when a failure of the integrity check is determined (i.e. if the verification result of the electronic signature fails, the control unit 21 may execute predetermined error processing. For example, the control unit 21 may transmit an error message indicating that the verification result of the electronic signature is unacceptable to the server apparatus 2000. The server device 2000 may execute predetermined error processing in response to the error message. For example, the server device 2000 retransmits the ECU code, the expected value of the ECU code, and the electronic signature to the data security device 1010, or regenerates the electronic signature, and then the ECU code and the expected value of the ECU code. And the electronic signature may be transmitted to the data security device 1010) (page 6 paragraph 5, see Figure 5) in order to re-verify the electronic signature for improving the data security in the vehicle.
At the time of the effective filing date of the current application, it would have been obvious to a person of ordinary skill in the art to recognize the need for using the regenerate the electronic signature and be transmitted to the data security device of vehicle for verification result of the regenerate electronic signature taught by Takemori et al. in the intelligent vehicle-mounted device and the secure communication based on the information security sign cryption protection mechanism of the data interaction process of the internet of vehicle of Zuo et al. because using the regenerate the electronic signature and be transmitted to the data security device of vehicle for verification result of the regenerate electronic signature would provide secure and liable communication for monitoring vehicle.
Referring to claim 2, Zuo et al. in view of Takemori et al. disclose the method of claim 1, Takemori et al. disclose further comprising: triggering an emergency handling service at least when tampering of the new version of the software stack is detected (i.e. Hardware Security Module (HSM) 1012 and Secure Hardware Extension (SHE) 1022 are used for the data security device 1010 and the Electronic Control Unit (ECU) 1020, but cryptographic processing chips other than HSM and SHE may be used. For the data security device 1010, for example, a cryptographic processing chip called “TPM (Trusted Platform Module) f” may be used. TPMf has tamper resistance. TPMf is an example of a secure element. For the ECU 1020, for example, a cryptographic processing chip called “TPMt” may be used. TPMt has tamper resistance. TPMt is an example of a secure element) (page 4 paragraphs 3 and 4; page 9 paragraphs 6 to 8).
Referring to claim 3, Zuo et al. in view of Takemori et al. disclose the method of claim 1, Zuo et al. disclose wherein the integrity check comprises determining whether a position, velocity or acceleration of a vehicle is within a pre-determined acceptable operating range (i.e. the sensor group 400 is composed of a video collecting module 401, an audio acquisition module 402, an audio player 403, a brake sensor 404, a vehicle speed sensor 405, an acceleration sensor 406, a shift sensor 407, a temperature sensor 408, a fuel sensor 409, a direction sensor 410, a tire pressure sensor 411.) (paragraph 0018; paragraph 0086; see Figure 5).
Referring to claim 5, Zuo et al. in view of Takemori et al. disclose the method of claim 3, Zuo et al. disclose further comprising: identifying at least one of the one or more sensors whose data is not within the pre-determined acceptable operating range; and ceasing to use the at least one of the one or more sensors (i.e. the sensor group 400 is used to collect real-time state data of the vehicle and connected by USB data wire or Bluetooth connection way group 112 with the USB interface or Bluetooth module 114 connected to the specific connection way connection mode determined by the sensor itself. the digital signal or analog signal of each vehicular sensor collected according to collection time sequence stored in the storage module 102, and send to the data backup storage server 200, and the server 200 receives the intelligent vehicle device 100 sent by the large amount of real-time sensor data, through the communication module 113. the automobile in the driving by the machine learning to large data mining modelling algorithm analysis, the given running state model of the vehicle, and the model makes a corresponding pre-alarm and alarm prompt is sent to intelligent vehicle-mounted device 100, intelligent vehicle-mounted device (100) after receiving the message, sending pre-warning and alarming prompt by the audio player 403) (paragraph 0018; paragraphs 0086 to 0087; see Figure 5).
Referring to claims 6-8, 10-13 and 15, Zuo et al. in view of Takemori et al. disclose an apparatus and a non-transitory computer readable program storage medium having code stored thereon, although different in scope from the claims 1-3 and 5, the claims 6-8, 10-13 and 15 contains similar limitations in that the claims 1-3 and 5 already addressed above therefore claims 6-8, 10-13 and 15 are also rejected for the same obvious reasons given with respect to claims 1-3 and 5, respectively.
Referring to claim 17, Zuo et al. in view of Takemori et al. disclose the method of claim 3, Zuo et al. disclose wherein the first message digest is an output of a cryptographic hash function of control commands sent by the monitor server; the second message digest is an output of a cryptographic hash function of control commands received by the vehicle (i.e. the APP application 300 transmits a control command to the server 200, the application APP 300 in the form of APP application control command packet sending some control command request to the server 200, the server 200 receives the request and then it is connected with channel by the application APP 300 CONNID find intelligent vehicle device corresponding to 100, and judging whether the intelligent vehicle device 100 completes the authentication operation (page 12 lines 8 to 12).. The APP application control command packet format comprises following parts: protocol type number STYPE value of 5, control command number MTYPE, operation command specific content DATA, hash function KHASH generates the message using a defined hash message digest, the control command number MTYPE begins allocation from the number 1 and no upper limit requirement, a control command number represents one of the APP application 300 to the control command of the intelligent vehicle device 100) (page 12 line 19 to 26; see Figures 14).
Claims 16 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Zuo et al. (CN 107948307) in view of Takemori et al. (WO 2018/029905) as applied to claim 1, and further in view of More et al. (Pub. No. US 2017/0031592).
`Referring to claim 16, Zuo et al. in view of Takemori et al. disclose the method of claim 1, however, Zuo et al. in view of Takemori et al. did not explicitly disclose wherein the monitor server and the vehicle each maintains a command buffer of a same size, the method further comprises: consecutively placing first control commands sent by the monitor server in the monitoring server command buffer, consecutively placing second control commands received by the vehicle in the vehicle command buffer; and computing a hash of each of the buffers to correspondingly generate the first message digest and the second message digest.
In the same field of endeavor of a communication system, More et al. teach wherein the monitor server and the vehicle each maintains a command buffer of a same size, the method further comprises: consecutively placing first control commands sent by the monitor server in the monitoring server command buffer, consecutively placing second control commands received by the vehicle in the vehicle command buffer; and computing a hash of each of the buffers to correspondingly generate the first message digest and the second message digest (i.e. the command buffer management module 134 may be configured to generate a message 136 in response to the communication interface 144 receiving a command. The message 136 may indicate a remaining allowed storage size 138 associated with the command buffer 128) (page 2 paragraph 0023; see Figures 1 to 2) in order to improve performance of the messaging system.
At the time of the effective filing date of the current application, it would have been obvious to a person of ordinary skill in the art to recognize the need for placing control commands send by the monitor server in the monitoring server command buffer taught by More et al. in the method of transmitting the control command from the server to the vehicular monitoring system of Zuo et al. in view of Takemori et al. because placing control commands send by the monitor server in the monitoring server command buffer would improve performance of the messaging system.
Referring to claim 18, Zuo et al. in view of Takemori et al. and in view of More et al. disclose the method of claim 16, More et al. disclose wherein a cryptographic hash of each of the buffers is computed in response the corresponding buffer if full (i.e. the command buffer management module 134 may send a “queue full” message to the first initiator device 150 in response to one or more commands received from the first initiator device 150 while the flag 127a is asserted. The command buffer management module 134 may send a buffer full message 139 to the first initiator device 150 (e.g., to indicate that the first portion 130 is “full”) in response to the one or more commands. The buffer full message 139 may indicate that a remaining allowed storage size of the command buffer 128 for the first initiator device 150 is zero) (page 4 paragraph 0035; see Figure 1).
Claims 19, 20 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Zuo et al. (CN 107948307) in view of Takemori et al. (WO 2018/029905) as applied to claim 1, and further in view of Seymour (Pub. No. US 2010/0159868).
Referring to claim 19, Zuo et al. in view of Takemori et al. disclose the method of claim 1, however, Zuo et al. in view of Takemori et al. did not explicitly disclose further comprising: receiving signal faults from the vehicle; determining not to trigger an emergency handling system in response to the signal faults being within a threshold of time.
In the same field of endeavor of a control communication system, Seymore teaches further comprising: receiving signal faults from the vehicle; determining not to trigger an emergency handling system in response to the signal faults being within a threshold of time (i.e. a determination is made as to whether the primary communication channel 134 is communicatively coupled to the existing safety system 132, some other communication network, or some device coupled to a communication network. The primary communication channel 134 is configured to preferentially transmit emergency messages to the existing safety center 136) (page 3 paragraph 0029; see Figure 1) in order to make a request of emergency assistance automatically to the call center promptly.
At the time of the effective filing date of the current application, it would have been obvious to a person of ordinary skill in the art to recognize the need for determining not to trigger an emergency handling system in response to the signal faults being within a threshold of time taught by Seymour in the method of providing security communication between the vehicular monitoring system and the server of Zuo et al. in view of Takemori because determining not to trigger an emergency handling system in response to the signal faults being within a threshold of time would improve first responder response time in the need of request of emergency assistance.
Referring to claim 20, Zuo et al. in view of Takemori et al. and Seymour disclose the method of claim 19, Seymour discloses wherein the threshold of time is determined based on
a longest tunnel known to exist on a route the vehicle is scheduled to travel on (i.e. a determination is made as to whether the primary communication channel 134 is communicatively coupled to the existing safety system 132, some other communication network, or some device coupled to a communication network. The primary communication channel 134 is configured to preferentially transmit emergency messages to the existing safety center 136) (page 3 paragraph 0029; see Figure 1).
Referring to claim 22, Zuo et al. in view of Takemori et al. disclose the method of claim 1, however, Zuo et al. in view of Takemori et al. did not explicitly disclose wherein the second message digest from the vehicle is received over an emergency channel.
In the same field of endeavor of a control communication system, Seymore teaches the second message digest is received from the vehicle over an emergency channel (134) that is dedicated for communications for handling an emergency (i.e. a determination is made as to whether the primary communication channel 134 is communicatively coupled to the existing safety system 132, some other communication network, or some device coupled to a communication network. The primary communication channel 134 is configured to preferentially transmit emergency messages to the existing safety center 136) (page 3 paragraph 0029; see Figures 1 to 3) in order to make a request of emergency assistance automatically to the call center promptly.
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Zuo et al. (CN 107948307) in view of Takemori et al. (WO 2018/029905) as applied to claim 1, and further in view of Watanabe et al. (US# 11,284,232).
Referring to claim 21, Zuo et al. in view of Takemori et al. disclose the method of claim 1, however, Zuo et al. in view of Takemori et al. did not explicitly disclose further comprising: determining that immediate intervention is required; and transmitting a control command with high priority over any local commands being processed by the vehicle.
In the same field of endeavor of a vehicle control system, Watanabe et al. teach further comprising: determining that immediate intervention is required; and transmitting a control command with high priority over any local commands being processed by the vehicle (i.e. the transmission control unit 212 transmits the control commands received by the communication units 270 to the control ECU 800 in order according to the priority order that gives the priority on the control command having the longest distance calculated in step SB1 (step SB2)) (column 19 lines 8 to 60; see Figures 7-8) in order to control the actions of the vehicle.
At the time of the effective filing date of the current application, it would have been obvious to a person of ordinary skill in the art to recognize the need for the transmission control unit transmits the control commands to the vehicle control unit in order according to a prescribed priority order taught by Watanabe et al. in the method of providing security communication between the vehicular monitoring system and the server of Zuo et al. in view of Takemori because having the need for the transmission control unit transmits the control commands to the vehicle control unit in order according to a prescribed priority order would improve operation of the actions of the vehicle.
Claim 23 is rejected under 35 U.S.C. 103 as being unpatentable over Zuo et al. (CN 107948307) in view of Takemori et al. (WO 2018/029905) and in view of Seymour (Pub. No. US 2010/0159868) as applied to claim 19, and further in view of Yu et al.(Pub. No. US 2017/0308098).
Referring to claim 23, Zuo et al. in view of Takemori et al. and Seymour disclose the method of claim 19, however, Zuo et al. in view of Takemori et al. and Seymour did not explicitly disclose further wherein the Emergency Handling System comprises: receiving geolocation information from the vehicle; and transmitting one or more control commands to navigate the vehicle to a safe location.
In the same field of endeavor of a control communication system, Yu et al. teach the emergency handling service comprises: receiving geolocation information from the vehicle (i.e. coordination of the delivery operations may be performed by an operations hub. To perform this, the operations hub may have personnel and equipment to remotely operate the vehicle, communicate with the vehicle (e.g. for sending commands, receiving monitoring information from the vehicle, etc.), and/or remotely monitor the vehicle) (page 6 paragraph 0072; see Figures 6-7) and the delivery destinations can be designated in any suitable manner to identify its location, such as GPS (global positioning system) coordinates, cellular network, and/or postal address as recognized by the postal service, emergency services (fire, ambulance, etc.), mapping agencies or firms, or courier services, etc. For example, a delivery destination may be designated as 1250 Main Street, Anytown, Mass. 90210 (fictitious address). The delivery destinations can be specified in even more detail (e.g. a specific side of a corner or a specific side of a building). Non-limiting examples of delivery destinations include residences and businesses, such as restaurants, offices, retail stores, etc.) (page 8 paragraph 0110; see Figures 6-14) and transmitting one or more control commands to navigate the vehicle to a safe location (i.e. the technical problems that can trigger this response may include one or more of: mechanical problem (e.g. flat tire), electrical problem (e.g. light beacon not working), electromechanical problem (e.g. electric motor malfunction), communication problem (e.g. loss of communication link), low battery charge, or low fuel. Detection and/or response to the problem may be performed autonomously or semi-autonomously (i.e. under a combination of human and autonomous control). For example, the vehicle may detect and assess the technical problem on its own and find safe parking on its own; or the problem may be assessed at the operations hub and the operations hub commands or guides the vehicle to a safe parking area; or some combination of these actions (page 5 paragraph 0055) in order to provide exact location for delivery service
At the time of the effective filing date of the current application, it would have been obvious to a person of ordinary skill in the art to recognize the need for triggering a response when there is an emergency and navigating the vehicle to a safe location taught by Yu et al. in the method of providing security communication between the vehicular monitoring system and the server of Zuo et al. in view of Takemori et al. and Seymour because triggering a response when there is an emergency and navigating the vehicle to a safe location would improve efficiency for making a delivery service.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Refer to the enclosed PTO-892 for details.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NAM V NGUYEN whose telephone number is 571-272-3061. The examiner can normally be reached on 8:00AM-5:00PM M-F.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Quan-Zhen Wang can be reached on 571-272-3114. The fax phone numbers for the organization where this application or proceeding is assigned are 571-273-8300 for regular communications.
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).
/NAM V NGUYEN/
Primary Examiner, Art Unit 2685
Prosecution Insights