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 .
DETAILED ACTION
The office action is in response to the application filed on . Claims 1-15 are pending in this application. Claims 1, 13 and 14 are independent claims.
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. 23215313 filed on 12/08/2023.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1 -15 are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, is directed to that judicial exception, an abstract idea, it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below.
Regarding claims 1, 13, 14 the limitations “selecting a target ECU for deploying the container from the plurality of ECUs based on the sets of capability information and the set of requirement information so that the capability of the target ECU described by the set of capability information of the target ECU satisfies the required ECU capability described by the set of requirement information of the container,” as drafted, is a function that, under its broadest reasonable interpretation, recite the abstract idea of a mental process. These limitations encompass a human mind carrying out these functions through observation, evaluation judgment and /or opinion, or even with the aid of pen and paper. Thus, this limitation recites and falls within the “Mental Processes” grouping of abstract ideas under Prong 1 step 2A.
Under Prong 2 step 2A, the judicial exception is not integrated into a practical application. The additional elements “for deploying software in a vehicle…” is generally linking the use of the judicial exception to a particular technological environment or filed of use, see MPEP 2106.05(f), and the additional elements ”obtaining a set of capability information for each of a plurality of electronic control units (ECUs) of the vehicle…”, and “In response to a container of the software being available for deployment…” do nothing more than add insignificant extra solution activity to the judicial exception of merely gathering data, see MPEP 2106.05(g). Accordingly, the additional elements do not integrate the recited judicial exception into a practical application and the claim is therefore directed to the judicial exception. See MPEP 2106.05(f) and (g), respectively.
Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As stated above in prong 2, the additional elements “for deploying software in a vehicle…” is generally linking the use of the judicial exception to a particular technological environment or filed of use, and the additional element ”obtaining a set of capability information for each of a plurality of electronic control units (ECUs) of the vehicle…”, and “In response to a container of the software being available for deployment…” is merely gathering data which the courts have identified as well-understood, routine conventional activity. See for example Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362, MPEP 2106.05(d). Therefore, the additional elements do not amount to significantly more, thus, cannot provide an inventive concept. Accordingly, the claims are no t patent eligible under 35 USC 101.
Regarding claim 2, the limitation “comparing the sets of capability information…” recites the function that can be mentally done in human mind under Prong I step 2A. Therefore, there is no additional elements that would integrate the judicial exception into a practical application.
Regarding claim 3, 4, 5, 6, and 12, the limitations recited in these claims merely describe the data being classified in claim 1, thus, are likewise analyzed under Prong 1 as mental process.
Regarding claim 7, the limitations “determining availability of the container…” recites the functions that can be mentally done in human mind under Prong I step 2A. The other limitations “at the controller”; “a server over an over-the-air (OTA) connection…”; and “downloading the container…” are the additional elements that recites at a high-level of generality such that it amounts no more than mere instructions to apply the exception using generic computer, and/or generic computer components. See MPEP 2106.05(f); and merely gathering data which the courts have identified as well-understood, routine conventional activity. Therefore, the additional elements as recited do not integrate the judicial exception into a practical application.
Regarding claim 8, the limitations “verifying the container…” recites the functions that can be mentally done in human mind under Prong I step 2A. The other limitations “at the controller “; “storing the container in a local registry …”; and “updating the container in the local registry…” are the additional elements that recites at a high-level of generality such that it amounts no more than mere instructions to apply the exception using generic computer, and/or generic computer components. See MPEP 2106.05(f); and merely gathering data which the courts have identified as well-understood, routine conventional activity. Therefore, the additional elements as recited do not integrate the judicial exception into a practical application.
Regarding claim 9, the limitations “determining whether the vehicle is in a valid state…”; “delaying or proceeding,” recite the functions that can be mentally done in human mind under Prong I step 2A. . The other limitations “at the controller” is the additional element that recites at a high-level of generality such that it amounts no more than mere instructions to apply the exception using generic computer, and/or generic computer components. See MPEP 2106.05(f); and merely gathering data which the courts have identified as well-understood, routine conventional activity. Therefore, the additional elements as recited do not integrate the judicial exception into a practical application.
Regarding claim 10, the limitations “deploying the container to the target…” recites the functions that can be mentally done in human mind under Prong I step 2A. The other limitations “at the controller” is the additional element that recites at a high-level of generality such that it amounts no more than mere instructions to apply the exception using generic computer, and/or generic computer components. See MPEP 2106.05(f); and merely gathering data which the courts have identified as well-understood, routine conventional activity. Therefore, the additional elements as recited do not integrate the judicial exception into a practical application.
Regarding claim 11, the limitations “installing the container …” ; “verifying a state of installing…”; “responsive to a fail in verifying “; “uninstalling the container and recovering…” recite the functions that can be mentally done in human mind under Prong I step 2A. The other limitations “at the target ECU” is the additional element that recites at a high-level of generality such that it amounts no more than mere instructions to apply the exception using generic computer, and/or generic computer components. See MPEP 2106.05(f); and merely gathering data which the courts have identified as well-understood, routine conventional activity. Therefore, the additional elements as recited do not integrate the judicial exception into a practical application.
Regarding claims 13, claim 13 recites further additional element “a processor configured to perform”, The additional element is recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using generic computer, and/or generic computer components. See MPEP 2106.05(f). Therefore, the additional elements recited in claims 13 do not integrate the judicial exception into a practical application under prong 2, nor amount to significantly more under step 2B.
Regarding claim 14, claim 14 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim does not fall within at least one of the four categories of patent eligible subject matter because they cover both statutory and non-statutory embodiments (under the broadest reasonable interpretation of the claim when read in light of the specification and in view of one skilled in the art) and embraces subject matter that is not eligible for patent protection, and therefore is directed to non-statutory subject matter.
“a computer program product … is not a “process, machine, manufacture, or composition of matter.” Those four categories define the explicit scope and reach of subject matter patentable under 35 U.S.C. § 101; thus, such a software cannot be patentable subject matter.” Claim 14 recites “a computer program product” The claim does not fall within at least one of the four categories of patent eligible subject matter because the claim is directed to a software per se as it only comprising the instructions. As a result, the claim is drawn to a medium that covers transitory embodiments. Thus, the claim is not eligible under 35US 101.
Regarding claim 15, claim 15 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim does not fall within at least one of the four categories of patent eligible subject matter because they cover both statutory and non-statutory embodiments (under the broadest reasonable interpretation of the claim when read in light of the specification and in view of one skilled in the art) and embraces subject matter that is not eligible for patent protection, and therefore is directed to non-statutory subject matter.
“[a] computer-readable data carrier … is not a “process, machine, manufacture, or composition of matter.” Those four categories define the explicit scope and reach of subject matter patentable under 35 U.S.C. § 101; thus, such a signal cannot be patentable subject matter.” (In re Petrus A.C.M. Nuijten; Fed Cir, 2006-1371, 9/20/2007). Claim 15 recites “a computer-readable data carrier” The claim does not fall within at least one of the four categories of patent eligible subject matter because the claim is directed to a signal per se. As a result, the claim is drawn to a medium that covers transitory embodiments. Thus, the claim is not eligible under 35US 101.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-7, 9-10, 12-15 are rejected under 35 U.S.C. 103 as being unpatentable over Negishi (US 11377056 B2) in view of Joshua (EP 4242834 A1).
Regarding claim 1, Negishi teaches A computer-implemented method for deploying software in a vehicle, the computer-implemented method comprising, at a controller of the vehicle:
obtaining a set of capability information for each of a plurality of electronic control units (ECUs) of the vehicle, each set of capability information describing a capability of a respective electronic control unit (ECU) of the plurality of ECUs (Fig. 1, 120- Resource Specify; Col 6, third paragraph:” The resource specifying unit 120 collects resource information at a predetermined timing by communication with each ECU 100. The resource information is data that enables calculation of provision resource. For example, the utilization rate of the processor 101 (so-called CPU utilization rate), the utilization rate of the memory 102, the clock frequency, the free space of the storage 103, the network utilization rate, and the number of provided services and the number of used services can be used as resource information. The resource specifying unit 120 specifies the provision resource based on the collected resource information.” Examiner notes the provision resource includes utilization of CPU, memory, network, clock frequency, free space, number of provided services, etc. it is considered capability of a respective electronic control unit (ECU) of the plurality of ECUs);
in response to a container of the software being available for deployment, obtaining a set of requirement information of the container, the set of requirement information describing a required ECU capability required by the container for deployment on one or more of the plurality of ECUs (Fig. 1, 130- Request Specify; Col. 7, lines 3-17: “The request specifying unit 130 specifies a request resource that is a resource requested by the additional application acquired by the application acquisition unit 110. The request specifying unit 130 specifies the request resource, for example, by reading information for specifying an execution environment of the application attached to the installation file of the additional application. The information for specifying the execution environment includes, for example, the operating state of the vehicle 1 assumed to be executed, the clock frequency of the processor 101, the utilization rate of the processor 101 and the memory 102 when executed, the free space of the storage 103 required for installation, the usage rate of the network and the like which are set in advance.” Examiner notes the request resource includes utilization of CPU, memory, network, clock frequency, number of provided services, etc. it is considered the required ECU capability required by the container for deployment on one or more of the plurality of ECUs);
and selecting a target ECU for deploying the container from the plurality of ECUs based on the sets of capability information and the set of requirement information so that the capability of the target ECU described by the set of capability information of the target ECU satisfies the required ECU capability described by the set of requirement information of the container (Fig. 1, 140- Select; Col. 7, lines 40-43:“The selection unit 140 selects, from among the ECUs 100, one of the ECUs 100 which has the provision resource satisfying the request resource as an installation destination of the application.” As noted above provision resource is considered capability of the target ECU and request resource is interpreted as capability requirement information of the container).
Negishi does not teach installation of containers to ECUs.
Joshua teaches installation of containers to ECUs (Col. 5 [0025], lines 4-12: “The method is performed by a vehicle system for handling configuration of a vehicle. The vehicle system inflates one or more containers. A container is a logical structure representing a segmented part of the vehicle's operating system resources and that are separated from other operating system resources of the vehicle. The vehicle system initiates configuration of one or more ECU comprised in the vehicle to connect the one or more containers.”)
Negishi and Joshua are considered analogous to the claimed invention because they are both techniques for deploy software in a vehicle. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to utilize the teaching of Joshua “configuration, deploying container” into the teachings of Negishi in order expand the use of the method and to realize the advantages of deploying containers which includes implements only those interfaces required by the service running in the container rather than running the entire operating system and improves quality and speed for enabling the service on the vehicle.
Regarding Claim 2, Negishi in view of Joshua teach The computer-implemented method of claim 1 wherein selecting the target ECU includes, at the controller:
comparing the sets of capability information and the requirement information to determine the capability of the target ECU satisfying the required ECU capability (Negishi, Col. 7, lines 40-43: “The selection unit 140 selects, from among the ECUs 100, one of the ECUs 100 which has the provision resource (ECU) satisfying the request resource (Container) as an installation destination of the application” Examiner notes provision resource is interpreted as capability of the target ECU, request resource is interpreted as capability requirement information of the container and select implicitly includes comparing request resource against provision resource to pick out target ECUs that satisfy requirement container);
Regarding claim 3, Negishi in view of Joshua teaches The computer-implemented method of claim 2 wherein the requirement information describes a minimum of the required ECU capability that the capability of the target ECU is to satisfy (Nigishi, Col. 12, lines 40-45: “Alternatively, when the information for specifying the execution environment is not attached to the additional application, the request specifying unit 130 may adopt a configuration that uses a preset minimum level, a preset policy in order of priority, or the like as a request resource of the additional application.”).
Regarding claim 4, Negishi in view of Joshua teach The computer-implemented method of claim 1 wherein the requirement information includes a runtime environment requirement indicating, as the required ECU capability, a runtime environment required by the container to run on the one or more of the plurality of ECUs and/or a resource requirement indicating, as the required ECU capability, a resource required on the one or more of the plurality of ECUs to run the container (Negishi, Col. 7, lines 3-16: “The request specifying unit 130 specifies a request resource that is a resource requested by the additional application acquired by the application acquisition unit 110. The request specifying unit 130 specifies the request resource, for example, by reading information for specifying an execution environment of the application attached to the installation file of the additional application. The information for specifying the execution environment includes, for example, the operating state of the vehicle 1 assumed to be executed, the clock frequency of the processor 101, the utilization rate of the processor 101 and the memory 102 when executed, the free space of the storage 103 required for installation, the usage rate of the network and the like which are set in advance.”; Examiner notes request resource information includes execution environment which is the runtime environment required by the container to run on one or more of the plurality of the ECUs to run the container).
Regarding claim 5, Negishi in view of Joshua teach The computer-implemented method of claim 1 wherein the capability information includes a runtime environment capability indicating, as the capability, a runtime environment available at the ECU to run the container and/or a resource capability indicating, as the capability, a resource available at the ECU to run the container (Negishi, Col.7, lines 43-50: “The selection unit 140 selects an installation destination based on the provision resource, in which the additional application is in the operating state, selected among the provision resources specified by the resource specifying unit 120. That is, the provision resource corresponding to the operating state in which the additional application operates selects the ECU 100 that satisfies the request resource.”; Examiner notes provision resource corresponding to the operating state which is the runtime environment capability required by the container to run on one ECU).
Regarding claim 6, Negishi in view of Joshua teach The computer-implemented method of claim 5 wherein: the runtime environment includes information relating to one or more of an operating system, a software, a library, and a configuration parameter, and/or the resource includes information relating to one or more of a processor, a memory, a volume, a network device, an input/output device, and an accelerator (Negishi, Col. 7, lines 9-16: “ The information for specifying the execution environment includes, for example, the operating state of the vehicle 1 assumed to be executed, the clock frequency of the processor 101, the utilization rate of the processor 101 and the memory 102 when executed, the free space of the storage 103 required for installation, the usage rate of the network and the like which are set in advance.”
Regarding claim 7, Negishi teaches The computer-implemented method of claim 1 further comprising, at the controller (The gateway ECU 100f is the controller):
determining availability of the container or an update for the container at a server over an over-the-air (OTA) connection (Negishi, Fig. 3, Step S202 [Deliver Application] from server to Gateway ECU; Col. 5, lines 45-52: “The gateway ECU 100f is a device that exerts a connection function with the external device outside the in-vehicle system 10 by executing the specific application. The gateway ECU 100f cooperates with, for example, a wireless communication device, and exerts a function of connecting to a server or the like arranged in a data center by communication via a wireless base station and a public communication network.”; Col. 6, lines 1-7: “The application acquisition unit 110 acquires an additional application to be additionally installed in any of the ECUs 100 included in the in-vehicle system 10 from the outside of the in-vehicle system 10. The application acquisition unit 110 acquires the installation file of the additional application from the server device, for example, using the communication function of the gateway ECU 100f.”);
and downloading the container or the update from the server over the OTA connection (Implicit in Fig. 3, Step S202 [Deliver Application], Col. 8, lines 41-43: “In S202, when the server device distributes the application to the gateway ECU 100f, the gateway ECU 100f starts the process related to the installation assignment application”; Examiner notes the server delivers application to the gateway ECU via wireless communication device hence OTA);
Regarding claim 9, Negishi in view of Joshua teach The computer-implemented method of claim 1 further comprising, at the controller (The gateway ECU 100f is the controller):
determining whether the vehicle is in a valid state allowing the container to be deployed; and delaying or proceeding, based on the valid state, to select the target ECU (Negishi, Fig. 2, S101 – Receive Speed, S-102 Vehicle Stops; Col. 8 lines 8-13:” In S101, the vehicle speed transmitted from integrated ECU 100a is received. In S102, based on the vehicle speed received in S101, it is determined whether the vehicle 1 stops. When the vehicle 1 stops, the process proceeds to S103, and when the vehicle 1 does not stop, the process returns to S101.” Examiner notes the valid state for installation of the container is when the vehicle stops or under a speed threshold. Step S101 is repeated until the vehicle stops i.e. valid state for installation).
Regarding claim 10, Negishi in view of Joshua teach The computer-implemented method of claim 1 further comprising, at the controller: deploying the container to the target ECU for installation on the target ECU to deploy the software (Col. 7, lines 62-65: “The selection unit 140 transfers the installation file acquired by the application acquisition unit 110 to the ECU 100 selected as the installation destination.”).
Regarding claim 12, Negishi in view of Joshua teach The computer-implemented method of claim 1 wherein: the plurality of ECUs includes ECUs of different platforms, and the different platforms include at least one of different hardware platforms, different operating systems, different virtual runtime environments, different application programming interfaces ( Negishi, Col. 12, lines 5-12: “Alternatively, as long as each ECU 100 can provide a function to be used by the additional application, the platform software may not be completely identical (e.g. different) . For example, some of the ECUs 100 may utilize middleware not necessary for the additional application and not used in other ECUs 100 (e.g. middleware use in some but not others) . Alternatively, in some of the ECUs 100, the version of the operating system may be different from the other ECUs 100.”).
Claim 13 corresponds to apparatus claim of method claim 1; therefore, it is rejected under the same rationale in the system claim 1 as shown above.
Claim 14 corresponds to computer program claim of method claim 1; therefore, it is rejected under the same rationale in the system claims 1 as shown above.
Regarding claim 15, Negishi in view of Joshua teaches A computer-readable data carrier having stored thereon the computer program product of claim 14 (Col. 12, lines 60-62: “The computer programs may be stored, as instructions being executed by a computer, in a tangible non-transitory computer-readable medium.”).
Claims 8 is rejected under 35 U.S.C. 103 as being unpatentable over Negishi (US 11377056 B2) in view of Joshua (EP 4242834 A1) and in further view of Ye et al. (US 20170060559 A1)
Regarding claim 8, Negishi in view of Joshua teach The computer-implemented method of claim 7 further comprising, at the controller (The gateway ECU 100f is the controller):
Negishi in view of Joshua teach storing the container in a local registry of the vehicle or updating the container in the local registry using the update to make the container available for deployment (Negishi, Fig. 3 – Step S202; Col. 8, lines 41-43: “In S202, when the server device distributes the application to the gateway ECU 100f”; Col. 7, lines 62-65: “The selection unit 140 transfers the installation file acquired by the application acquisition unit 110 to the ECU 100 selected as the installation destination.” e.g. gateway ECU 100f receives the application from the server, stores the application in the gateway ECU before the selection unit (within the gateway) transfers the files to ECU selected as the installation destination thus the gateway unit acts as a local registry of the vehicle).
Negishi in view of Joshua do not teach verifying the container or the update;
Ye teaches verifying the container or the update (Pg. 1 [0016] lines 1-12:” More specifically, in the first stage, software may be delivered securely from a software repository of the update server to the vehicle. The update server may be configured to send the vehicle software updates in accordance with the configuration of the vehicle. These software updates to the most recent version of the software for the vehicle ECUs may be referred to herein as “approved versions.” In an example, these software updates may be distributed with a cryptographically-strong signature created using a per-application private key to provide authenticity, integrity, and non-repudiation and which is verifiable by the vehicle ECUs in the field.”);
Negishi in view of Joshua and Ye are considered analogous to the claimed invention because they are all techniques for deploy software in a vehicle. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to utilize the teaching of Ye “verifying the container or the update” into the teachings of Negishi in view of Joshua in order to verify authenticity, integrity, and non-repudiation of the container or update before installing, deploying of the container to verify that each component implemented in a processing system is compatible, valid and includes the appropriate software version.
Claims 11 is rejected under 35 U.S.C. 103 as being unpatentable over Negishi (US 11377056 B2) in view of Joshua (EP 4242834 A1) and in further view of Sarkar et al (US 20190324858 A1).
Regarding claim 11, Negishi in view of Joshua teach The computer-implemented method of claim 10 further comprising, at the target ECU:
installing the container to deploy the software (Negishi , Fig. 4, Step S306 – Execute Application; Col. 9, lines 29-30:”In S306, execution of the process concerning the function of the additional application is started”);
verifying a state of installing the container on the target ECU (Negishi, Fig. 3, Step S212 – Notify Success/Failure; Col. 7, lines 65-67: “In addition, the selection unit 140 notifies the server device of the success or failure of the installation of the additional application.”);
Negishi in view of Joshua do not teach in responsive to a fail in verifying, uninstalling the container and recovering a previous version of the container.
Sarkar teaches teach in responsive to a fail in verifying, uninstalling the container and recovering a previous version of the container( Sarkar, Fig. 3, Pg. 3, [0037] :”FIG. 3 shows a table 300 that contains various ECU software configurations in order to illustrate an example of a compatibility matrix or acceptable software configuration list for rollback. Rollback may be required when a software update at an ECU is unsuccessful in order to recover the ECU from an inoperable state. In order to make the ECU operable again, the software is “rolled back” to its previous software configuration. In another embodiment, a software operation can be performed on a plurality of ECUs, with some of the ECUs updating successfully and the other ECUs remaining in their original state. Based on incompatibilities of the updated software at one ECU with the original software at another ECU, this post-update configuration can leave the overall software configuration of the plurality of ECUs inoperable.”; and Fig. 4; Pg. 4, [0042]:” In box 402, an update operation is performed (from a first software configuration) on those ECUs that can be rolled back, i.e., rollback capable ECUs. In box 404, the method checks to see whether all of the rollback capable ECUs have been successfully updated to their intended final states. If the rollback capable ECUs have been successfully updated, the method proceeds to box 418, which is discussed later. However, if the rollback capable ECUs have not been successfully updated, the method moves to box 406 where the recovery process begins.” and [0043]:” At box 406, one or more recovery configurations for the ECUs is obtained. In box 408, a list is made for each of the one or more recovery configurations. For a selected recovery configuration, the list includes those ECUs that are to be rolled back in order to obtain the recovery configuration. In box 410, the method checks to see if a list is available; or if there is not a list, meaning that there are no recovery configurations available. If there is no list, the method proceeds to box 434 which indicates the update was unsuccessful. The indication of an unsuccessful update can be provided to the processing center 102. However if there is a list, the method proceeds to box 412. At box 412 an acceptable software configuration list is selected from the one or more lists available; the selected list requiring rollbacks on a least a number of ECUs. In box 414, rollback is performed on each of the ECUs in the selected acceptable software configuration list.);
Negishi in view of Joshua and Sarkar are considered analogous to the claimed invention because they are all techniques for deploy software in a vehicle. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to utilize the teaching of Sarkar “uninstalling the container and recovering a previous version of the container” into the teachings of Negishi in view of Joshua in order to rollback the containers to previous version to ensure the continuation of the operation of the vehicle in case of deployment failure.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
DE 102019217077 A1 discloses Vehicle System Has Selector Which Is Provided For Selecting Information Processors That Provides Deployment Resource That Meets Request Resource As Installation Target For Application.
WO 2025047135 A1 discloses an onboard device mounted in a vehicle, a resource calculation unit that calculates available resources; a feasibility determination unit that determines the feasibility of realizing functions assigned to other onboard devices; and a processing unit that performs processing to realize the functions assigned to the other onboard devices, which have been determined to be realizable by the feasibility determination unit.
WO 2024124474 A1 discloses method for upgrading components mounted on vehicle e.g. car, involves executing upgrading operation of vehicle, and suspending execution of upgrading operation of vehicle when traction battery fails or storage battery fails
US 20250315247 A1 discloses obtaining a software upgrade requirement of at least one electronic control unit ECU of a vehicle, where the at least one ECU is associated with a power battery or a storage battery of the vehicle; and when it is determined that the power battery or the storage battery is not faulty, performing an upgrade operation of the vehicle based on the software upgrade requirement; or when it is determined that the power battery or the storage battery is faulty, suspending an upgrade operation of the vehicle. The method can improve a success rate of upgrading a vehicle-mounted component.
JP 2018132995 A discloses acquiring information on a scene in which additional software operates, second acquisition means (120) for acquiring information on a scene in which set software operates, selection means (130) for selecting, as a candidate ECU in which the additional software is to be set, an ECU in which set software operating in a scene which does not occur at a same time as the scene in which the additional software operates from among a plurality of ECUs (200) is set, exclusion means (130) for excluding an ECU among the plurality of ECUs in which set software operating in a scene which may occur at a same time as a scene in which additional software runs is set from candidate ECUs in which the additional software is to be set, and setting means (140) for setting additional software in any one of the candidate ECUs.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to THUAN H NGUYEN whose telephone number is (571)270-0332. The examiner can normally be reached 8am-5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Chat Do can be reached at 5712723721. 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.
/THUAN HUU NGUYEN/Examiner, Art Unit 2648
/Chat C Do/Supervisory Patent Examiner, Art Unit 2193
Prosecution Insights