DETAILED ACTION
This office action is in response to claims filed 12 September 2023.
Claims 1-12 are pending.
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 .
Claim Objections
Claims 1 and 4 are objected to because of the following informalities: “own apparatus” should read “in-vehicle apparatus”. Appropriate correction is required.
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-vehicle apparatus”, and “management unit”, in claims 1-10.
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, comprising at least a “comprehensive in-vehicle ECU such as a vehicle computer” (see [0049] of the specification) having processor, memory, and other hardware typically found in modern computers.
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 § 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-12 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claimed invention is directed to an abstract idea (mental process) without significantly more.
Regarding claim 1, in step 1 of the 101 analysis set forth in MPEP 2106, the claim recites a system that determines allocation information for vehicle based virtual devices based on vehicle state. A system is one of the four statutory categories of invention.
In step 2A, prong 1 of the 101 analysis set forth in the MPEP 2106, the examiner has determined that the following limitations recite a process that, under the broadest reasonable interpretation, covers a mental process but for recitation of generic computer components:
i. “generates a plurality of virtual devices” (a person can mentally generate virtual devices by simply making a judgement of a topology of virtual devices either completely within the mind or assisted with pen and paper (MPEP 2106.04(a)))
ii. “manages the plurality of virtual devices” (a person can mentally manage virtual devices by simply evaluating a topology of virtual devices and making judgements related to management functionality of the virtual devices (MPEP 2106.04(a)))
iii. “based on the specified vehicle state, determines a piece of allocation information for allocating the virtual devices to the own apparatus” (a person can mentally determine a piece of allocation information by simply evaluating a vehicle state, and making a judgement of a particular piece of allocation information (MPEP 2106.04(a)))
iv. “applies the determined allocation information to the virtual devices” (a person can mentally apply allocation information to virtual devices by simply making a judgement of a mere plan to allocate virtual devices according to allocation information (MPEP 2106.04(a)))
If claim limitations, under their broadest reasonable interpretation, covers performance of the limitations as a mental process but for the recitation of generic computer components, then it falls within the mental process grouping of abstract ideas. Accordingly, the claim “recites” an abstract idea.
In step 2A, prong 2 of the 101 analysis set forth in MPEP 2106, the examiner has determined that the following additional elements do not integrate this judicial exception into a practical application:
v. “An in-vehicle apparatus that is mounted in a vehicle” (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)).
vi. “virtual devices that are operating environments for a plurality of programs” (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)).
vii. “a management unit” (merely uses a computer as a tool to perform an abstract idea (MPEP 2106.05(f)).
viii. “wherein the management unit specifies a vehicle state that indicates a state of the vehicle” (insignificant extra-solution activity of mere data output (MPEP 2106.05(g)).
Since the claim does not contain any other additional elements that are indicative of integration into a practical application, the claim is “directed” to an abstract idea.
In step 2B of the 101 analysis set forth in the 2019 PEG, the examiner has determined through reanalysis of the following limitations considered in step 2A prong 2, that the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception.
v. “An in-vehicle apparatus that is mounted in a vehicle” (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)).
vi. “virtual devices that are operating environments for a plurality of programs” (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)).
vii. “a management unit” (merely uses a computer as a tool to perform an abstract idea (MPEP 2106.05(f)).
viii. “wherein the management unit specifies a vehicle state that indicates a state of the vehicle” (well-understood, routine, and conventional activity of data transmission over a network, (MPEP 2106.05(d)(II))).
Considering the additional elements individually and in combination, and the claim as a whole, the additional elements do not provide significantly more than the abstract idea. Therefore, the claim is not patent eligible.
Regarding claim 2, the additional element “the management unit acquires specification information for specifying the vehicle state from the virtual devices” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (insignificant extra-solution activity of mere data gathering MPEP 2106.05(g)), and under step 2B it does not amount to significantly more than the judicial exception (well-understood, routine, and conventional activity of receiving data over a network, (MPEP 2106.05(d)(II)). Further, the additional element “specifies the vehicle state based on the acquired specification information” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (insignificant extra-solution activity of mere data output MPEP 2106.05(g)), and under step 2B it does not amount to significantly more than the judicial exception (well-understood, routine, and conventional activity of transmitting data over a network, (MPEP 2106.05(d)(II)).
Regarding claim 3, the additional element “the virtual devices specify the vehicle state” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (insignificant extra-solution activity of mere data output MPEP 2106.05(g)), and under step 2B it does not amount to significantly more than the judicial exception (well-understood, routine, and conventional activity of transmitting data over a network, (MPEP 2106.05(d)(II)). Further, the additional element “the management unit acquires the vehicle state specified by the virtual devices from the virtual devices” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (insignificant extra-solution activity of mere data gathering MPEP 2106.05(g)), and under step 2B it does not amount to significantly more than the judicial exception (well-understood, routine, and conventional activity of receiving data over a network, (MPEP 2106.05(d)(II)).
Regarding claim 4, the additional element “the management unit specifies the vehicle state based on a state of hardware of the own apparatus” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (insignificant extra-solution activity of mere data output MPEP 2106.05(g)), and under step 2B it does not amount to significantly more than the judicial exception (well-understood, routine, and conventional activity of transmitting data over a network, (MPEP 2106.05(d)(II)).
Regarding claim 5, the additional element “the management unit specifies the vehicle state a plurality of times” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (insignificant extra-solution activity of mere data output MPEP 2106.05(g)), and under step 2B it does not amount to significantly more than the judicial exception (well-understood, routine, and conventional activity of transmitting data over a network, (MPEP 2106.05(d)(II)). Further additional element “if, among the plurality of specified vehicle states, an identical vehicle state has continued a predetermined number of times or more, the management unit determines the allocation information based on the identical vehicle state” does not render the claim patent eligible because under step 2A prong 1, it recites a judicial exception (mental process) (a person can mentally determine allocation information by simply evaluating the number of times a vehicle state has persisted, and making a judgement of allocation information (MPEP 2106.04(a))).
Regarding claim 6, the additional element “the management unit specifies the vehicle state a plurality of times” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (insignificant extra-solution activity of mere data output MPEP 2106.05(g)), and under step 2B it does not amount to significantly more than the judicial exception (well-understood, routine, and conventional activity of transmitting data over a network, (MPEP 2106.05(d)(II)). Further additional element “if, among the plurality of specified vehicle states, the number of times an identical vehicle state has been specified is greater than or equal to a predetermined value, the management unit determines the allocation information based on the identical vehicle state” does not render the claim patent eligible because under step 2A prong 1, it recites a judicial exception (mental process) (a person can mentally determine allocation information by simply evaluating the number of times a vehicle state has persisted, and making a judgement of allocation information (MPEP 2106.04(a))).
Regarding claim 7, additional element “the management unit applies the allocation information to change a type of the virtual devices to be allocated” does not render the claim patent eligible because under step 2A prong 1, it recites a judicial exception (mental process) (a person can mentally change a type of virtual device by simply evaluating allocation information and making a judgement of a new type of allocated virtual machine (MPEP 2106.04(a))).
Regarding claim 8, additional element “the management unit applies the allocation information to change the number of virtual devices to be allocated” does not render the claim patent eligible because under step 2A prong 1, it recites a judicial exception (mental process) (a person can mentally change a number of virtual devices by simply evaluating allocation information and making a judgement of a new number of allocated virtual machines (MPEP 2106.04(a))).
Regarding claim 9, additional element “the management unit applies the allocation information to change at least one of the times at which the virtual devices are to be allocated” does not render the claim patent eligible because under step 2A prong 1, it recites a judicial exception (mental process) (a person can mentally change a time of virtual device allocation by simply evaluating allocation information and making a judgement of a new time to allocate virtual machines (MPEP 2106.04(a))).
Regarding claim 10, additional element “the management unit applies the allocation information to change a cycle time in which the virtual devices are to be allocated” does not render the claim patent eligible because under step 2A prong 1, it recites a judicial exception (mental process) (a person can mentally change a cycle time of virtual device allocation by simply evaluating allocation information and making a judgement of a new cycle time to allocate virtual machines (MPEP 2106.04(a))).
Regarding claims 11-12, they comprise limitations similar to claim 1, and are therefore rejected for similar rationale.
Additionally, regarding claim 12, the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because it is directed to software per se. Specifically, it recites “A computer program for causing a computer that is mounted in a vehicle and generates a plurality of virtual devices that are operating environments of a plurality of programs, to execute a process”. In other words, the claim is directed to the computer program itself, which is understood to be software only, and the additional limitation “for causing a computer that is mounted in a vehicle and generates a plurality of virtual devices that are operating environments of a plurality of programs, to execute a process” is considered to be intended use, and is therefore not a “structural limitation” but rather is a “mere statement of purpose or use” (see MPEP 2111.02 (II)). Therefore claim 12 is rejected as being directed to software per se.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 4-8, and 11-12 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by HAYES et al. Pub. No.: US 2020/0326967 A1 (hereafter HAYES.
Regarding claim 1, HAYES teaches:
An in-vehicle apparatus that is mounted in a vehicle ([0017] Further shown in the top view 101 d is an automation computing system 116 (i.e., “in-vehicle apparatus”). The automation computing system 116 can include one or more computing devices configured to evaluate the environmental state of the autonomous vehicle 100, control one or more autonomous operations (e.g., autonomous driving operations) of the autonomous vehicle 100 (i.e., automation computing system 116 is “mounted” within vehicle 100)) and generates a plurality of virtual devices that are operating environments for a plurality of programs ([0028] Each of the virtual machines 229 (i.e., plural “virtual devices” executing within automation computing system 16 according to Fig. 2) may be configured to execute one or more of the automation module 220, the data collection module 224, the data processing module 226 (i.e., plural “programs”), or combinations thereof), the in- vehicle apparatus comprising;
a management unit that manages the plurality of virtual devices ([0027] Further stored in RAM 206 is a hypervisor 228 (i.e., “management unit”). The hypervisor 228 is configured to manage the configuration and execution of one or more virtual machines 229),
wherein the management unit specifies a vehicle state that indicates a state of the vehicle and, based on the specified vehicle state, determines a piece of allocation information for allocating the virtual devices to the own apparatus, and applies the determined allocation information to the virtual devices ([0044] Executing 602, by the hypervisor 610, the first virtual machine 612 comprising the first operating system 616 may be performed as part of a start-up or boot-up operation of the autonomous vehicle 100 (i.e., based on a specified vehicle state (start-up, or boot-up of the vehicle) specified at the hypervisor, a virtual machine is executed, which includes “allocating memory resources, processor resources, or device resources” as shown below in [0047]). [0045] The example method depicted in FIG. 6 also includes detecting 604 a change in the state of the autonomous vehicle 100. A change in the state of the autonomous vehicle 100 may include, for example, a change in the operational state of the autonomous vehicle. A change in the operational state of the autonomous vehicle 100 may include, for example, entering or exiting an autonomous driving mode, a potentially autonomous driving mode (e.g., a user-operated driving mode where the autonomous vehicle 100 is capable of entering an autonomous driving mode), a stationary mode (e.g., a parked mode), or some other mode. [0047] The method of FIG. 6 may further include revoking 606, by the hypervisor 610, in response to the change in the state of the autonomous vehicle 100, one or more resources associated with the execution of the first virtual machine 612. For example, the hypervisor 610 may suspend execution of the first virtual machine 612 such that any suspended processes or operation may be resumed from a point at which they were paused by the hypervisor 610. In other words, the hypervisor 610 may pause execution of the first virtual machine 612. The hypervisor 610 may also terminate execution of the first virtual machine 612. This may include terminating any processes or services executed via the first virtual machine 612 and/or freeing any disk space or memory allocated to the first virtual machine 612. This may also include revoking one or more memory resources, processor resources, or device resources allocated to the first virtual machine 612 (i.e., in response to a change in vehicle state (a change in a driving mode of the autonomous vehicle) specified at the hypervisor, a “piece of allocation information” indicating revocation of allocated resources is determined and applied). [0048] The method of FIG. 6 may further include executing 608, by the hypervisor 610, a second virtual machine 614 comprising a second operating system 618. Executing the second virtual machine 614 may include initializing the second virtual machine 614. For example, the hypervisor 610 may allocate memory and/or begin one or more processes associated with the second virtual machine 614 and/or the second operating system 618. Executing the second virtual machine 614 may also comprise resuming a suspended or paused instance of the second virtual machine 614 (i.e., in response to the change in vehicle state above, a second virtual machine is initialized, which involves determining a “piece of allocation information” that indicates allocation of at least memory resources)).
Regarding claim 4, HAYES teaches:
the management unit specifies the vehicle state based on a state of hardware of the own apparatus (0045] The example method depicted in FIG. 6 also includes detecting 604 a change in the state of the autonomous vehicle 100. A change in the state of the autonomous vehicle 100 may include, for example, a change in the operational state of the autonomous vehicle. A change in the operational state of the autonomous vehicle 100 may include, for example, entering or exiting an autonomous driving mode, a potentially autonomous driving mode (e.g., a user-operated driving mode where the autonomous vehicle 100 is capable of entering an autonomous driving mode), a stationary mode (e.g., a parked mode), or some other mode (i.e., each mode of the autonomous vehicle represents a state of the “hardware” including a driving mode, stationary mode, or some other mode)).
Regarding claim 5, HAYES teaches:
the management unit specifies the vehicle state a plurality of times, and if, among the plurality of specified vehicle states, an identical vehicle state has continued a predetermined number of times or more, the management unit determines the allocation information based on the identical vehicle state ([0044] Executing 602, by the hypervisor 610, the first virtual machine 612 comprising the first operating system 616 may be performed as part of a start-up or boot-up operation of the autonomous vehicle 100 (i.e., the hypervisor allocates resources to a virtual machine when it is determined that the state of the vehicle is “start-up” or “boot-up” for a predetermined number of times (at least one time)). [0045] The example method depicted in FIG. 6 also includes detecting 604 a change in the state of the autonomous vehicle 100. A change in the state of the autonomous vehicle 100 may include, for example, a change in the operational state of the autonomous vehicle. A change in the operational state of the autonomous vehicle 100 may include, for example, entering or exiting an autonomous driving mode, a potentially autonomous driving mode (e.g., a user-operated driving mode where the autonomous vehicle 100 is capable of entering an autonomous driving mode), a stationary mode (e.g., a parked mode), or some other mode (i.e., a change in the state indicates that the new vehicle state has continued for a predetermined number of times (at least one time))).
Regarding claim 6, HAYES teaches:
the management unit specifies the vehicle state a plurality of times, and if, among the plurality of specified vehicle states, the number of times an identical vehicle state has been specified is greater than or equal to a predetermined value, the management unit determines the allocation information based on the identical vehicle state ([0044] Executing 602, by the hypervisor 610, the first virtual machine 612 comprising the first operating system 616 may be performed as part of a start-up or boot-up operation of the autonomous vehicle 100 (i.e., the hypervisor allocates resources to a virtual machine when it is determined that the state of the vehicle is “start-up” or “boot-up” for a predetermined number of times (at least one time)). [0045] The example method depicted in FIG. 6 also includes detecting 604 a change in the state of the autonomous vehicle 100. A change in the state of the autonomous vehicle 100 may include, for example, a change in the operational state of the autonomous vehicle. A change in the operational state of the autonomous vehicle 100 may include, for example, entering or exiting an autonomous driving mode, a potentially autonomous driving mode (e.g., a user-operated driving mode where the autonomous vehicle 100 is capable of entering an autonomous driving mode), a stationary mode (e.g., a parked mode), or some other mode (i.e., a change in the state indicates that the new vehicle state has continued for a predetermined number of times (at least one time))).
Regarding claim 7, HAYES teaches:
the management unit applies the allocation information to change a type of the virtual devices to be allocated ([0047] The method of FIG. 6 may further include revoking 606, by the hypervisor 610, in response to the change in the state of the autonomous vehicle 100, one or more resources associated with the execution of the first virtual machine 612. For example, the hypervisor 610 may suspend execution of the first virtual machine 612 such that any suspended processes or operation may be resumed from a point at which they were paused by the hypervisor 610. In other words, the hypervisor 610 may pause execution of the first virtual machine 612. [0048] The method of FIG. 6 may further include executing 608, by the hypervisor 610, a second virtual machine 614 comprising a second operating system 618. Executing the second virtual machine 614 may include initializing the second virtual machine 614. For example, the hypervisor 610 may allocate memory and/or begin one or more processes associated with the second virtual machine 614 and/or the second operating system 618. Executing the second virtual machine 614 may also comprise resuming a suspended or paused instance of the second virtual machine 614 (i.e., second virtual machine “comprises a second operating system of a second modality”, as in [0003], and therefore represents at least a virtual machine having a changed operating system modality “type”)).
Regarding claim 8, HAYES teaches:
the management unit applies the allocation information to change the number of virtual devices to be allocated ([0044] Executing 602, by the hypervisor 610, the first virtual machine 612 comprising the first operating system 616 may be performed as part of a start-up or boot-up operation of the autonomous vehicle 100 (i.e., determining to allocate resources to a new virtual machine on start up changes the number of virtual machines (increases the number by 1)). [0047] The method of FIG. 6 may further include revoking 606, by the hypervisor 610, in response to the change in the state of the autonomous vehicle 100, one or more resources associated with the execution of the first virtual machine 612. For example, the hypervisor 610 may suspend execution of the first virtual machine 612 such that any suspended processes or operation may be resumed from a point at which they were paused by the hypervisor 610. In other words, the hypervisor 610 may pause execution of the first virtual machine 612 (i.e., revoking resources of a virtual machine and suspending operations of a virtual machine changes the number of executing virtual machines (reduces the number by 1))).
Regarding claims 11-12, they comprise limitations similar to those of claim 1, and are therefore rejected for similar rationale.
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.
Claims 2-3 are rejected under 35 U.S.C. 103 as being unpatentable over HAYES, as applied to claim 1 above, and in further view of LEE et al. Pub. No.: US 2020/0026546 A1 (hereafter LEE).
Regarding claim 2, while HAYES discusses management units that provide virtual devices to vehicles, HAYES does not explicitly teach:
the management unit acquires specification information for specifying the vehicle state from the virtual devices, and specifies the vehicle state based on the acquired specification information.
However, in analogous art that similarly teaches management units that provide virtual devices to vehicles, LEE teaches:
the management unit acquires specification information for specifying the vehicle state from the virtual devices, and specifies the vehicle state based on the acquired specification information ([0166] The vehicle VM (i.e., “virtual device”) may transmit, to the virtual vehicle interface, control information (i.e., “specification information for specifying the vehicle state”, as the control information specifies what state the vehicle should be in) obtained from computation that is performed based on the received information. The control information may be information including a result of image identification regarding autonomous driving, and the vehicle may control driving thereof based on the control information. In addition, the control information may include information on execution of a specific application. [0167] In step 935, the virtual vehicle interface may transmit at least a part of the information received from the vehicle VM to the vehicle manager (i.e., “management unit”, which “acquires” the control information from the virtual machine). [0169] In step 945, the vehicle may perform an operation based on the control information transmitted from the vehicle VM. The control information may include at least one of information on a control target, information on a control-related application, or information required to identify the sensor data which is the basis of the control information (i.e., vehicle is controlled, thereby changing the “state” of the vehicle based on the control information acquired from the virtual machine)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined LEE’s teaching of a management unit that receives vehicle state control specification information from a virtual machine device, with HAYES’s teaching of a management unit that controls resource allocation of virtual machine devices, to realize, with a reasonable expectation of success, a system comprising a management unit that controls resource allocation of virtual machine devices in a vehicle based on vehicle state information, as in HAYES, that is specified by the virtual machine devices, as in LEE. A person having ordinary skill would have been motivated to make this combination to test information related to vehicle control in a virtual vehicle prior to performing the control to ensure no problems will occur (LEE [0179]).
Regarding claim 3, while HAYES discusses management units that provide virtual devices to vehicles, HAYES does not explicitly teach:
the virtual devices specify the vehicle state, and the management unit acquires the vehicle state specified by the virtual devices from the virtual devices.
However, in analogous art that similarly teaches management units that provide virtual devices to vehicles, LEE teaches:
the virtual devices specify the vehicle state, and the management unit acquires the vehicle state specified by the virtual devices from the virtual devices ([0166] The vehicle VM (i.e., “virtual device”) may transmit, to the virtual vehicle interface, control information (i.e., information for specifying the vehicle “state”, as the control information specifies what state the vehicle should be in) obtained from computation that is performed based on the received information. The control information may be information including a result of image identification regarding autonomous driving, and the vehicle may control driving thereof based on the control information. In addition, the control information may include information on execution of a specific application. [0167] In step 935, the virtual vehicle interface may transmit at least a part of the information received from the vehicle VM to the vehicle manager (i.e., “management unit”, which “acquires” the control information from the virtual machine). [0169] In step 945, the vehicle may perform an operation based on the control information transmitted from the vehicle VM. The control information may include at least one of information on a control target, information on a control-related application, or information required to identify the sensor data which is the basis of the control information (i.e., vehicle is controlled, thereby changing the “state” of the vehicle based on the control information acquired from the virtual machine)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined LEE’s teaching of a management unit that receives vehicle state control specification information from a virtual machine device, with HAYES’s teaching of a management unit that controls resource allocation of virtual machine devices, to realize, with a reasonable expectation of success, a system comprising a management unit that controls resource allocation of virtual machine devices in a vehicle based on vehicle state information, as in HAYES, that is specified by the virtual machine devices, as in LEE. A person having ordinary skill would have been motivated to make this combination to test information related to vehicle control in a virtual vehicle prior to performing the control to ensure no problems will occur (LEE [0179]).
Claims 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over HAYES, as applied to claim 1 above, and in further view of TRACEY et al. Pub. No.: US 2018/0321973 A1 (hereafter TRACEY).
Regarding claim 9, while HAYES discusses allocation of resources to virtual machines, HAYES does not explicitly teach:
the management unit applies the allocation information to change at least one of the times at which the virtual devices are to be allocated.
However, in analogous art that similarly discusses allocation of resources to virtual machines, TRACEY teaches
the management unit applies the allocation information to change at least one of the times at which the virtual devices are to be allocated ([0018] The hypervisor has a schedule (11) consisting of an ordered collection of slots. A slot may either be statically assigned to a VM or may be dynamic, that is, as yet unassigned. Under normal operation, the hypervisor starts at the first slot in the schedule (11) and runs the specified VM until a clock-tick interrupt occurs. On occurrence of the clock-tick interrupt, the hypervisor suspends the VM being run, advances to the next slot in the schedule (11), and runs the specified VM (process 18). This running of VMs as described by the schedule (11) is repeated on every subsequent clock-tick interrupt. [0020] The hypervisor further provides for an API that can be used by the management software—but not by VMs—to request extra time for a VM. When this API is called and the free-space count is 0, the API call is ignored. When this API is called and the free-space count is not 0, then the specified VM is added to the end of the queue (12) and the free-space count is decremented by 1 (i.e., virtual machines are scheduled for allocation to resources, and requesting extra time enables the hypervisor to “change” the time that a particular virtual machine is to be allocated (the particular virtual machine is given extra time at the end of the queue))).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined TRACEY’s teaching of changing the times when virtual machines are to be scheduled, with HAYES’s teaching of allocating virtual machines to resources, to realize, with a reasonable expectation of success, a system that schedules virtual machines for allocation, as in HAYES, on a dynamically changeable and periodic basis, as in TRACEY. A person having ordinary skill would have been motivated to make this combination to improve flexibility of traditional round robin schedulers (TRACEY [0010]).
Regarding claim 10, while HAYES discusses allocation of resources to virtual machines, HAYES does not explicitly teach:
the management unit applies the allocation information to change a cycle time in which the virtual devices are to be allocated.
However, in analogous art that similarly discusses allocation of resources to virtual machines, TRACEY teaches
the management unit applies the allocation information to change a cycle time in which the virtual devices are to be allocated ([0018] The hypervisor has a schedule (11) consisting of an ordered collection of slots. A slot may either be statically assigned to a VM or may be dynamic, that is, as yet unassigned. Under normal operation, the hypervisor starts at the first slot in the schedule (11) and runs the specified VM until a clock-tick interrupt occurs. On occurrence of the clock-tick interrupt, the hypervisor suspends the VM being run, advances to the next slot in the schedule (11), and runs the specified VM (process 18). This running of VMs as described by the schedule (11) is repeated on every subsequent clock-tick interrupt. [0020] The hypervisor further provides for an API that can be used by the management software—but not by VMs—to request extra time for a VM. When this API is called and the free-space count is 0, the API call is ignored. When this API is called and the free-space count is not 0, then the specified VM is added to the end of the queue (12) and the free-space count is decremented by 1 (i.e., virtual machines are scheduled for allocation to resources, and requesting extra time enables the hypervisor to “change” the time that a particular virtual machine is to be allocated (the particular virtual machine is given extra time at the end of the queue))).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined TRACEY’s teaching of changing the times when virtual machines are to be scheduled, with HAYES’s teaching of allocating virtual machines to resources, to realize, with a reasonable expectation of success, a system that schedules virtual machines for allocation, as in HAYES, on a dynamically changeable and periodic basis, as in TRACEY. A person having ordinary skill would have been motivated to make this combination to improve flexibility of traditional round robin schedulers (TRACEY [0010]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL W AYERS whose telephone number is (571)272-6420. The examiner can normally be reached M-F 8:30-5 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, Aimee Li can be reached at (571) 272-4169. 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.
/MICHAEL W AYERS/Primary Examiner, Art Unit 2195