DETAILED ACTION
This Final Office Action is in response to the argument and amendment filed October 01, 2025.
Claims 1, 3, 8, 10, and 16 are amended.
Claims 2, 4, 5, 6, 7, 9, 11, 12, 13, 14 and 15 are originals.
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 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.
Claim(s) 1 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Ricci et al [2016/0325755] hereafter Ricci, in view of Wagner et al [10564946] hereafter Wagner, in further view of Dimitrov et al [2013/0275969] hereafter Dimitrov.
As per claim 1;
Ricci discloses:
A method of providing an infotainment virtualization service, which is performed by a personalized infotainment virtualization system in a car sharing environment, the method comprising:
{[0118] The vehicle control system 204 may communicate through the communication network 224 to a server 228 that may be located in a facility that is not within physical proximity to the vehicle 104. Thus, the server 228 may represent a cloud computing system or cloud storage that allows the vehicle control system 204 to either gain access to further computing capabilities or to storage at a location outside of the vehicle 104. The server 228 can include a computer processor and memory and be similar to any computing system as understood to one skilled in the art.}
receiving personalized data from a cloud when receiving a request from a user;
{[0345] In step 1320, the vehicle control system 204, using an application, may create a new record in table 1200 for the user. This new record may store a user identifier and their characteristics 1212. It may also store the area 508 and zone 512 in data portions 1216 and 1220. The new record may then be capable of receiving new settings data for this particular user. In this way, the vehicle 104 can automatically identify or characterize a person so that settings may be established for the person in the vehicle 104.
[0346] The determination may be made after receiving a user input from the user. For example, the user may make a selection on a touch sensitive display indicating that settings currently made are to be stored. In other situations, a period of time may elapse after the user has made a configuration. After determining that the user is finished making changes to the settings, based on the length of the period of time since the setting was established, the vehicle control system 204 can save the setting. Thus, the vehicle control system 204 can make settings automatically based on reaching a steady state for settings for user.}
storing the personalized data in a physical repository within an automotive infotainment system;
{[0381] In the event that at least some of the received information qualifies as user profile data, the method 2000 continues by storing the user profile data in a profile data 252 memory associated with the user (step 2016). As previously described, the profile data 252 may include one or more user profiles and may be stored locally (e.g., in a memory of a device 212, 248, and/or in a memory of a vehicle 104, etc.) and/or remotely (e.g., on the cloud, in a remote storage memory, and/or other memory location, etc.). The profile data 252 may include one or more security features to prevent unauthorized access and/or use of a user profile. These one or more security features may include an identity, identification, password, passphrase, key, and/or other authentication feature, etc.}
wherein the generating and executing of the virtual machine through the predetermined virtualization library comprises generating the virtual machine corresponding to each user terminal when the number of users is less than or equal to a preset number,
{[0343 - 0345] …. For example, sensors 242 in a seat, may determine that some new amount of weight has been registered. The amount of weight may fall within predetermined parameters (e.g., over a threshold, in a specific range, etc.). This weight may then be determined to be a person by one or more optical or other sensors 242. The vehicle control system 204 may then determine that a person is in a certain zone 512 or area 508. For example, the sensors 242 may send signals to the vehicle controls system 204 that an event has occurred….
[0345] … If the person has been identified previously and their characteristics stored in portion 1212, the method 1300 proceeds YES to step 1316 where that person may be identified. In identifying a person, the information associated with that person 1240 may be retrieved and provided to the vehicle control system 204 for further action. If a person cannot be identified by finding their sensor characteristics in portion 1212, the method 1300 proceeds NO to step 1320. In step 1320, the vehicle control system 204, using an application, may create a new record in table 1200 for the user. This new record may store a user identifier and their characteristics 1212….}
and generating the virtual machine corresponding to each operating system of the user terminal when the number of users exceeds the preset number.
{[0022] The present disclosure can provide a number of advantages depending on the particular aspect, embodiment, and/or configuration. One advantage includes the creation and maintenance of user profiles associated with users of a vehicle. Among other things, the user profiles can act as a repository for user information. This user information can be used by any number of entities and/or devices in tracking a user, providing an output, manipulating controls of a vehicle, and/or creating custom control interfaces (e.g., gestures, etc.). The user profile may be transferred between at least one of vehicles, users, companies, groups, etc., and combinations thereof. …}
[0345] … If the person has been identified previously and their characteristics stored in portion 1212, the method 1300 proceeds YES to step 1316 where that person may be identified. In identifying a person, the information associated with that person 1240 may be retrieved and provided to the vehicle control system 204 for further action. If a person cannot be identified by finding their sensor characteristics in portion 1212, the method 1300 proceeds NO to step 1320. In step 1320, the vehicle control system 204, using an application, may create a new record in table 1200 for the user. This new record may store a user identifier and their characteristics 1212….}
Ricci does not explicitly disclose the virtual machine elements as well as a predetermined virtualization library. However, Wagner discloses:
Virtual machine and generating and executing a virtual machine through a predetermined virtualization library;
{[Col 5 line 49- Col 6 line 3] Specifically, the virtual machine instance manager can, prior to receiving the user code and prior to receiving any information from a user regarding any particular virtual machine instance configuration, create and configure virtual machine instances according to a predetermined set of configurations, each corresponding to any one or more of a variety of run-time environments. Thereafter, the virtual machine instance manager receives user-initiated requests to execute code, and identifies a pre-configured virtual machine instance to execute the code based on configuration information associated with the request. The virtual machine instance manager can further allocate the identified virtual machine instance to execute the user's code at least partly by creating and configuring containers inside the allocated virtual machine instance, and provisioning the containers with code of the task as well as an dependency code objects.
[Col 16 line 50-65] On receiving a request to execute a task, a worker manager 140 finds capacity to execute a task on the on-demand code execution system 110. For example, if there exists a particular virtual machine instance in the active pool 140A that has a container with the user code of the task already loaded therein (e.g., code 156D-1 shown in the container 156D), the worker manager 140 may assign the container to the task and cause the task to be executed in the container. Alternatively, if the user code of the task is available in the local cache of one of the virtual machine instances (e.g., codes 158G, 158H, which are stored on the instance 158 but do not belong to any individual containers), the worker manager 140 may create a new container on such an instance, assign the container to the task, and cause the user code of the task to be loaded and executed in the container.}
Motivation: It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the infotainment system as disclosed by Ricci with the inclusion of a generating and execute of virtual machine the predetermined virtualization library and a preset as taught by Wagner.
The combination of Ricci and Wagner does not disclose reading the personalized data, however Dimitrov discloses:
reading the personalized data by connecting a virtual repository that is generated through the virtual machine and the physical repository; and
{[0040] FIG. 8 is a flow diagram of an example method 800 of updating virtual machine status and configuration information. Initially, an orchestrator reads virtual machine runtime states and configurations at 802. For example, orchestrator 108 reads virtual machine runtime states for virtual machines 114 in FIG. 1, discussed above. The orchestrator stores the virtual machine runtime states and configurations at 804. In some embodiments, the runtime states are stored in memory. In the event of a malfunctioning orchestrator, the in-memory runtime state information can be re-created using the monitoring agents of all virtual machines running in the application management platform 100.
[0043] Initially, the method 900 identifies multiple provisioned virtual machines 902 based on, for example, information stored in repository 112 (FIG. 1). In some embodiments, the repository 112 stores information about currently provisioned virtual machines running within application management platform 100. In other embodiments, one or more other components or systems store information regarding the currently provisioned virtual machines. The method 900 analyzes any application instances running on each of the provisioned virtual machines at 904 to determine the status (e.g., active or inactive) of the application instances. For example, the virtual machine monitor 400 (FIG. 4) regularly monitors application processes and sends that information to the orchestrator 108 (FIG. 1). The orchestrator 108 uses the information from the virtual machine monitor 400 as well as information received from the monitoring module 110 (FIG. 1) to determine the status of each application instance.}
executing a service application that is to operate in the virtual machine based on the personalized data,
{[0043] Initially, the method 900 identifies multiple provisioned virtual machines 902 based on, for example, information stored in repository 112 (FIG. 1). In some embodiments, the repository 112 stores information about currently provisioned virtual machines running within application management platform 100. In other embodiments, one or more other components or systems store information regarding the currently provisioned virtual machines. The method 900 analyzes any application instances running on each of the provisioned virtual machines at 904 to determine the status (e.g., active or inactive) of the application instances. For example, the virtual machine monitor 400 (FIG. 4) regularly monitors application processes and sends that information to the orchestrator 108 (FIG. 1). The orchestrator 108 uses the information from the virtual machine monitor 400 as well as information received from the monitoring module 110 (FIG. 1) to determine the status of each application instance. In some situations, a particular virtual machine may not be running any application instances. Further, some virtual machines may include one or more instances of applications that were started on the virtual machine, but no longer active. For example, inactive application instances may include instances of applications that were deployed, but are not registered in the load balancer 106 (FIG. 1). This may occur due to an application failure, manual stoppage of the application by a user, and the like.}
Motivation: It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the infotainment system as disclosed by Ricci and Wagner with the inclusion of reading the personalized data as taught by Dimitrov.
As per claim 16;
Ricci discloses;
A personalized infotainment virtualization system in a car sharing environment, comprising:
a physical repository configured to store personalized data received from a cloud;
{[0118] The vehicle control system 204 may communicate through the communication network 224 to a server 228 that may be located in a facility that is not within physical proximity to the vehicle 104. Thus, the server 228 may represent a cloud computing system or cloud storage that allows the vehicle control system 204 to either gain access to further computing capabilities or to storage at a location outside of the vehicle 104. The server 228 can include a computer processor and memory and be similar to any computing system as understood to one skilled in the art.
[0367] The vehicle control system 204 may then wait a period of time, in step 1836. The period of time may be any amount of time from seconds to minutes to days. Thereinafter, the vehicle control system 204 can receive new data from vehicle sensors 242, in step 1828. Thus, the vehicle control system 204 can receive data periodically and update or continue to refine the health data and safety parameters in data structure 1204. Thereinafter, the vehicle control system 204 may optionally store the health and safety data in cloud storage 232 by sending it through the communication network 224 to the server 228, in step 1840.}
a kernel configured to manage the personalized data stored in the physical repository;
{[0133] The data storage 320 can include any module for storing, retrieving, and/or managing data in one or more data stores and/or databases. The database or data stores may reside on a storage medium local to (and/or resident in) the vehicle control system 204 or in the vehicle 104. Alternatively, some of the data storage capability may be remote from the vehicle control system 204 or automobile, and in communication (e.g., via a network) to the vehicle control system 204. The database or data stores may reside in a storage-area network (“SAN”) familiar to those skilled in the art. Similarly, any necessary files for performing the functions attributed to the vehicle control system 204 may be stored locally on the respective vehicle control system 204 and/or remotely, as appropriate. The databases or data stores may be a relational database, and the data storage module 320 may be adapted to store, update, and retrieve data in response to specifically-formatted commands. The data storage module 320 may also perform data management functions for any flat file, object oriented, or other type of database or data store.
[0275] A kernel 1028 can be a computer program that manages input/output requests from software and translates them into data processing instructions for the processor 304 and other components of the vehicle control system 204. The kernel 1028 is the fundamental component of the operating system 1004 that can execute many of the functions associated with the OS 1004.}
store the read personalized data in the virtual repository, and
{[0381] In the event that at least some of the received information qualifies as user profile data, the method 2000 continues by storing the user profile data in a profile data 252 memory associated with the user (step 2016). As previously described, the profile data 252 may include one or more user profiles and may be stored locally (e.g., in a memory of a device 212, 248, and/or in a memory of a vehicle 104, etc.) and/or remotely (e.g., on the cloud, in a remote storage memory, and/or other memory location, etc.). The profile data 252 may include one or more security features to prevent unauthorized access and/or use of a user profile. These one or more security features may include an identity, identification, password, passphrase, key, and/or other authentication feature, etc.}
wherein the virtual machine is generated corresponding to each user terminal when the number of users is less than or equal to a preset number,
{[0343 - 0345] …. For example, sensors 242 in a seat, may determine that some new amount of weight has been registered. The amount of weight may fall within predetermined parameters (e.g., over a threshold, in a specific range, etc.). This weight may then be determined to be a person by one or more optical or other sensors 242. The vehicle control system 204 may then determine that a person is in a certain zone 512 or area 508. For example, the sensors 242 may send signals to the vehicle controls system 204 that an event has occurred….
[0345] … If the person has been identified previously and their characteristics stored in portion 1212, the method 1300 proceeds YES to step 1316 where that person may be identified. In identifying a person, the information associated with that person 1240 may be retrieved and provided to the vehicle control system 204 for further action. If a person cannot be identified by finding their sensor characteristics in portion 1212, the method 1300 proceeds NO to step 1320. In step 1320, the vehicle control system 204, using an application, may create a new record in table 1200 for the user. This new record may store a user identifier and their characteristics 1212….}
and is generated corresponding to each operating system of the user terminal when the number of users exceeds the preset number.
{[0022] The present disclosure can provide a number of advantages depending on the particular aspect, embodiment, and/or configuration. One advantage includes the creation and maintenance of user profiles associated with users of a vehicle. Among other things, the user profiles can act as a repository for user information. This user information can be used by any number of entities and/or devices in tracking a user, providing an output, manipulating controls of a vehicle, and/or creating custom control interfaces (e.g., gestures, etc.). The user profile may be transferred between at least one of vehicles, users, companies, groups, etc., and combinations thereof. …
[0345] … If the person has been identified previously and their characteristics stored in portion 1212, the method 1300 proceeds YES to step 1316 where that person may be identified. In identifying a person, the information associated with that person 1240 may be retrieved and provided to the vehicle control system 204 for further action. If a person cannot be identified by finding their sensor characteristics in portion 1212, the method 1300 proceeds NO to step 1320. In step 1320, the vehicle control system 204, using an application, may create a new record in table 1200 for the user. This new record may store a user identifier and their characteristics 1212….}
Ricci does not explicitly disclose the virtual machine elements as well as a predetermined virtualization library. However, Wagner discloses:
a virtual machine configured to:
generate a virtual repository when the virtual machine is generated and executed through a predetermined virtualization library,
{[Col 5 line 49- Col 6 line 3] Specifically, the virtual machine instance manager can, prior to receiving the user code and prior to receiving any information from a user regarding any particular virtual machine instance configuration, create and configure virtual machine instances according to a predetermined set of configurations, each corresponding to any one or more of a variety of run-time environments. Thereafter, the virtual machine instance manager receives user-initiated requests to execute code, and identifies a pre-configured virtual machine instance to execute the code based on configuration information associated with the request. The virtual machine instance manager can further allocate the identified virtual machine instance to execute the user's code at least partly by creating and configuring containers inside the allocated virtual machine instance, and provisioning the containers with code of the task as well as an dependency code objects.
[Col 16 line 50-65] On receiving a request to execute a task, a worker manager 140 finds capacity to execute a task on the on-demand code execution system 110. For example, if there exists a particular virtual machine instance in the active pool 140A that has a container with the user code of the task already loaded therein (e.g., code 156D-1 shown in the container 156D), the worker manager 140 may assign the container to the task and cause the task to be executed in the container. Alternatively, if the user code of the task is available in the local cache of one of the virtual machine instances (e.g., codes 158G, 158H, which are stored on the instance 158 but do not belong to any individual containers), the worker manager 140 may create a new container on such an instance, assign the container to the task, and cause the user code of the task to be loaded and executed in the container.}
Motivation: It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the infotainment system as disclosed by Ricci with the inclusion of a predetermined virtualization library and a preset as taught by Wagner.
The combination of Ricci and Wagner does not disclose reading the personalized data, however Dimitrov discloses:
read the personalized data by connecting the virtual repository to the physical repository,
{[0040] FIG. 8 is a flow diagram of an example method 800 of updating virtual machine status and configuration information. Initially, an orchestrator reads virtual machine runtime states and configurations at 802. For example, orchestrator 108 reads virtual machine runtime states for virtual machines 114 in FIG. 1, discussed above. The orchestrator stores the virtual machine runtime states and configurations at 804. In some embodiments, the runtime states are stored in memory. In the event of a malfunctioning orchestrator, the in-memory runtime state information can be re-created using the monitoring agents of all virtual machines running in the application management platform 100.
[0043] Initially, the method 900 identifies multiple provisioned virtual machines 902 based on, for example, information stored in repository 112 (FIG. 1). In some embodiments, the repository 112 stores information about currently provisioned virtual machines running within application management platform 100. In other embodiments, one or more other components or systems store information regarding the currently provisioned virtual machines. The method 900 analyzes any application instances running on each of the provisioned virtual machines at 904 to determine the status (e.g., active or inactive) of the application instances. For example, the virtual machine monitor 400 (FIG. 4) regularly monitors application processes and sends that information to the orchestrator 108 (FIG. 1). The orchestrator 108 uses the information from the virtual machine monitor 400 as well as information received from the monitoring module 110 (FIG. 1) to determine the status of each application instance.}
execute a service application that is to operate in a virtual environment based on the personalized data,
{[0043] Initially, the method 900 identifies multiple provisioned virtual machines 902 based on, for example, information stored in repository 112 (FIG. 1). In some embodiments, the repository 112 stores information about currently provisioned virtual machines running within application management platform 100. In other embodiments, one or more other components or systems store information regarding the currently provisioned virtual machines. The method 900 analyzes any application instances running on each of the provisioned virtual machines at 904 to determine the status (e.g., active or inactive) of the application instances. For example, the virtual machine monitor 400 (FIG. 4) regularly monitors application processes and sends that information to the orchestrator 108 (FIG. 1). The orchestrator 108 uses the information from the virtual machine monitor 400 as well as information received from the monitoring module 110 (FIG. 1) to determine the status of each application instance. In some situations, a particular virtual machine may not be running any application instances. Further, some virtual machines may include one or more instances of applications that were started on the virtual machine, but no longer active. For example, inactive application instances may include instances of applications that were deployed, but are not registered in the load balancer 106 (FIG. 1). This may occur due to an application failure, manual stoppage of the application by a user, and the like.}
Motivation: It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the infotainment system as disclosed by Ricci, with the inclusion of a library as taught by Dimitrov, to store the personalized data.
Claim(s) 2, 3, 4, 5, 8, 9, 10, 11, 12, 13, 14, 15 are rejected under 35 U.S.C. 103 as being unpatentable over Ricci et al [2016/0325755] hereafter Ricci, in view of Wagner et al [10564946] hereafter Wagner; in view of Dimitrov et al [2013/0275969] hereafter Dimitrov, in further view of Sham et al [2020/0193344] hereafter Sham.
As per claim 2;
The combination teaches the above-enclosed limitations. Sham further discloses the following limitations:
The method of claim 1, wherein the receiving of the personalized data from the cloud when receiving the request from the user comprises receiving any one of a request for car rental, a request for a car return, and a request to execute a specific service from any one of an unspecified number of users.
{[0029] At 202, a request for using a vehicle 102 can be generated by user device 108. This request can include information regarding the user 107, a manner for using vehicle 102, and/or any other elements. The information regarding user 107 can include information indicating an identity of the user, a current location of the user 107, and/or any other information regarding user 107. The information regarding the manner for sharing the vehicle 102 may include a time window during which the user 107 desires to use vehicle 102, a type of vehicle 102 desired by user 107 for the sharing experience, and/or any other information regarding the manner for sharing the vehicle 102.}
Motivation: It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the infotainment system as disclosed by Ricci, with the inclusion of a request for a car rental as taught by Sham, to receive a user service request.
As per claim 3;
The combination teaches the above-enclosed limitations; Sham discloses:
The method of claim 1, wherein the receiving of the personalized data from the cloud when receiving the request from the user comprises receiving user data comprising:
a car rental user ID, a rental car ID, and rental time information, and service data comprising:
user driving information, device connection information, service use information, and other personal information.
{[0047] At an operation 302, a first request to use a vehicle may be received from a user device. The request received 302 may include information indicating a specific time (e.g. 30 minutes later from now) when the vehicle is to be used, a proposed pickup location where the vehicle is to picked up for the use, identification information regarding a user making the request, and/or any other information.}
Motivation: It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the infotainment system as disclosed by Ricci with the inclusion of a service and driver information, as taught by Sham, for documentation purposes.
As per claim 4;
Ricci discloses;
The method of claim 3, further comprising: receiving, from the cloud, the personalized data updated based on the user ID after the car is rented; and updating the personalized data stored in the physical repository based on the updated personalized data.
{[0381] In the event that at least some of the received information qualifies as user profile data, the method 2000 continues by storing the user profile data in a profile data 252 memory associated with the user (step 2016). As previously described, the profile data 252 may include one or more user profiles and may be stored locally (e.g., in a memory of a device 212, 248, and/or in a memory of a vehicle 104, etc.) and/or remotely (e.g., on the cloud, in a remote storage memory, and/or other memory location, etc.). The profile data 252 may include one or more security features to prevent unauthorized access and/or use of a user profile. These one or more security features may include an identity, identification, password, passphrase, key, and/or other authentication feature, etc.
[0045] The method 2800 begins at step 2804 and proceeds by determining gestures stored in a user profile (step 2808). The gestures stored in the user profile can be any of the gestures described above (e.g., in conjunction with FIGS. 11I-11K, etc.). Gestures can be stored locally (e.g., at a vehicle 104, a device 212, 248, etc.) and/or remotely (e.g., on the cloud, a server 228 and profile data 252 memory, etc.). In some cases, the gestures may include distinguishable (i.e., easily detectable) gestures that are preset to cause specific responses. Additionally, or alternatively, when a user 216 and/or group of users 216 (e.g., a family, business, institution, etc.) owns multiple vehicles 104, the vehicles 104 can be registered with the cloud (e.g., server 228, etc.) and feature settings, gestures, and other customized parameters can be shared among the various vehicles 104 associated with the user 216 and/or group of users.}
As per claim 5;
Ricci discloses;
The method of claim 3, wherein the executing of the service application that is to operate in the virtual machine based on the personalized data comprises:
detecting service use information included in the service data;
{[0289] The panel launcher 1040 can allow for the launching or executing of applications or processes by receiving inputs from a user interface to launch programs.
[0127] The processor 304 may comprise a general-purpose programmable processor or controller for executing application programming or instructions. The processor 304 may, optionally, include multiple processor cores, and/or implement multiple virtual processors.}
detecting user data corresponding to the service use information;
{[0408] The method begins at step 2404 and continues by retrieving a vehicle template 2408. The vehicle template may be retrieved from a template data 2220 memory and/or a user profile associated with a user 216. Retrieving the template may be similar, or identical, to the template retrieval as described in conjunction with step 2308 of FIG. 23. The vehicle template may be retrieved in response to identifying a user 216 and/or a user profile associated with a vehicle 104.}
and executing a corresponding service application based on the service use information and the user data.
{[0408] The method begins at step 2404 and continues by retrieving a vehicle template 2408. The vehicle template may be retrieved from a template data 2220 memory and/or a user profile associated with a user 216. Retrieving the template may be similar, or identical, to the template retrieval as described in conjunction with step 2308 of FIG. 23. The vehicle template may be retrieved in response to identifying a user 216 and/or a user profile associated with a vehicle 104.
[0402] The method 2300 continues by utilizing the retrieved vehicle template in a vehicle 104 (step 2312). Utilizing the vehicle template can include configuring settings, features, controls, and/or other aspects of the vehicle 104 in accordance with data stored in the vehicle template. For example, data in a vehicle template may include restrictions on speed limits.}
As per claim 8;
Ricci discloses:
The method of claim 1, after the executing of the service application that is to operate in the virtual machine based on the personalized data, further comprising:
operating a host container when the automotive infotainment system is booted;
{[0174] Once the device is established within a zone 512, a profile associated with the vehicle 104 can store information identifying that device and/or a person and optionally associating it with a particular zone 512 as a default. As discussed, there can be a master profile optionally associated with the device in zone A 512A, this master profile can govern communications with the communications subsystems 340 and where communications within vehicle 104 are to occur.}
searching whether a user device that has already been registered with the automotive infotainment system is present within a preset range and connecting the user device to the automotive infotainment system;
{[0344] The vehicle control system 204 can receive the information from the sensors 242 and use that information to search the database 1200 that may be stored within the system data 208. The sensor data may be compared to ID characteristics 1212 to determine if the person has already been identified. The vehicle control system 204 may also send the characteristic data from the sensors to the communication network 224 to a server 228 to compare the sensor data to stored data 232 that may be stored in a cloud system. The person's features can be compared to stored features 1212 to determine if the person in the vehicle 104 can be identified.}
[[and]] generating sub-containers so that the sub-containers correspond to a number of connected user devices; and
managing data to be transmitted to and received from a sub-container corresponding to a user device that is now selected, among the connected user devices.
{[0113] As an example, the profile data 252 may include one or more user profiles. User profiles may be generated based on data gathered from one or more of vehicle preferences (e.g., seat settings, HVAC settings, dash configurations, and the like), recorded settings, geographic location information (e.g., provided by a satellite positioning system (e.g., GPS), Wi-Fi hotspot, cell tower data, etc.), mobile device information (such as mobile device electronic addresses, Internet browsing history and content, application store selections, user settings and enabled and disabled features, and the like), private information (such as user information from a social network, user presence information, user business account, and the like), secure data, biometric information, audio information from on board microphones, video information from on board cameras, Internet browsing history and browsed content using an on board computer and/or the local area network enabled by the vehicle 104, geographic location information (e.g., a vendor storefront, roadway name, city name, etc.), and the like.}
As per claim 9;
Ricci discloses;
The method of claim 8, further comprising generating contents relating to a connection or a disconnection as the device connection information when at least one of the connected user devices is disconnected or at least one of the already registered user devices is connected.
{[0114] The profile data 252 may include one or more user accounts. User accounts may include access and permissions to one or more settings and/or feature preferences associated with the vehicle 104, communications, infotainment, content, etc. In one example, a user account may allow access to certain settings for a particular user, while another user account may deny access to the settings for another user, and vice versa. The access controlled by the user account may be based on at least one of a user account priority, role, permission, age, family status, a group priority (e.g., the user account priority of one or more users, etc.), a group age (e.g., the average age of users in the group, a minimum age of the users in the group, a maximum age of the users in the group, and/or combinations thereof, etc.).}
As per claim 10;
Ricci discloses;
The method of claim 8, wherein the generating of the sub-container so that the sub-container corresponds to the number of connected user devices comprises:
requesting user setting information from a respective one of the connected user devices based on device connection information of the respective connected user device;
{[0386] The method 2100 begins at step 2104 and proceeds when a request is received to access profile data 252. As provided herein, the profile data 252 may include at least one user profile and/or data associated with at least one user 216. The request to access profile data 252 may be made in response to identifying and/or recognizing a user 216. In one embodiment, the request to access profile data 252 may be made in response to identifying and/or recognizing at least one device 212, 248 associated with a user 216 and/or vehicle 104. In any event, the request may be received via the profile identification module 848 and/or the profile data 252 memory.}
and generating setting information of the sub-container based on the user setting information.
{[0114 - 116] The profile data 252 may include one or more user accounts. User accounts may include access and permissions to one or more settings and/or feature preferences associated with the vehicle 104, communications, infotainment, content, etc. In one example, a user account may allow access to certain settings for a particular user, while another user account may deny access to the settings for another user, and vice versa. The access controlled by the user account may be based on at least one of a user account priority, role, permission, age, family status, a group priority (e.g., the user account priority of one or more users, etc.), a group age (e.g., the average age of users in the group, a minimum age of the users in the group, a maximum age of the users in the group, and/or combinations thereof, etc.).
[0115] For example, a user 216 may be allowed to purchase applications (e.g., software, etc.) for the vehicle 104 and/or a device associated with the vehicle 104 based on information associated with the user account. This user account information may include a preferred payment method, permissions, and/or other account information. As provided herein, the user account information may be part of the user profile and/or other data stored in the profile data 252.}
As per claim 11;
Ricci discloses;
The method of claim 10, wherein the generating of the setting information of the sub-container based on the user setting information comprises generating the setting information of the sub-container comprising an application, content, and a UI configuration to be provided through the sub-container.
{[0113 - 116] User profiles may be generated based on data gathered from one or more of vehicle preferences (e.g., seat settings, HVAC settings, dash configurations, and the like), recorded settings, geographic location information (e.g., provided by a satellite positioning system (e.g., GPS), Wi-Fi hotspot, cell tower data, etc.), mobile device information (such as mobile device electronic addresses, Internet browsing history and content, application store selections, user settings and enabled and disabled features, and the like), private information (such as user information from a social network, user presence information, user business account, and the like), secure data, biometric information, audio information from on board microphones, video information from on board cameras, Internet browsing history and browsed content using an on board computer and/or the local area network enabled by the vehicle 104, geographic location information (e.g., a vendor storefront, roadway name, city name, etc.), and the like.
[0114] The profile data 252 may include one or more user accounts. User accounts may include access and permissions to one or more settings and/or feature preferences associated with the vehicle 104, communications, infotainment, content, etc
[0115] For example, a user 216 may be allowed to purchase applications (e.g., software, etc.) for the vehicle 104 and/or a device associated with the vehicle 104 based on information associated with the user account. This user account information may include a preferred payment method, permissions, and/or other account information. As provided herein, the user account information may be part of the user profile and/or other data stored in the profile data 252.
[0116] In this example, the user account information in the profile data 252 associated with both the adult user and the child user may be used by the vehicle 104 in determining whether content is appropriate for the area given the age of the child user.}
As per claim 12;
Ricci discloses;
The method of claim 8, wherein the managing of the data to be transmitted to and received from the sub-container corresponding to the user device that is now; elected, among the connected user devices, comprises:
{[0114] The profile data 252 may include one or more user accounts. User accounts may include access and permissions to one or more settings and/or feature preferences associated with the vehicle 104, communications, infotainment, content, etc. In one example, a user account may allow access to certain settings for a particular user, while another user account may deny access to the settings for another user, and vice versa. The access controlled by the user account may be based on at least one of a user account priority, role, permission, age, family status, a group priority (e.g., the user account priority of one or more users, etc.), a group age (e.g., the average age of users in the group, a minimum age of the users in the group, a maximum age of the users in the group, and/or combinations thereof, etc.).}
providing the data to a sub-container corresponding to any one user device5elected by the user, among the connected user devices;
and providing a service corresponding to the data by displaying a sub-container5creen corresponding to the sub-container through an interface.
{[0112] The device or user interface 212, 248 can receive input or provide information to a user 216. The user 216 may thus interact with the vehicle control system 204 through the interface or device 212, 248. Further, the device 212, 248 may include or have access to device data 220 and/or profile data 252. The device data 220 can be any type of data that is used in conjunction with the device 212, 248 including, but not limited to, multimedia data, preferences data, device identification information, or other types of data.}
{[0115 - 116] For example, a user 216 may be allowed to purchase applications (e.g., software, etc.) for the vehicle 104 and/or a device associated with the vehicle 104 based on information associated with the user account. This user account information may include a preferred payment method, permissions, and/or other account information. As provided herein, the user account information may be part of the user profile and/or other data stored in the profile data 252.
[0116] In this example, the user account information in the profile data 252 associated with both the adult user and the child user may be used by the vehicle 104 in determining whether content is appropriate for the area given the age of the child user.}
As per claim 13;
Ricci discloses;
The method of claim 8, wherein the managing of the data to be transmitted and received from the sub-container corresponding to the user device that is currently; elected, among the connected user devices, comprises:
receiving, from the user, a request to change the user device through an interface of the automotive infotainment system;
and replacing a first sub-container corresponding to a first user device that is being used to transmit and receive the data with a second sub-container corresponding to a second user device.
{[0347 - 0348] The vehicle control system 204 may then store the settings for the person, in step 1328. The user interaction subsystem 332 can make a new entry for the user 1208 in data structure 1204. The new entry may be either a new user or a new-settings listed in 1224. The settings may be stored based on the area 508 and zone 512. As explained previously, the settings can be any kind of configuration of the vehicle 104 that may be associated with the user in that area 508 and the zone 512.
[0348] The settings may also be stored in cloud storage, in step 1332. Thus, the vehicle control system 204 can send the new settings to the server 228 to be stored in storage 232. In this way, these new settings may be ported to other vehicles for the user. Further, the settings in storage system 232 may be retrieved, if local storage does not include the settings in storage system 208.}
Second user device.
{[0165] By way of example, a device 212, 248 associated with a user 216 may be located at a second outside area 520 from the vehicle 104. In this case, and based at least partially on the distance of the device 212, 248 from the vehicle 104 (e.g., provided by detecting the device 212, 248 at or beyond the second outside area 520) the vehicle 104 may lock one or more features (e.g., ignition access, vehicle access, communications ability, etc.) associated with the vehicle 104. Optionally, the vehicle 104 may provide an alert based on the distance of the device 212, 248 from the vehicle 104.}
As per claim 14;
Ricci discloses;
The method of claim 13, wherein the managing of the data to be transmitted to and received from the sub-container corresponding to the user device that is currently; elected, among the connected user devices, comprises replacing the first sub-container with the second sub-container when receiving, from the user, a touch input or swipe input to a sub-container screen corresponding to a plurality of the connected user devices that have been displayed on the interface.
{[0390] In the event that the request is determined to be authorized, the method 2100 may continue at step 2116 by providing access to the user profile and/or profile data 252. Access may include copying at least one portion of the user profile, deleting at least one portion of the user profile, modifying at least one portion of the user profile, transferring the user profile, and/or the like. For example, a user 216 may request access to the user profile to configure a vehicle 104 using settings and/or preferences stored in the user profile. In some embodiments, the user profile, or portions thereof, may be copied to a memory of the vehicle 104. In one embodiment, the user profile may be read from the profile data 252 memory, without necessarily copying all of the user profile. In any embodiment, the vehicle 104 may read the settings and/or preferences from the user profile, and in response, configure at least one area 508 and/or zone 512 of the vehicle 104 based at least partially on the user profile information. In another example, an agency may wish to configure a vehicle 104 based on a user profile stored in profile data 252 memory.}
when receiving, from the user, a touch input or swipe input
{[0291 - 292] One or more gestures used to interface with the vehicle control system 204 may be as described in conjunction with FIG. 11A through 11K. FIGS. 11A through 11H depict various graphical representations of gesture inputs that may be recognized by the devices 212, 248. The gestures may be performed not only by a user's body part, such as a digit, but also by other devices, such as a stylus, that may be sensed by the contact sensing portion(s) of a screen associated with the device 212, 248.
[0292] With reference to FIGS. 11A-11H, a first type of gesture, a touch gesture 1120, is substantially stationary on a portion (e.g., a screen, a display, etc.) of a device 212, 248 for a selected length of time. A circle 1128 represents a touch or other contact type received at particular location of a contact sensing portion of the screen. The circle 1128 may include a border 1132, the thickness of which indicates a length of time that the contact is held substantially stationary at the contact location. For instance, a tap 1120 (or short press) has a thinner border 1132A than the border 1132B for a long press 1124 (or for a normal press). The long press 1124 may involve a contact that remains substantially stationary on the screen for longer time period than that of a tap 1120. As will be appreciated, differently defined gestures may be registered depending upon the length of time that the touch remains stationary prior to contact cessation or movement on the screen.}
As per claim 15;
Ricci discloses;
The method of claim 8, wherein the managing of the data to be transmitted to and received from the sub-container corresponding to the user device that is currently selected, among the connected user devices, comprises:
receiving, from the user,
{[0347] The vehicle control system 204 may then store the settings for the person, in step 1328. The user interaction subsystem 332 can make a new entry for the user 1208 in data structure 1204. The new entry may be either a new user or a new-settings listed in 1224. The settings may be stored based on the area 508 and zone 512. As explained previously, the settings can be any kind of configuration of the vehicle 104 that may be associated with the user in that area 508 and the zone 512.
coordinate information corresponding to a predetermined input through the interface;
{[0298] Context commonly refers to one or more of the particular application(s) selected by the gesture and the portion(s) of the application currently executing, whether the application is a single- or multi-screen application, and whether the application is a multi-screen application displaying one or more windows. A sensed location of the gesture commonly refers to whether the sensed set(s) of gesture location coordinates are on a touch sensitive display or a gesture capture region of a device 212, 248, whether the sensed set(s) of gesture location coordinates are associated with a common or different display, or screen, or device 212, 248, and/or what portion of the gesture capture region contains the sensed set(s) of gesture location coordinates.}
receiving data corresponding to a command by transmitting, to a first user device, the command corresponding to the coordinate information;
and transmitting the data to a first sub-container corresponding to the first user device.
{[0353] After identifying the user by matching characteristics with the features in portion 1212, the vehicle control system 204 can determine if there are settings for the user for the area 1216 and zone 1220 the user currently occupies. If there are settings, then the vehicle control system 204 can make the determination that there are settings in portion 1224, and the vehicle control system 204 may then read and retrieve those settings, in step 1420. The settings may be then used to configure or react to the presence of the user, in step 1424. Thus, these settings may be obtained to change the configuration of the vehicle 104, for example, how the position of the seats or mirrors are set, how the dash, console, or heads up display is configured, how the heat or cooling is configured, how the radio is configured, or how other different configurations are made.}
First user device
{[0165] Optionally, the location of the device 212, 248 relative to the vehicle 104 may determine vehicle functionality and/or features to be provided and/or restricted to a user 216. By way of example, a device 212, 248 associated with a user 216 may be located at a second outside area 520 from the vehicle 104. In this case, and based at least partially on the distance of the device 212, 248 from the vehicle 104 (e.g., provided by detecting the device 212, 248 at or beyond the second outside area 520) the vehicle 104 may lock one or more features (e.g., ignition access, vehicle access, communications ability, etc.) associated with the vehicle 104. Optionally, the vehicle 104 may provide an alert based on the distance of the device 212, 248 from the vehicle 104. Continuing the example above, once the device 212, 248 reaches the first outside area 516 of the vehicle 104 at least one of the vehicle features may be unlocked. For instance, by reaching the first outside area 516, the vehicle 104 may unlock a door of the vehicle 104. In some cases, when the device is detected to be inside the vehicle 104, the various sensors 236, 242 may determine that the user 216 is in an area 508 and/or zone 512. As is further described herein, features of the vehicle 104, device 212, 248, and/or other components may be controlled based on rules stored in a memory.}
Claim(s) 6, 7 are rejected under 35 U.S.C. 103 as being unpatentable over Ricci et al [2016/0325755] hereafter Ricci, in view of Wagner et al [10564946] hereafter Wagner, in view of Dimitrov et al [2013/0275969] hereafter Dimitrov, in further view of Johnson et al [2020/0331433] hereafter Johnson.
As per claim 6;
The combination teaches the above-enclosed limitations. Johnson further discloses the following limitations:
The method of claim 1, further comprising:
receiving a request for a car return from the user;
{[0005] In accordance with another exemplary aspect, the inventors disclose a method for performing an automated return administration of a rental vehicle, the method comprising (1) receiving input from a mobile device of a driver for the rental vehicle that is indicative of a request to schedule a return for the rental vehicle, (2) in response to the received input, communicating information from a reservation record for the rental vehicle to the driver's mobile device to populate a pre-return graphical user interface (GUI) for display on the driver's mobile device, the GUI being configured to solicit return information from the driver, (3) receiving the solicited return information from the driver's mobile device through the GUI, and (4) storing the received return information in memory in association with the reservation record; and wherein the method steps are performed by a processor.}
Motivation: It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the infotainment system as disclosed by Ricci with the inclusion of a return administration, as taught by Johnson.
Johnson teaches vehicle return administration; however, Dimitrov discloses the termination of the virtual machine. Dimitrov teaches;
terminating the virtual machine that is being executed;
{[0026] A particular embodiment may include any number of individual virtual machines operating at a specific time. The number of operating virtual machines typically changes over time as new virtual machines are provisioned or terminated based on the changing needs of the end-users, the systems utilizing the virtual machines, and the like.}
transmitting the personalized data stored in the physical repository to the cloud; and discarding the personalized data stored in the physical repository.
{[0381 In the event that at least some of the received information qualifies as user profile data, the method 2000 continues by storing the user profile data in a profile data 252 memory associated with the user (step 2016). As previously described, the profile data 252 may include one or more user profiles and may be stored locally (e.g., in a memory of a device 212, 248, and/or in a memory of a vehicle 104, etc.) and/or remotely (e.g., on the cloud, in a remote storage memory, and/or other memory location, etc.). The profile data 252 may include one or more security features to prevent unauthorized access and/or use of a user profile. These one or more security features may include an identity, identification, password, passphrase, key, and/or other authentication feature, etc.}
As per claim 7;
Ricci discloses:
The method of claim 6, wherein the transmitting of the personalized data stored in the physical repository to the cloud comprises transmitting,
{[0348] The settings may also be stored in cloud storage, in step 1332. Thus, the vehicle control system 204 can send the new settings to the server 228 to be stored in storage 232. In this way, these new settings may be ported to other vehicles for the user. Further, the settings in storage system 232 may be retrieved, if local storage does not include the settings in storage system 208.}
to the cloud, the personalized data of the physical repository in which personalized data that has been newly generated while the car is rented is also stored.
{[0117 - 0118] The vehicle control system 204 may also communicate with or through a communication network 224. The communication network 224 can represent any type of wireless and/or wired communication system that may be included within the vehicle 104 or operable to communicate outside the vehicle 104……
[0118] The vehicle control system 204 may communicate through the communication network 224 to a server 228 that may be located in a facility that is not within physical proximity to the vehicle 104. Thus, the server 228 may represent a cloud computing system or cloud storage that allows the vehicle control system 204 to either gain access to further computing capabilities or to storage at a location outside of the vehicle 104. The server 228 can include a computer processor and memory and be similar to any computing system as understood to one skilled in the art.}
Response to Arguments
In response to the argument filled October 1, 2025, regarding the 103 rejections, the Examiner Respectfully disagrees.
Applicant argues that the prior art of record fails to teach the claims, specifically that the prior art does not disclose or suggest the “generation and execution of a virtual machine through a predetermined virtualization library…..wherein the generating and executing of the virtual machine through the predetermined virtualization library comprises generating the virtual machine corresponding to each user terminal when the number of users is less than or equal to a preset number, and generating the virtual machine corresponding to each operating system of the user terminal when the number of users exceeds the preset number”.
In terms of the arguments, Ricci teaches the preset number based on the user device and number of users. Ricci does not teach specific limitations as amended, specifically virtual machine elements, however, the Examiner now references under 35 USC 103 rejection, Ricci in view of Wagner. Based on the considered amendments cited, 35 USC 103 references have been utilized to teach the claimed invention (claim 1 and 16).
As such, claim 1 and 16 are maintaining the 35 USC 103 rejection as considered above in light of the amended claim limitation.
Applicant argues that the prior art of record fails to teach the claims, specifically that the prior art does not disclose the virtualization (VM) infrastructure or the generation/management of virtual machines.
Examiner respectfully disagrees.
In response to applicant argument the Examiner is citing Ricci for teaching a virtualization system and managing of virtualized machines. {[0118]}. Ricci also teaches the storage of personalized data {[0367]}, infrastructure (kernel and repository execution service applications {[0381]}.
In response to applicant argument the prior art used does teach these limitations. The Examiner is citing Dimitrov for teaching the reading of personalized data and executing service application. See Dimitrov {[0040 - 0043]}.
The Examiner is citing Johnson and Sham for receiving a personalized data request. See Johnson {[0005]} and Sham {[0029] and 0047]}.
Based on the considered amendments cited, 35 USC 103 references have been utilized to
teach the claimed invention (Claim 1 and 16). As such claim 1, 3, 8, 10 and 16 are maintaining the 35 USC 103 rejection as considered above in light of the amended claim limitation. Lacking any further argument, claims 1-16 are maintaining the 35 USC 103 rejection, as considered above in light of the amended claim limitation above.
Conclusion
THIS ACTION IS MADE FINAL. 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 VICTOR CHIGOZIRIM ESONU whose telephone number is (571)272 - 4883. The examiner can normally be reached Monday - Friday 9:00 am - 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, Sarah Monfeldt can be reached on (571) 270-1833. 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, vis it:
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.
/VICTOR CHIGOZIRIM ESONU/ /ANDREW CHASE LAKHANI/ Examiner, Art Unit 3629 Primary Examiner, Art Unit 3629