DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This Office Action is in response to the amendments filed on 11/20/2025. Claims 1 -9 are amended and Claims 11-20 are added. Claims 1-20 are presently pending and examined.
Response to Arguments
112(f) Rejection
Applicant’s amendments and accompanying arguments, see remarks, filed 11/20/2025, with respect to 112(f) rejections have been fully considered and are persuasive. The 112(f) rejection has been withdrawn.
101 Rejection
Applicant’s amendments and accompanying arguments, see remarks, filed 11/20/2025, with respect to 101 rejections have been fully considered and are persuasive. The 101 rejection of Claims 1-9 has been withdrawn.
Prior Art Rejection
Applicant’s amendments and accompanying arguments, see remarks, filed 11/20/2025, with respect to the rejection(s) of claim(s) 1-9 under 103 have been fully considered.
Application has argued that Yang does not teach the claimed selection logic and that Yang does not teach selection based on the vehicle's resources.
Yang discloses a [0029]connected vehicle 103 may include computing device(s) 152 having sensor(s) 113, processor(s) 115, memory(ies) 117, communication unit(s) 119, vehicle data store(s) 121, and a function deployment control 120, [0030] The ECUs may receive and store the sensor data associated with the connected vehicle 103 and/or the sensor data associated with other connected vehicles 103 in the vehicle data store 121 for access and/or retrieval by the function deployment control 120, [0031] The function deployment control 120 includes software and/or hardware logic executable to deploy vehicle functions for the connected vehicles 103. Yang also discloses that the functionality can be on the connected vehicle, [0031] the connected vehicle 103 a . . . 103 n may include instances 120 b . . . 120 m of the function deployment control 120. Yang discloses that [0031] each instance 120 a . . . 120 n and 120 b . . . 120 m may comprise one or more components the function deployment control 120 depicted in FIG. 2, and may be configured to fully or partially perform the functionalities described herein depending on where the instance resides. [0064] For each connected vehicle 103 that will be in the geographic region at the future point in time, the deployment engine 206 may receive the vehicle preference of the connected vehicle 103 from the server data store 125, and determine one or more first vehicle functions included in the vehicle preference of the connected vehicle 103. The connected vehicle 103 may likely request the execution of the first vehicle function(s) and/or request the function data of the first vehicle function(s) when the connected vehicle 103 is in the geographic region, and these first vehicle function(s) may be referred to as the vehicle function(s) associated with the connected vehicle 103. It is therefore clear that Yang discloses an embodiment where the vehicle side controller performs the logic.
Yang discloses a priority and priority threshold for deciding the subset of the vehicle functions [0077] the deployment engine 206 may determine a priority level for the first vehicle functions associated with the connected vehicles 103 based on the connected vehicle status of the geographic region, [0080] the deployment engine 206 may determine the priority level corresponding to the first vehicle function and the connected vehicle 103 based on the vehicle priority metric of the first connected vehicle 103 and/or the urgency metric of the first vehicle function, and [0080] the deployment engine 206 may assign an adjustable weight value for each factor being used to determine the priority level corresponding to the first vehicle function and the connected vehicle 103. Other factors for determining the priority level corresponding to the first vehicle function and the connected vehicle 103 are also possible and contemplated.
Yang also discloses the adjustment of resources based on the traffic environment.
Applicant argues that Grix fails to cure the deficiencies of Yang. Examiner respectfully disagrees with the applicant.
Grix teaches [0006] transferring execution of the locally and remotely executing applications in accordance with the determinations relating to connectivity. Grix teaches an embodiment [0047] that allow for utilization of both local and remote processing, and using bandwidth constraints and connection availability and connectivity options to dynamically redistribute processing in a manner that can better use available resource when those resources are actually available. Grix teaches selecting one or the plurality of the sub-functions in accordance with the connectivity and bandwidth. subset of the server function (Service A, Service B, Service C) to run on either the vehicle or the remote server (see Fig. 2A – 2E). Accordingly, Grix teaches the use of local processing resources in the connected vehicle and selection of a subset of services to execute locally on the connected vehicle.
Therefore applicants’ arguments and are not persuasive. The rejections are maintained.
Based on the amendments, there are other new ground(s) of rejection.
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.
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.
Claims 1, 7 - 15, 18 - 20 are rejected under 35 U.S.C. 103 as being unpatentable over Hao Yang et. al. US20210295705 (“Yang”) in view of Jason Grix et. al. US 20190221050 (“Grix”)
As per Claim 1 and 9,
Yang discloses,
An in-vehicle device mounted to a vehicle including a driving support device including processing circuitry configured to electronically control parts of the vehicle based on information from an external server (see at least [0029] The connected vehicle 103 may include computing device(s) 152 having sensor(s) 113, processor(s) 115, memory(ies) 117, communication unit(s) 119, vehicle data store(s) 121, and a function deployment control 120.)
processing circuitry disposed within the in-vehicle device mounted to the vehicle and configured to:
operate as an in-vehicle server configured to:
( see at least [0031] The function deployment control 120 includes software and/or hardware logic executable to deploy vehicle functions for the connected vehicles 103. As illustrated in FIG. 1, [0031] the connected vehicle 103 a . . . 103 n may include instances 120 b . . . 120 m of the function deployment control 120.)
to use data received from outside, and
(see at least [0030] The ECUs may receive and store the sensor data associated with the connected vehicle 103 and/or the sensor data associated with other connected vehicles 103 in the vehicle data store 121 for access and/or retrieval by the function deployment control 120)
output subset information for replacing a part of the information from the external server (see at least [0030] The ECUs may receive and store the sensor data associated with the connected vehicle 103 and/or the sensor data associated with other connected vehicles 103 in the vehicle data store 121 for access and/or retrieval by the function deployment control 120, [ 0031] may be configured to fully or partially perform the functionalities described herein depending on where the instance resides, and [0031] The function deployment control 120 may receive and process vehicle dynamics, trip data, traffic pattern, etc., and communicate with other elements of the connected vehicle 103 via the communication bus 154, such as the memory 117, the communication unit 119, the vehicle data store 121, etc. The function deployment control 120 is described in details below with reference to at least FIGS. 2-8).
acquire current dynamic information of information processing resources possessed by the vehicle;
(see at least [0065] In some embodiments, the deployment engine 206 may evaluate the available computing resources of a computing system, such as a server, for a particular current or future timeframe, and [0066] the deployment engine 206 may estimate the amount of computing resource required to deploy the first vehicle functions for the connected vehicles 103)
a function selection unit configured to select, in response to a fact that reception of the information from the external server has been suspended, at least one of the sub-functions executed by the in-vehicle server, in accordance with a priority based on a traffic environment where the vehicle is in; (see at least [0021] The present technology provides a traffic-adaptive function deployment system for the servers to proactively process traffic information, and [0030] The function deployment control 120 includes software and/or hardware logic executable to deploy vehicle functions for the connected vehicles 103, [ 0031] may be configured to fully or partially perform the functionalities described herein depending on where the instance resides, and [0031] the function deployment control 120 may receive and process vehicle dynamics, trip data, traffic pattern, etc.,)
Yang does not disclose,
execute one or a plurality of sub-functions forming a subset of a function of the external server,
determine that reception of the information from the external server has been suspended;
select, in response to a fact that the reception of the information from the external server has been suspended, at least one of the one of the plurality of the sub-functions executed by the in-vehicle server within a range allowed by the information processing resources possessed by the vehicle in accordance with a priority determined based on a traffic environment of the vehicle and the current dynamic information of the information processing resources possessed by the vehicle: and
provide, in accordance with the fact that the reception of the information from the external server has been suspended, the subset information from the in- vehicle server to the driving, support device,
wherein the driving support device electronically controls parts of the vehicle based on the subset information from the in-vehicle server.
Grix teaches,
execute one or a plurality of sub-functions forming a subset of a function of the external server (see at least [0035] How many services will be passed to the remote server may be a function of available bandwidth and/or a type of connection).
determine that reception of the information from the external server has been suspended (see at least [0036] If the connection is not sufficient to handle the data transfer needs of all services, the local service manager may keep one or more services executing locally, [0040] the process can monitor the connection and if the connection begins to fail, for example, the process can spin up locally and receive any relevant data before the connection fails completely and Fig. 2E)
select, in response to a fact that the reception of the information from the external server has been suspended, at least one of the one of the plurality of the sub-functions executed by the in-vehicle server within a range allowed by the information processing resources possessed by the vehicle in accordance with a priority determined based on a traffic environment of the vehicle and the current dynamic information of the information processing resources possessed by the vehicle: and (see at least [0030] FIGS. 2A-2E show illustrative distribution of computing services. Whenever there is no connectivity, the process executes all possible services locally. Once connectivity is established, the system offloads as many services to the cloud as possible. Over the course of a journey, the system will pass handling back and forth between the vehicle and cloud, depending on communication variation and how that will impact effectiveness of cloud computing as opposed to executing the functions onboard (typically requiring little to no remote communication).
provide, in accordance with the fact that the reception of the information from the external server has been suspended, the subset information from the in- vehicle server to the driving, support device (see at least [0039] If there is no connectivity whatsoever, the process will spin up 305 a local instance of the service, using an onboard processor. While the service is executing, the process will also monitor 307 connection availability, and if the connection becomes available, the process can pass handling to a remote version of the service, by requesting remote spin up and passing any needed data, and Fig. 2E.)
wherein the driving support device electronically controls parts of the vehicle based on the subset information from the in-vehicle server (see at least [0004] the processor is configured to launch a local version of the application, responsive to determining that current vehicle connectivity is insufficient to support remote execution, and [0013] a processor 3 controls at least some portion of the operation of the vehicle-based computing system).
Thus, Yang discloses an in-vehicle device capable of executing one or a plurality of functions and Grix teaches redistribution of functions based on vehicle connectivity to a remote server.
As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the inventions as disclosed by Yang with the sensor accuracy and capabilities taught by Grix, with a reasonable expectation of success, for dynamically choosing local or remote processing, based on how communication constraints may affect the net handling time or other utility parameters (0029).
As per Claim 7,
Yang discloses,
the in-vehicle server decides, for each function selected by the function selection unit, a cooperation node from which data necessary for realizing the function is to be collected (see at least [0031] the connected vehicle 103 a . . . 103 n may include instances 120 b . . . 120 m of the function deployment control 120. In some embodiments, each instance 120 a . . . 120 n and 120 b . . . 120 m may comprise one or more components the function deployment control 120 depicted in FIG. 2, and may be configured to fully or partially perform the functionalities described herein depending on where the instance resides, [0037] The vehicle preference may indicate one or more vehicle functions that are likely requested or executed by the connected vehicle 103 to improve driving experience and/or vehicle operations of the connected vehicle 103. Non-limiting examples of the vehicle function include a function to minimize travel time, a function to increase traffic safety, a function to maximize fuel efficiency, etc. In some embodiments, the vehicle data store 121 may store a vehicle priority metric indicating a level of priority associated with the connected vehicle 103)
As per Claim 8,
Yang discloses,
the in-vehicle server decides a cooperation node from which data necessary for realizing functions selected by the function selection unit is to be collected, such that the cooperation node is common among all the selected functions (see at least [0030] ECUs may receive and store the sensor data associated with the connected vehicle 103 and/or the sensor data associated with other connected vehicles 103 in the vehicle data store 121 for access and/or retrieval by the function deployment control 120, [0035] The vehicle data store 121 includes a non-transitory storage medium that stores various types of data, and [0037] the vehicle data store 121 may also store vehicle preference of the connected vehicle 103. The vehicle preference may indicate one or more vehicle functions that are likely requested or executed by the connected vehicle 103 to improve driving experience and/or vehicle operations of the connected vehicle 103. Non-limiting examples of the vehicle function include a function to minimize travel time, a function to increase traffic safety, a function to maximize fuel efficiency, etc.)
As per Claim 10,
Yang discloses,
A vehicle having mounted thereto the in-vehicle device according to claim 1 (see at least [0029] The connected vehicle 103 may include computing device(s) 152 having sensor(s) 113, processor(s) 115, memory(ies) 117, communication unit(s) 119, vehicle data store(s) 121, and a function deployment control 120).
As per Claim 11,
Yang discloses,
The in-vehicle device according to claim 7, wherein the cooperation node is selected from infrastructure sensors and other vehicles (see at least [0023] An example system for deploying vehicle functions for connected vehicles may receive vehicle data for a plurality of vehicles associated with a geographic region, [0030] The ECUs may receive and store the sensor data associated with the connected vehicle 103 and/or the sensor data associated with other connected vehicles 103 in the vehicle data store 121 for access and/or retrieval by the function deployment control 120 , and [0064] the deployment engine 206 may determine one or more connected vehicles 103 that will be in the geographic region of the server 101 at the future point in time based on the connected vehicle status of the geographic region. For each connected vehicle 103 that will be in the geographic region at the future point in time, the deployment engine 206 may receive the vehicle preference of the connected vehicle 103 from the server data store 125, and determine one or more first vehicle functions included in the vehicle preference of the connected vehicle 103. The connected vehicle 103 may likely request the execution of the first vehicle function(s) and/or request the function data of the first vehicle function(s) when the connected vehicle 103 is in the geographic region, and these first vehicle function(s) may be referred to as the vehicle function(s) associated with the connected vehicle 103.)
As per Claim 12,
Yang discloses,
The in-vehicle device according to claim 7, wherein the processing circuitry is configured to update the cooperation node based on a current position of the vehicle after the at least one of the one or the plurality of sub-functions is selected (see at least [0063] the deployment engine 206 may determine one or more vehicle functions to be deployed by the server 101 associated with the geographic region based on the connected vehicle status of the geographic region. For example, the deployment engine 206 may determine the vehicle functions to be deployed by the server 101 based on the estimated number of connected vehicles 103 in the geographic region at the future point in time. In block 308, the deployment engine 206 may deploy the vehicle functions using available resources of the server 101).
As per Claim 13,
Yang discloses,
The in-vehicle device according to claim 8, wherein the cooperation node is selected from infrastructure sensors and other vehicles (see at least [0064] the deployment engine 206 may determine one or more connected vehicles 103 that will be in the geographic region of the server 101 at the future point in time based on the connected vehicle status of the geographic region. For each connected vehicle 103 that will be in the geographic region at the future point in time, the deployment engine 206 may receive the vehicle preference of the connected vehicle 103 from the server data store 125, and determine one or more first vehicle functions included in the vehicle preference of the connected vehicle 103. The connected vehicle 103 may likely request the execution of the first vehicle function(s) and/or request the function data of the first vehicle function(s) when the connected vehicle 103 is in the geographic region, and these first vehicle function(s) may be referred to as the vehicle function(s) associated with the connected vehicle 103).
As per Claim 14,
Yang does not disclose,
The in-vehicle device according to claim1, wherein the processing circuitry is configured to switch an operation mode of the in-vehicle device from a normal mode to a suspension mode in response to the fact that the reception of the information from the external server has been suspended
Grix teaches,
The in-vehicle device according to claim1, wherein the processing circuitry is configured to switch an operation mode of the in-vehicle device from a normal mode to a suspension mode in response to the fact that the reception of the information from the external server has been suspended (see at least [0038] FIG. 3 shows an illustrative process for service request handling. In this illustrative example, a process executing at the vehicle receives 301 a service request. The user could launch an application, or the service could be a vehicle support service supporting some form of onboard functionality. Other requests could include designated automatic application launching or other services that may run upon startup, on demand, or activated automatically).
Thus, Yang discloses an in-vehicle device capable of executing one or a plurality of functions and Grix teaches redistribution of functions based on vehicle connectivity to a remote server.
As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the inventions as disclosed by Yang with the sensor accuracy and capabilities taught by Grix, with a reasonable expectation of success, for dynamically choosing local or remote processing, based on how communication constraints may affect the net handling time or other utility parameters (0029).
As per Claim 15,
Yang does not disclose,
The in-vehicle device according to claim 14,wherein in the normal mode, the processing circuitry is configured to provide the information from the external server to the driving support device, and
in the suspension mode, the processing circuitry is configured to provide the subset information from the in-vehicle server to the driving support device.
Grix teaches,
in-vehicle device according to claim 14,wherein in the normal mode, the processing circuitry is configured to provide the information from the external server to the driving support device; and (see at least [0039] While the service is executing, the process will also monitor 307 connection availability, and if the connection becomes available, the process can pass handling to a remote version of the service, by requesting remote spin up and passing any needed data)
and in the suspension mode, the processing circuitry is configured to provide the subset information from the in-vehicle server to the driving support device (see at least [0039] If there is no connectivity whatsoever, the process will spin up 305 a local instance of the service, using an onboard processor).
Thus, Yang discloses an in-vehicle device capable of executing one or a plurality of functions and Grix teaches redistribution of functions based on vehicle connectivity to a remote server.
As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the inventions as disclosed by Yang with the sensor accuracy and capabilities taught by Grix, with a reasonable expectation of success, for dynamically choosing local or remote processing, based on how communication constraints may affect the net handling time or other utility parameters (0029).
As per Claim 18,
Yang does not disclose,
The in-vehicle device according to claim 1, wherein the one or the plurality of sub-functions include at least one of an in-vehicle mini edge server function or an in-vehicle mini cloud server function.
Grix teaches,
The in-vehicle device according to claim 1, wherein the one or the plurality of sub-functions include at least one of an in-vehicle mini edge server function or an in-vehicle mini cloud server function (see at least [0035] A service that requires very limited data transfer may also require limited processing, but still may be passed to the remote server in favor of a processing-intensive service (which would be more effectively run remotely) that also requires significant data-passing, if the connection is poor, the bandwidth is low, etc. If the bandwidth increases and/or the connection becomes more reliable, the process may swap the two services, since the system will benefit from having the latter service run on the cloud if the communication connection can handle the necessary data transfer. This sort of balancing can be used to dynamically pass service handling between the cloud and vehicle as connections permit).
Thus, Yang discloses an in-vehicle device capable of executing one or a plurality of functions and Grix teaches redistribution of functions based on vehicle connectivity to a remote server.
As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the inventions as disclosed by Yang with the sensor accuracy and capabilities taught by Grix, with a reasonable expectation of success, for dynamically choosing local or remote processing, based on how communication constraints may affect the net handling time or other utility parameters (0029).
As per Claim 19,
Yang does not disclose,
The in-vehicle device according to claim 1. wherein the processing circuitry is configured to:
detect a variation in the information processing resources possessed by the vehicle after the at least one of the one or the plurality of sub-functions has been selected; and
reconstruct the in-vehicle server by re-selecting the at least one of the one or the plurality of sub-functions in response to the variation.
Grix teaches,
The in-vehicle device according to claim 1. wherein the processing circuitry is configured to:
detect a variation in the information processing resources possessed by the vehicle after the at least one of the one or the plurality of sub-functions has been selected; and (see at least [0047] illustrative embodiments allow for utilization of both local and remote processing, and using bandwidth constraints and connection availability and connectivity options to dynamically redistribute processing in a manner that can better use available resource when those resources are actually available, [0066] For example, the deployment engine 206 may estimate the amount of computing resource required to deploy the first vehicle functions for the connected vehicles 103, and compare the amount of resource required to deploy the first vehicle functions for the connected vehicles 103 to the amount of available resources of the server 101 (e.g., the capacity of free memory space, the percentage of available processing capacity, the unoccupied network bandwidth, etc.), and [0077] Referring back to FIG. 6, if in block 604, the deployment engine 206 determines that the available resources of the server 101 are not sufficient to deploy all first vehicle functions)
reconstruct the in-vehicle server by re-selecting the at least one of the one or the plurality of sub-functions in response to the variation (see at least [0036] FIG. 2C shows the spin-up of services on the remote server 210, after the handling instructions have been passed from the local services manager to the remote services manager. Any data needed to continue service provision can also be provided, so that remote services A 221, B 223 and C 225 can continue with limited to no interruption or reset. Once the remote services have successfully spun up, as in FIG. 2D, the local service manager can spin down the local versions of those services. Passing all service handling, such as in this example, may be done when a high bandwidth, reliable connection exists. If the connection is not sufficient to handle the data transfer needs of all services, the local service manager may keep one or more services executing locally).
Thus, Yang discloses an in-vehicle device capable of executing one or a plurality of functions and Grix teaches redistribution of functions based on vehicle connectivity to a remote server.
As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the inventions as disclosed by Yang with the sensor accuracy and capabilities taught by Grix, with a reasonable expectation of success, for dynamically choosing local or remote processing, based on how communication constraints may affect the net handling time or other utility parameters (0029).
As per Claim 20,
Yang does not disclose,
The in-vehicle device according to claim 19, wherein the variation in the information processing resources includes one of a communication delay time in the vehicle exceeding a threshold or a processing load exceeding a threshold.
Grix teaches,
The in-vehicle device according to claim 19, wherein the variation in the information processing resources includes one of a communication delay time in the vehicle exceeding a threshold or a processing load exceeding a threshold (see at least [0035] How many services will be passed to the remote server may be a function of available bandwidth and/or a type of connection).
Thus, Yang discloses an in-vehicle device capable of executing one or a plurality of functions and Grix teaches redistribution of functions based on vehicle connectivity to a remote server.
As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the inventions as disclosed by Yang with the sensor accuracy and capabilities taught by Grix, with a reasonable expectation of success, for dynamically choosing local or remote processing, based on how communication constraints may affect the net handling time or other utility parameters (0029).
Claims 2 – 6 and 16 - 17 are rejected under 35 U.S.C. 103 as being unpatentable over Yang and Grix as applied to Claim 1 above, and further in view of Tasuku Ishigooka US 11934865 (“Ishigooka”).
As per Claim 2,
Yang discloses,
identify the traffic environment of the vehicle (see at least [0042] In some embodiments, for each road segment associated with the geographic region, the server data store 125 may also store a roadway infrastructure describing various roadway components in the road segment that may impact the flow of traffic (e.g., lanes, traffic lights, freeway ramps, etc.), [0049] the traffic condition estimator 202 may estimate a future traffic condition for each road segment associated with the geographic region at a future point in time indicated by a future timestamp, and [0089] As an example, FIG. 7B illustrates a larger view of the roadway area 700 in FIG. 7A. As depicted in FIG. 7B, the roadway area 700 may include multiple geographic regions 744, 746, 748, 750, 752, 754, 756 associated with multiple servers 101).
select, in accordance with a priority defined by the selected one, out of the one or the plurality of priority tables, the at least one of the one or the plurality of sub-functions (see at least FIG. 6, [0028] the unconnected vehicle 123 may be a vehicle platform that lacks the capability of communicating with other computing entities, or has such capability but is restricted from or incapable of using it due to various reasons (e.g., system errors, power loss, opt-out settings, etc.). Therefore, the unconnected vehicle 123 may be may be non-responsive and unable to transmit and receive data to and from other computing entities of the system 100, [0063] in block 306, the deployment engine 206 may may determine one or more vehicle functions to be deployed by the server 101 associated with the geographic region based on the connected vehicle status of the geographic region. For example, the deployment engine 206 may determine the vehicle functions to be deployed by the server 101 based on the estimated number of connected vehicles 103 in the geographic region at the future point in time. In block 308, the deployment engine 206 may deploy the vehicle functions using available resources of the server 101, and [0064] the deployment engine 206 may receive the vehicle preference of the connected vehicle 103 from the server data store 125, and determine one or more first vehicle functions included in the vehicle preference of the connected vehicle 103. The connected vehicle 103 may likely request the execution of the first vehicle function(s) and/or request the function data of the first vehicle function(s) when the connected vehicle 103 is in the geographic region, and these first vehicle function(s) may be referred to as the vehicle function(s) associated with the connected vehicle 103. Non-limiting examples of the vehicle function include the function to minimize travel time, the function to increase traffic safety, the function to maximize fuel efficiency, etc.)
Yang does not explicitly disclose,
store a priority table defining a priority level of the function for each of one or a plurality of types of the traffic environment;
select one, out of the one or the plurality of priority tables, that corresponds to the traffic environment of the vehicle;
Ishigooka teaches,
store a priority table defining a priority level of the function for each of one or a plurality of types of the traffic environment (see at least [Col. 4, line 30-36] It is to be noted that in the following description, each piece of information of the present disclosure will be explained in the form of “table”, but these pieces of information may not necessarily be expressed in a data structure of a table, and may be expressed in a data structure such as a list, DB, and queue or in another form, [Col. 6, line 56-60] It is to be noted that the task configuration 1111 (table) is set and managed in a memory (not illustrated) of the ECU-A 11, for example. The task configuration may be set on the memory as data from the beginning, or may be set by transmission of data from the ECU-B 12, for example, and [ Col. 6, line 61-65 ] The task configuration 1111 includes a task name 11111, a task ID 11112, an execution cycle 11113, task priority 11114, a normal execution time 11115, an initialization execution time 11116, a function group 11117, and scheduling 11118, as configuration items).
select one, out of the one or the plurality of priority tables, that corresponds to the traffic environment of the vehicle ( see at least [Col. 6, line 43-46] . The travel plan unit 1101 receives the travel environment information as input, and outputs track candidate information. The judgement function unit 1102 receives the track candidate information as input, and outputs travel track information, and [Col. 6, line 61-65] The task configuration 1111 includes a task name 11111, a task ID 11112, an execution cycle 11113, task priority 11114, a normal execution time 11115, an initialization execution time 11116, a function group 11117, and scheduling 11118, as configuration items).
Thus, Yang discloses prioritization of functions to be executed based on resource availability and the traffic environment functions and Ishigooka teaches storing the priority level in memory and executing the functions based on priority and resources available.
As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the inventions as disclosed by Yang with the priority scheduling as taught by Ishigooka, with a reasonable expectation of success, to executes a plurality of functions in units of predetermined function group (Col. 2, line 31-32).
As per Claim 3,
Yang discloses,
The in-vehicle device according to claim 2, wherein the processing circuitry is configured a to identify the traffic environment of the vehicle based on a dynamic map and a position of the vehicle (see at least [0041] the server data store 125 may store a server identifier (ID) uniquely identify the server 101, region data describing the geographic region associated with the server 101 (e.g., region location (e.g., GPS coordinates), shape and size, etc.), etc. In some embodiments, the server data store 125 may also store the vehicle dynamics of various vehicles associated with the geographic region at multiple timestamps. The vehicles associated with the geographic region may include one or more connected vehicles 103 and/or one or more unconnected vehicles 123 that are located within the geographic region or within a predefined distance from the geographic region , and [0048] the traffic condition estimator 202 may analyze the vehicle data received from the connected vehicle 103, and determine the vehicle dynamics of the connected vehicle 103 and its proximate vehicles at the corresponding timestamp, and [0048] for each vehicle at each timestamp, the vehicle dynamics of the vehicle may include the vehicle location, the vehicle speed, the acceleration/deceleration rate, the lane number, etc., of the vehicle at the timestamp. Thus, the traffic condition estimator 202 may obtain the vehicle dynamics of not only the connected vehicles 103 but also the unconnected vehicles 123 associated with the with the geographic region).
As per Claim 4,
Yang discloses,
the current dynamic information is dynamic information of at least a plurality of information processing resources out of the information processing resources possessed by the vehicle, [0064] the deployment engine 206 may receive the vehicle preference of the connected vehicle 103 from the server data store 125, and determine one or more first vehicle functions included in the vehicle preference of the connected vehicle 103. The connected vehicle 103 may likely request the execution of the first vehicle function(s) and/or request the function data of the first vehicle function(s) when the connected vehicle 103 is in the geographic region, and these first vehicle function(s) may be referred to as the vehicle function(s) associated with the connected vehicle 103. Non-limiting examples of the vehicle function include the function to minimize travel time, the function to increase traffic safety, the function to maximize fuel efficiency, etc.
Yang does not disclose,
the in-vehicle server distributes the at least one of the one or the plurality of sub- functions to the plurality of information processing resources in the information processing resources possessed by the vehicle, thereby processing the at least one of the one or the plurality of sub-function.
Grix teaches,
the in-vehicle server distributes the at least one of the one or the plurality of sub- functions to the plurality of information processing resources in the information processing resources possessed by the vehicle, thereby processing the at least one of the one or the plurality of sub-function (see at least [0008] FIGS. 2A-2E show illustrative distribution of computing services)
Thus, Yang discloses an in-vehicle device capable of executing one or a plurality of functions and Grix teaches distribution of functions to a plurality of processing resources.
As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the inventions as disclosed by Yang with the sensor accuracy and capabilities taught by Grix, with a reasonable expectation of success, for dynamically choosing local or remote processing, based on how communication constraints may affect the net handling time or other utility parameters (0029).
As per Claim 5
Yang does not disclose,
in accordance with the priority defined by the selected one, out of the one or the plurality of priority tables one of the plurality of sub-functions within the range allowed by the information processing resources possessed by the vehicle based on the current dynamic information; and
select another of the plurality of sub-functions necessary for execution of the one of the plurality of sub-functions.
Ishigooka teaches,
in accordance with the priority defined by the selected one, out of the one or the plurality of priority tables one of the plurality of sub-functions within the range allowed by the information processing resources possessed by the vehicle based on the current dynamic information (see at least [Col. 6, line 54-56] FIG. 5 is a view illustrating an example of a task configuration 1111 before update (condition A 01) of the first embodiment, and [Col. 6, line 61-65] The task configuration 1111 includes a task name 11111, a task ID 11112, an execution cycle 11113, task priority 11114, a normal execution time 11115, an initialization execution time 11116, a function group 11117, and scheduling 11118, as configuration items.)
select another of the plurality of sub-functions necessary for execution of the one of the plurality of sub-functions (see at least [ Col. 6 line 66 – Col. 7, line 5 ]The task name 11111 is information indicating a function to be executed as a name of the task. For example, a travel plan task executes the travel plan unit 1101, a judgement function task executes the judgement function unit 1102, a first surrounding recognition task executes the first surrounding recognition unit 1104, and a mode change task executes the mode change unit 1108, and [Col. 7, line 39-54] The scheduling 11118 is information indicating a scheduling policy under which the task is executed. In the first embodiment, a plurality of scheduling policies are assumed to coexist, but the present disclosure is not limited to this).
Thus, Yang discloses prioritization of functions to be executed based on resource availability and the traffic environment functions and Ishigooka teaches plurality of task setting and scheduling policies.
As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the inventions as disclosed by Yang with the task setting and scheduling as taught by Ishigooka, with a reasonable expectation of success, to executes a plurality of functions in units of predetermined function group (Col. 2, line 31-32).
As per Claim 6
Yang does not disclose,
the processing circuitry is configured to: store one or more functions having been executed by the driving support device in accordance with the fact that the reception has been suspended
Select, in accordance with the priority defined by the selected one, out of the one or the plurality of priority tables, the at least one of the one or the plurality of sub-functions within the range allowed by the information processing resources possessed by the vehicle and from the one or more functions having been executed by the driving support, based on the current dynamic information
Ishigooka teaches,
the processing circuitry is configured to: store one or more functions having been executed by the driving support device in accordance with the fact that the reception has been suspended (see at least [Col. 6, line 56-60] It is to be noted that the task configuration 1111 (table) is set and managed in a memory (not illustrated) of the ECU-A 11, for example. The task configuration may be set on the memory as data from the beginning, or may be set by transmission of data from the ECU-B 12, for example).
Select, in accordance with the priority defined by the selected one, out of the one or the plurality of priority tables, the at least one of the one or the plurality of sub-functions within the range allowed by the information processing resources possessed by the vehicle and from the one or more functions having been executed by the driving support, based on the current dynamic information (see at least [Col. 7, line 13-18] The task priority 11114 is information indicating the priority of the task. This priority indicates the degree to which the task is preferentially executed when tasks are in a state of being simultaneously executable, and the smaller the numeral is, the higher the priority is, [Col. 7, line 33-37] The function group 11117 is information indicating the function group to which the task belongs. For example, the common function group is an application program that is executed regardless of the condition. The function group for the condition A is a function group executed in the condition A, [Col. 7, line 39-42] The scheduling 11118 is information indicating a scheduling policy under which the task is executed. In the first embodiment, a plurality of scheduling policies are assumed to coexist, but the present disclosure is not limited to this, and [Col. 8, line 9-11] the task configuration 1112 and the execution management setting 1113 (table) are set and managed in the memory (not illustrated) of the ECU-A 11).
Thus, Yang discloses prioritization of functions to be executed based on resource availability and the traffic environment functions and Ishigooka teaches storing the task priority as a table in memory.
As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the inventions as disclosed by Yang with the task setting and scheduling as taught by Ishigooka, with a reasonable expectation of success, to executes a plurality of functions in units of predetermined function group (Col. 2, line 31-32).
As per Claim 16
Yang discloses,
wherein the traffic environment of the vehicle is identified based on a road shape (see at least [0042] In some embodiments, for each road segment associated with the geographic region, the server data store 125 may also store a roadway infrastructure describing various roadway components in the road segment that may impact the flow of traffic (e.g., lanes, traffic lights, freeway ramps, etc.), [0049] the traffic condition estimator 202 may estimate a future traffic condition for each road segment associated with the geographic region at a future point in time indicated by a future timestamp, and [0089] As an example, FIG. 7B illustrates a larger view of the roadway area 700 in FIG. 7A. As depicted in FIG. 7B, the roadway area 700 may include multiple geographic regions 744, 746, 748, 750, 752, 754, 756 associated with multiple servers 101).
As per Claim 17
Yang discloses,
wherein the road shape includes at least one of an intersection, a branch merging point, a straight road, or a curve (see at least [0042] the server data store 125 may also store a roadway infrastructure describing various roadway components in the road segment that may impact the flow of traffic (e.g., lanes, traffic lights, freeway ramps, etc.). For example, the roadway infrastructure may indicate a number of lanes in the road segment, a traffic signal location, a traffic signal duration, etc., of traffic lights at one or more intersections in the road segment, a ramp location, a ramp length, a merging angle, etc., of one or more freeway ramps in the road segment, etc.)
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ASHUTOSH PANDE whose telephone number is (571)272-6269. The examiner can normally be reached Monday -Friday 9:00am -5:00 PM EST.
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, Fadey Jabr can be reached at 5712721516. 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.
/A.P./Examiner, Art Unit 3668
/Fadey S. Jabr/Supervisory Patent Examiner, Art Unit 3668
Prosecution Insights