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 .
This Office action is responsive to the communication filed on 03/21/2024. The claims 1- 20 are pending, of which the claim(s) 1, 12, 20 is/are in independent form.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
I) Claim 12 provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of co-pending Application No. 18/756312 (reference application, filed on 05/26/2026). Although the claims at issue are not identical, they are not patentably distinct from each other because the co-pending application’s claim renders obvious the claim(s) 1 of the instant application as set forth below.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Instant Application: 18/612797
Co-Pending Application: 18/756312 of 05/26/2026
12. An electronic control unit for controlling operation of a vehicle, the electronic control unit comprising
A system comprising:.. a central control unit of the vehicle comprising
a first processor configured to execute applications associated with the vehicle;
a remote operator via a remote teleoperation device to actuate the
one or more subsystems
a safety and control interface configured to:
receive a request for a service from an application executed by the first processor; and
an application processor configured to execute a remote control application that receives the instructions from the remote teleoperation device
perform a safety check to determine whether the application is allowed to
utilize the service; and
the safety processor configured to:
arbitrate the requests from the remote control application by determining whether the requests satisfy safety rules for the vehicle.,.. in response to the requests satisfying the safety rules
a second processor configured to execute the service or deny the service based on the safety check.
the safety processor configured to:…cause the one or more subsystems to perform the at least one operation associated with the instructions.
The co-pending application’312’s claim 1 uses safety processor to perform safety check, PHOSITA can clearly understand that this function can be moved to the an application processor as part of the design choice of how to distribute jobs/tasks between two available processors. Thus, claim 12 of the instant application is unpatentable over claim 1 of the co-pending application’312.
II) Claim 12 provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of co-pending Application No. 18606548 (reference application, filed on 12/18/2025).
Although the claims at issue are not identical, they are not patentably distinct from each other because the co-pending application’s claim renders obvious the claim(s) 1 of the instant application as shown below. This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Instant Application: 18/612797
Co-Pending Application: 18/606548 of 12/18/2025
12. An electronic control unit for controlling operation of a vehicle, the electronic control unit comprising
1. A system comprising:.. central control unit of the vehicle, the central control unit comprising
a first processor configured to execute applications associated with the vehicle;
a first processor configured to execute applications associated with
the vehicle that output requests to perform operations using the one or more subsystems;
a safety and control interface configured to:
receive a request for a service from an application executed by the first processor; and
a second processor configured to maintain an operating state of the vehicle within a safe operating envelope of the vehicle, wherein the second processor receives the requests from the applications executed by the first
processor to perform the operations and outputs commands to the one or more subsystems of the vehicle to perform the operations based on the requests satisfying safety rules for the
perform a safety check to determine whether the application is allowed to
utilize the service; and
perform the operations based on the
requests satisfying safety rules for the vehicle
a second processor configured to execute the service or deny the service based on the safety check.
a vehicle subsystem actuator of a subsystem of the one or more subsystems
configured to actuate responsive to receiving at least one of the commands to cause
the subsystem to perform at least one of the operations.
Therefore, the claim 1 of the co-pending application 18/606548 teaches/suggests each limitation of the claim 12 of the instant application and renders invention thereof obvious to PHOSITA.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
In claims: 1-9 & 12- 20:
“safety and control interface”: In Figs. 2 & 4, shown as item 132 having logics and memory 410 as part of the CPU 120 used as an electronic control unit for a vehicle; see paras. 1051, 064, 0066, 20101. Also see dependent clams 10-11.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1- 4, 7, 9- 10, & 12- 14 is/are rejected under 35 U.S.C. 102(a) (2) as being anticipated by Budz et al. (US 20240321024 A1).
Regarding claim 1, Budz teaches a system [system 100 of Budz having flow diagram 500/600] comprising: (Figs. 1-2, 5-6 [052]);
[a] one or more subsystems [“various systems of a vehicle”, e.g., brakes, door pod etc., of the vehicle] of a vehicle [one of “vehicle 106 and vehicle 108”], each of the one or more subsystems configured to perform an operation of the vehicle (Fig. 1-2, 5-6, [054, 060, 084]);
[b] a first processor [processor of the client computing device, e.g., Fig. 5, “client computing device 502” wirelessly communicating and sending command(s) to vehicle(s)] configured to execute applications [“client computing device 502 (e.g., a smartphone configured to execute an application to request the actuation of a system of a vehicle)”] associated with the vehicle ([074, 084, 091, 096]);
[c] a safety and control interface [ECU 210 and/or TCU 212/506 of fig. 2 and/or computing system 504/604 of figs. 5-6] configured to:
(c1) receive a request [“computing system 504 may be configured to receive the signal 516 that includes a request to actuate a system of a vehicle” or “a signal 520 (e.g., a signal including a vehicle actuation”] for a service [“vehicle actuation” such as wake up or open/lock the door etc., start up, shut down for the vehicle being provided from the mobile phone] from an application [client device’s application that being used by user to send vehicle actuation commands] executed by the first processor; (c2) determine whether [“determination of whether a vehicle actuation command is valid or invalid”, “the ECU (not shown) may perform operations including checking the validity of a vehicle actuation command” and/or “a requesting entity is authorized to actuate one or more systems” of step 712] the application has an application permission to access the service; and (c3) determine whether [“and determining whether a vehicle is in a safe state (e.g., brakes of a vehicle are locked, and a vehicle is not moving) that allows a vehicle to implement a vehicle actuation command”] executing the service would maintain a safety goal [“operational safety”] established for the vehicle ([3004-4009, 069-070, 083-087, 093, 0107, 50110]); and
[c] a second processor [“BCM 508/208” and/or any processor used by the door pod 510 to process BCM’s signal 524 and generate signal 526 to control the door latch 512 or processor of the subsystem of the vehicle that process ECU/TCU’s commands] configured to execute [Fig. 7, Step 722, e.g., “determining that a vehicle is in a safe operational state that will allow a vehicle actuation command to be safely implemented by the one or more systems of a vehicle”] the service requested by the application based on the safety and control interface [the output of the safety and control interface is provided to the second processor to actually execute the command sent from the client’s device] determining that the application has the application permission to access the service and [Fig. 7 clearly shows that checking both authentication and safety rule before allowing execution of the commands in Step 722] that executing the service responsive to the request would maintain the safety goal established for the vehicle ([010, 066, 087-088, 015]).
Therefore, Budz teaches each limitation of the claim and clearly anticipates the invention of this claim.
Regarding claim 2, Budz teaches The system of claim 1, wherein the second processor, in being configured to execute the service, is configured to cause actuation of at least one of the one or more subsystems [e.g., “unlock the door latch 512”, cabin temperature, engine start/off] of the vehicle ([088, 0101], Fig. 5).
Regarding claim 3, Budz teaches the system of claim 1, wherein the request includes the application permission ([006, 0106]).
Regarding claim 4, Budz teaches the system of claim 3, wherein the application permission is provided to the application for inclusion in the request by an authentication service [“authorization”] ([006, 098]).
Regarding claim 7, Budz teaches the system of claim 1, wherein the application permission is implemented to satisfy, at least in part, a safety rule [e.g., rental period of the vehicle is active or expired checking or the vehicle is in “authorized geographic area”] applied to the vehicle ([002, 004, 0100]).
Regarding claim 9, Budz teaches the system of claim 1, wherein the safety and control interface [TCU/ECU can see the commands sent by the client to control the function of the BCM] is configured to intercept the request sent from a connection between the first processor [customer’s computing device 502] and the second processor [BCM of the vehicle or the subsystem controlling computer system of the vehicle] ([090], Figs. 5-6 & associated texts).
Regarding claim 10, Budz teaches the system of claim 1, wherein the safety and control interface is configured as part of a connection [ the TCU is in between the client and the BCM or the door pod] between the first processor and the second processor ([086-087], Fig. 5).
Regarding claim 12, the rejection discussed in claim 1 is incorporated. Thus, only in summary, Budz teaches an electronic control unit [ECU 608] for controlling operation of a vehicle, the electronic control unit comprising: (Figs. 5- 6, [065]);
[a] a first processor [processor of the user’s computing device, “client computing device 602”] configured to execute applications [“may access a software application (e.g., a mobile application)”] associated with the vehicle ([091]);
[b] a safety and control interface [one or more of the TCU, ECU or BCU] configured to: receive a request [command sent from client, e.g., signal 614/516/520, “client computing device 502 may generate the request and send signal 516 comprising the details of the request”] for a service from an application executed by the first processor; and perform a safety check [Fig. 7, Steps 712 and/or 718] to determine whether the application is allowed to utilize the service (Figs. 5- 7, [084-087]); and
[c] a second processor [“BCM 508” and/or computer that process output of the BCK 508 such as door pod 510 to control door latch 512] configured to execute [Steps 718 and 722, “after a vehicle is determined to be in a safe operational state, an engine of a vehicle may be started up and one or more doors of a vehicle may be unlocked”] the service or deny [step 720] the service based on the safety check ([087-088, 0112- 0115], Figs. 5, 7). Thus, Budz clearly anticipates the invention of this claim.
Regarding claim 13, Budz teaches the electronic control unit of claim 12, wherein, in being configured to perform the safety check [step 718 of fig. 7], the safety and control interface is configured to determine whether the application has an application permission [authorization or valid/invalid] required to access the service (Fig. 7, [097-0098, 0107]).
Regarding claim 14, Budz teaches the electronic control unit of claim 13, wherein, in being configured to perform the safety check, the safety and control interface is configured to, responsive to determining that the application does not [No in Step 706 or 712] have the application permission required to access the service, discard [“If the message is not from an authorized entity or otherwise invalid, a vehicle systems will not be activated.”] the request and instruct the second processor to deny the service (Fig. 7, [080, 0103]).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries 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.
Claim(s) 5-6 & 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Budz.
Regarding claims 5-6, Budz further teaches the system of claim 1, wherein the safety and control interface is further configured to receive the safety goal (See “brakes of a vehicle are locked” or not, “vehicle is not moving”] ([0110, 077] in step 716 of fig.7 shows safe operation state is checked).
However, Budz still fails to explicitly teach when and who provides these safety goals (vehicle not moving, brakes are not locked) checking rules to the computer of the vehicle of Budz so that these safety rules are checked in method of fig. 7. Thus, Budz may not teach its receive the “safety goal” is:
Claim 5- “as part of a commissioning process” and
Claim 6- “is defined by a manufacturer of the vehicle during the commissioning process”.
Nevertheless, Budz implicitly teaches/suggests both of the missing limitations of the claims 5- 6 as well. Specifically, PHOSITA knows that since typical drivers who use the various types (like boats, trucks) of the vehicles (see, para.060) of Budz do not know which safety goals/features are important/not-important to enforce before allowing/disallowing one or more “vehicle actuation command” and also would not know how to program various safety goals, providing/programming such safety goals to the computer(s) of the vehicles during commissioning process by the vehicle manufacturers would have been obvious. The motivation of doing so would have been to allow vehicle manufacturers to be assured that vehicles manufactured by them meet the government’s safety standards and the safety rules will not be bypassed even when the users do not know how to program such safety rules.
Regarding claim 11, Budz teaches the system of claim 1 including the safety and control interface [computing system 504/604 or ECU 608] (Fig. 5-6, [085-086]).
However, Budz may not explicitly teach “the safety and control interface includes
one or more application programming interfaces and exposes the one or more
application programming interfaces to the application” as claimed.
However Budz implicitly teaches/suggests to the PHOSITA that the safety and control interface includes one or more application programming interfaces and exposes the one or more application programming interfaces to the application as claimed ([085-086], Fig. 5- 6 of Budz show the computing system 504 or ECU 608. PHOSITA knows that the computing system and ECU are well -known to include APIs in order to allow exchanging of data/message/notification to the clients 502 & 514). See MPEP 2144.01.
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Budz in view of Robertson et al. (US 20160004535 A1).
Regarding claim 8, Budz teaches the system of claim 7, wherein the safety rule is implemented to satisfy Asafe operation of the vehicle ([0131-0133]).
However, Budz may not teach its implementing of the safe operation of the vehicle while processing the actuation commands is to “satisfy Automotive Safety Integrity Level D (ASIL D)” as claimed.
Robertson teaches a system with a processor used in high safety-level applications. Specifically, Robertson teaches a system comprising: a safety and control interface configured to perform an operation of the vehicle wherein the safety rule is implemented to satisfy Automotive Safety Integrity Level D (ASIL-D) operation [“when a high-safety function is to be executed, such as when the instruction executed is an instruction associated with a ASIL-C or ASIL-D level function.”] of the vehicle ([018, 021]).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to (1) combine Robertson and Budz because they both related to using a computer system of vehicle for safety goal during remote controlling of the vehicle and (2) modify the safety rule of Budz is implemented to satisfy Automotive Safety Integrity Level D (ASIL-D) operation of the vehicle as in Robertson. Doing so would ensure that high-safety functions to be included for execution in the vehicles of the Budz (Robertson [021]).
Claim(s) 15-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Budz in view of Kafzan (US 20250055871 A1).
Regarding claim 15, Budz teaches the electronic control unit of claim 13, wherein, in being configured to perform the safety check, the safety and control interface is configured to, responsive to determining that the application does have the application permission required to access the service, determine whether [step 716 is based on completing of the steps 706 and step 710] the service is maintains
Budz does not teach to determine whether the service is associated with one or more safety goals. That is, Budz’s vehicle does not discriminate the commands as safety related and not safety related as claimed.
Kafzan relates to monitoring and inspecting remotely provided commands [“monitored messages”] for transportation vehicle(s) [railway fleet networks] and calculating of the message sensitivity levels by considering safety goals ([006-007, 016]). Specifically, Budz teaches an electronic control unit for controlling operation of a vehicle the electronic control unit comprising: a safety and control interface configured to: receive a request [“An intercepted message/communication… message carried command(s) may accordingly be evaluated”, analogous to Budz’s commands provided from client computing device 502] for a service from an application executed by the first processor; and responsive to determining that the application does have the application permission required to access the service, determine [determining “the inspected message sensitivity level rank is high” or “low” by factoring “operation and/or safety”] whether the service is associated with one or more safety goals ([059-060, 076, 0113-0115], Fig. 4E).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to (1) combine Kafzan and Budz because they both related to performing safety check to the remotely provided requests for service for a vehicle operation and (2) modify the a safety and control interface of Budz to determine whether the received request for service is associated with one or more safety goals responsive to determining that the application does have the permission required to access the service as in Kafzan. Doing so would allow assuring compliance during processing of the received service requests and avoid unnecessary processing burden for low risk (not safety related) service requests thereby saving processing resources of the vehicle(s) (Kafzan [060, 075]).
Regarding claim 16, Budz in view of Kafzan teaches/suggests the electronic control unit of claim 15, wherein, in being configured to perform the safety check, the safety and control interface is configured to, responsive to determining that the service is not associated with the one or more safety goals, instruct [applying the idea of “if the inspected message sensitivity level rank is low, then (b) Flagging the inspected message for review and/or reporting it and allowing to continue to the message's target transportation network management unit” in Budz (e.g., to change “cabin temperature” setting by couple degrees while vehicle is moving as can be clear to PHOSITA) system to continue the command without safety check if they are not related to (having low effect) safety goal to minimize processing burden since the commands do not pose safety threat anyway] the second processor to execute the service (Kafzan [0115] & Budz Fig. 7 [017]).
Regarding claim 17, Budz in view of Kafzan teaches/suggests the electronic control unit of claim 15, wherein, in being configured to perform the safety check, the safety and control interface is configured to, responsive to determining that the service is associated with the one or more safety goals [using idea of “if the inspected message sensitivity level rank is high, then (a) Flagging and blocking the inspected message from reaching the message's target transportation network management unit, until further processing has cleared and released the message” to perform step 718 in Budz since the commands appear high risky/safety related], instruct the second processor to determine whether the one or more safety goals would be maintained if the service is executed (Kafzan [0115] & Budz Fig. 7 [0115-0116]).
Regarding claim 18, Budz in view of Kafzan teaches/suggests the electronic control unit of claim 17, wherein, in being configured to perform the safety check, the safety and control interface is configured to, responsive to determining that the one or more safety goals would be maintained if the service is executed, instruct [step 722 of Budz] the second processor to execute the service (Kafzan [0115] & Budz Fig. 7 [110, 0115-0116]).
Regarding claim 19, Budz in view of Kafzan teaches/suggests the electronic control unit of claim 17, wherein, in being configured to perform the safety check, the safety and control interface is configured to, responsive to determining [No in Steps 716 & 718 of Budz] that the one or more safety goals would not be maintained if the service is executed, discard the request and instruct the second processor not to execute the service (Kafzan [0115] & Budz Fig. 7 [0110, 0115-0116]).
Regarding claim 20, the rejection of claims 1 & 12 are incorporated. Thus, only in summary, Budz teaches a method comprising: (Fig. 7, [095]);
receiving, by a safety and control interface [Figs. 5-6, one or both of the TCU or ECU or the “computing system 504”] of an electronic control unit of a vehicle, a request [“At 702, a vehicle actuation command may be received.”] for a service from an application[“smartphone configured to execute an application to request the actuation of a system of a vehicle” used by the client device 502] ([084, 096]);
determining [checking request is valid or not and/or checking the request is authorized request or not], by the safety and control interface, whether [steps 706 and 712] the application has a permission to access the service ([0103-0107, 0137]);
responsive to determining that the application has the permission to access the service, determining, by the safety and control interface, whether vehicle can maintain a safety goal ([0107-110]);
responsive to determining that the vehicle can maintain vehicle is in a safe operational state, one or more systems of a vehicle may be actuated”] the service, at least in part, by actuating one or more subsystems of the vehicle (Fig. 7, [086-088, 0109-0112]).
Budz may not teach “determining, by the safety and control interface, whether the service is associated with a safety goal” as claimed a since Budz appear to checking safety goal for each request. Thus, Budz may not teach the limitation shown with strikethrough emphasis but this limitation is cured by Kafzan as discussed above.
Kafzan teaches A method comprising: receiving, by a safety and control interface of an electronic control unit of a vehicle, a request [“given message”] for a service from an application; responsive to determining that the application has the permission to access the service, determining [checking of “message sensitivity level” in fig. 4E], by the safety and control interface, whether the service is associated with a safety goal; responsive to determining that the service is associated with the safety goal [“high” sensitivity message], determining, by the safety and control interface, whether [performing of “further processing” before allowing the message to reach the “target transportation network management unit”] the safety goal would be maintained if the service is executed ([060, 0113-0115]). Thus, Kafzan clearly cures Budz’s deficiency.
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to (1) combine Kafzan and Budz because they both related to performing safety check to the remotely provided requests for service for a vehicle operation and (2) modify the a safety and control interface of Budz to determine whether the service is associated with a safety goal after determining that the application has the permission to access the service and perform checking of whether the safety goal would be maintained if the service is executed as in Budz.
Doing so would allow assuring compliance during processing of the received service requests at the vehicles sent from the remote location using client device and avoid unnecessary processing burden for low risk (not safety related) service requests (Kafzan [060, 075]). Accordingly, Budz in view of Kafzan teaches each elements of the claim and renders invention thereof obvious to PHOSITA.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
1) Kato (US 20260034998 A1) teaches autonomous driving vehicle executes the autonomous driving based on the signal and an operation instruction from the operation terminal ([008]).
2) McKendrick et al. (US 20240059322 A1) teaches determining whether it is for the autonomous to implement one or of the updated planned trajectory or the planned behavior ([082]).
Contacts
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SANTOSH R. POUDEL whose telephone number is (571)272-2347. The examiner can normally be reached Monday - Friday (8:30 am - 5:00 pm).
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, Kamini Shah can be reached at (571) 272-2279. 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.
/SANTOSH R POUDEL/ Primary Examiner, Art Unit 2115
1 “safety and control interface 132 is configured to implement, at least in part, one or more of the APIs 116”
2 “the safety and control interface 132 includes an authentication module 404”
3 “There may be a determination of whether a vehicle actuation command is valid or invalid. Based on a vehicle actuation command being valid, there may be a determination of whether a requesting entity is authorized to actuate the one or more systems of a vehicle. Based on a requesting entity being authorized to actuate the one or more systems of a vehicle, there may be a determination of whether a vehicle is in a safe operational state that will allow a vehicle actuation command to be safely implemented by the one or more systems of a vehicle”
4 “The BCM and/or the TCU may be configured to determine whether a requesting entity is authorized to actuate the one or more systems of a vehicle.”
5 “At step 716, a system may determine whether a vehicle is in a safe operational state… safe operational state may be performed by one or more systems of a vehicle including one or more ECUs of a vehicle, a BCM of a vehicle, and/or any system of a vehicle that may monitor the state of a vehicle”.
Prosecution Insights