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 .
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.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1, 9, 12, 18 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Babayan et al. (US 20240394036 A1).
In regards to claim 1, Babayan teaches a vehicle control apparatus comprising a processor configured to check an over-the-air (OTA) software update, detect that a user experience is selected for an updated function (Abstract; Paragraphs 5)
Methods, computing systems, and technology for testing an update controller within a virtual environment are presented. An example computing system accesses data indicative of a rule for distributing the OTA software update. The computing system determines an action to be taken for implementing the OTA software update. The action is based on the rule for distributing the OTA software update and a mocked behavior of an external software service available to the update controller. The mocked behavior simulates a response of the external software service to a request from the update controller within the isolated virtual environment. The computing system accesses data indicating that a vehicle simulator is available for the OTA software update. The computing system generates a task package including the OTA software update and indicating the action to be taken for implementing the OTA software update. The computing system outputs the task package to the vehicle simulator..[Abstr]
One example aspect of the present disclosure is directed to a computing system. The computing system includes a control circuit configured to test, within an isolated virtual environment, an update controller for distributing an over-the-air (OTA) software update. The control circuit is configured to access data indicative of a rule for distributing the OTA software update. The control circuit is configured to determine an action to be taken for implementing the OTA software update. The action is based on the rule for distributing the OTA software update and a mocked behavior of an external software service available to the update controller. The mocked behavior simulates a response of the external software service to a request from the update controller within the isolated virtual environment. The control circuit is configured to access data indicating that a vehicle simulator is available for the OTA software update. The control circuit is configured to generate, for the vehicle simulator, a task package including the OTA software update and indicating the action to be taken for implementing the OTA software update. The control circuit is configured to output the task package to the vehicle simulator within the isolated virtual environment.[P-5]
Babayan then teaches mimicking/mocking a communication signal transmitted to at least one controller related to the updated function based on the selection, and control the at least one controller to operate in a virtual mode using the mimicked communication signal (Paragraphs 6, 7, 11, 12, 46, 129)
In an embodiment, the control circuit is further configured to provision the isolated virtual environment including a simulated instance of the update controller, wherein the simulated instance of the update controller includes a simulated administration service and a simulated vehicle service.[ P-6]
In an embodiment, to provision the isolated virtual environment, the control circuit is configured to provision, within the isolated virtual environment, the vehicle simulator, a simulated consumer service, and a proxy for facilitating mocked behaviors of a plurality of external software services.[ P-7]
In an embodiment, the mocked behavior is based on a behavior of the external software service in a live environment.[P-11]
In an embodiment, the mocked behavior is based on log data generated during communication between the update controller and the external software service in the live computing environment. The log data includes a request parameter associated with the update controller, a response payload provided by the external software service, and a response time indicating a duration of time until the external software service responded to the update controller.[P-12]
In some implementations, techniques can be utilized to prevent mock behaviors from drifting too far from their real-world corollaries. For example, a mocked behavior may drift from the actual behavior of the external dependency. In the event the drift is too great, tests may become less reliable indicators that certain code will work in the real world. To address this situation, as will be further described herein, the technology of the present disclosure may use data collected from calling a given external service in the real world to inform a model governing how the external service responds in the virtual environment (e.g., as represented by its mocked behavior).[P-46]
The testing computing system 500 may provision one or more mocked external software services 640 (also referred to herein as “mocked dependencies 640”). The mocked external software services 640 may represent or simulate one or more of the external services 525 that may be called by the update controller in an actual, live environment. Within the virtual environment 600A, however, the behavior of the external services 525 can be mocked with explicit, contrived behaviors (“mocked behaviors”). A mocked behavior may be defined automatically by the modules associated with integration tests 645 based on the performance of live external software services 525. Additionally, or alternatively, a mocked behavior may be defined based on user input via a user interface and stored in the integration tests 645.[P-129]
The at least one controller is configured to receive the mimicked communication signal and operate in the virtual mode under control of the processor. (Paragraphs 12, 129)
In an embodiment, the mocked behavior is based on log data generated during communication between the update controller and the external software service in the live computing environment. The log data includes a request parameter associated with the update controller, a response payload provided by the external software service, and a response time indicating a duration of time until the external software service responded to the update controller.[P-12]
The testing computing system 500 may provision one or more mocked external software services 640 (also referred to herein as “mocked dependencies 640”). The mocked external software services 640 may represent or simulate one or more of the external services 525 that may be called by the update controller in an actual, live environment. Within the virtual environment 600A, however, the behavior of the external services 525 can be mocked with explicit, contrived behaviors (“mocked behaviors”). A mocked behavior may be defined automatically by the modules associated with integration tests 645 based on the performance of live external software services 525. Additionally, or alternatively, a mocked behavior may be defined based on user input via a user interface and stored in the integration tests 645.[P-129]
In regards to claim 9, Babayan teaches the processor is configured to control the updated function in the virtual mode based on user input provided via switch manipulation or screen touch input. (Paragraphs 59, 114, 129)
The user device 115 may include a computing device owned or otherwise accessible to the user 120. For instance, the user device 115 may include a phone, laptop, tablet, wearable device (e.g., smart watch, smart glasses, headphones), personal digital assistant, gaming system, personal desktop devices, other hand-held devices, or other types of mobile or non-mobile user devices. As further described herein, the user device 115 may include one or more input components such as buttons, a touch screen, a joystick or other cursor control, a stylus, a microphone, a camera or other imaging device, a motion sensor, etc. The user device 115 may include one or more output components such as a display device (e.g., display screen), a speaker, etc. In an embodiment, the user device 115 may include a component such as, for example, a touchscreen, configured to perform input and output functionality to receive user input and present information for the user 120. The user device 115 may execute one or more instructions to run an instance of a software application and present user interfaces associated therewith, as further described herein. In an embodiment, the launch of a software application may initiate a user-network session with the computing platform 110.[P-59]
The consumer systems 520 may automatically create a rule 522 or allow for manual creation of a rule 522. For instance, the consumer systems 520 may be configured to automatically create a rule 522 once an OTA update 515 is validated, deployed, posted, or otherwise made available for distribution. Additionally, or alternatively, the consumer systems 520 may include a display device that is configured to present a user interface for a user of the consumer systems 520. The user interface may allow a user to provide user input to create a rule 522.[P-114]
The testing computing system 500 may provision one or more mocked external software services 640 (also referred to herein as “mocked dependencies 640”). The mocked external software services 640 may represent or simulate one or more of the external services 525 that may be called by the update controller in an actual, live environment. Within the virtual environment 600A, however, the behavior of the external services 525 can be mocked with explicit, contrived behaviors (“mocked behaviors”). A mocked behavior may be defined automatically by the modules associated with integration tests 645 based on the performance of live external software services 525. Additionally, or alternatively, a mocked behavior may be defined based on user input via a user interface and stored in the integration tests 645.[P-129]
In regards to claim 12, Babayan teaches a vehicle control method comprising: checking, by a processor, an over-the-air (OTA) software update(Abstract; Paragraphs 5, 74)
Methods, computing systems, and technology for testing an update controller within a virtual environment are presented. An example computing system accesses data indicative of a rule for distributing the OTA software update. The computing system determines an action to be taken for implementing the OTA software update. The action is based on the rule for distributing the OTA software update and a mocked behavior of an external software service available to the update controller. The mocked behavior simulates a response of the external software service to a request from the update controller within the isolated virtual environment. The computing system accesses data indicating that a vehicle simulator is available for the OTA software update. The computing system generates a task package including the OTA software update and indicating the action to be taken for implementing the OTA software update. The computing system outputs the task package to the vehicle simulator..[Abstr]
One example aspect of the present disclosure is directed to a computing system. The computing system includes a control circuit configured to test, within an isolated virtual environment, an update controller for distributing an over-the-air (OTA) software update. The control circuit is configured to access data indicative of a rule for distributing the OTA software update. The control circuit is configured to determine an action to be taken for implementing the OTA software update. The action is based on the rule for distributing the OTA software update and a mocked behavior of an external software service available to the update controller. The mocked behavior simulates a response of the external software service to a request from the update controller within the isolated virtual environment. The control circuit is configured to access data indicating that a vehicle simulator is available for the OTA software update. The control circuit is configured to generate, for the vehicle simulator, a task package including the OTA software update and indicating the action to be taken for implementing the OTA software update. The control circuit is configured to output the task package to the vehicle simulator within the isolated virtual environment.[P-5]
The hardware layer 205 may be an abstraction layer including computing code that allows for communication between the software and the computing hardware 215 in the vehicle computing system 200. For example, the hardware layer 205 may include interfaces and calls that allow the vehicle computing system 200 to generate a hardware-dependent instruction to the computing hardware 215 (e.g., processors, memories, etc.) of the vehicle 105.[P-74]
Babayan also teaches detecting, by the processor, that a user experience has been selected for an updated function; mimicking, by the processor, a communication signal related to the updated function based on the selection(Paragraphs 6, 7, 11, 12, 46, 129)
In an embodiment, the control circuit is further configured to provision the isolated virtual environment including a simulated instance of the update controller, wherein the simulated instance of the update controller includes a simulated administration service and a simulated vehicle service.[ P-6]
In an embodiment, to provision the isolated virtual environment, the control circuit is configured to provision, within the isolated virtual environment, the vehicle simulator, a simulated consumer service, and a proxy for facilitating mocked behaviors of a plurality of external software services.[ P-7]
In an embodiment, the mocked behavior is based on a behavior of the external software service in a live environment.[P-11]
In an embodiment, the mocked behavior is based on log data generated during communication between the update controller and the external software service in the live computing environment. The log data includes a request parameter associated with the update controller, a response payload provided by the external software service, and a response time indicating a duration of time until the external software service responded to the update controller.[P-12]
In some implementations, techniques can be utilized to prevent mock behaviors from drifting too far from their real-world corollaries. For example, a mocked behavior may drift from the actual behavior of the external dependency. In the event the drift is too great, tests may become less reliable indicators that certain code will work in the real world. To address this situation, as will be further described herein, the technology of the present disclosure may use data collected from calling a given external service in the real world to inform a model governing how the external service responds in the virtual environment (e.g., as represented by its mocked behavior).[P-46]
The testing computing system 500 may provision one or more mocked external software services 640 (also referred to herein as “mocked dependencies 640”). The mocked external software services 640 may represent or simulate one or more of the external services 525 that may be called by the update controller in an actual, live environment. Within the virtual environment 600A, however, the behavior of the external services 525 can be mocked with explicit, contrived behaviors (“mocked behaviors”). A mocked behavior may be defined automatically by the modules associated with integration tests 645 based on the performance of live external software services 525. Additionally, or alternatively, a mocked behavior may be defined based on user input via a user interface and stored in the integration tests 645.[P-129]
Furthermore, the operating, by the processor, the updated function in a virtual mode using the mimicked communication signal(Paragraphs 12, 129)
In an embodiment, the mocked behavior is based on log data generated during communication between the update controller and the external software service in the live computing environment. The log data includes a request parameter associated with the update controller, a response payload provided by the external software service, and a response time indicating a duration of time until the external software service responded to the update controller.[P-12]
The testing computing system 500 may provision one or more mocked external software services 640 (also referred to herein as “mocked dependencies 640”). The mocked external software services 640 may represent or simulate one or more of the external services 525 that may be called by the update controller in an actual, live environment. Within the virtual environment 600A, however, the behavior of the external services 525 can be mocked with explicit, contrived behaviors (“mocked behaviors”). A mocked behavior may be defined automatically by the modules associated with integration tests 645 based on the performance of live external software services 525. Additionally, or alternatively, a mocked behavior may be defined based on user input via a user interface and stored in the integration tests 645.[P-129]
In regards to claim 18, Babayan teaches controlling, by the processor, the updated function in the virtual mode based on user input provided via switch manipulation or screen touch. (Paragraphs 59, 114, 129)
The user device 115 may include a computing device owned or otherwise accessible to the user 120. For instance, the user device 115 may include a phone, laptop, tablet, wearable device (e.g., smart watch, smart glasses, headphones), personal digital assistant, gaming system, personal desktop devices, other hand-held devices, or other types of mobile or non-mobile user devices. As further described herein, the user device 115 may include one or more input components such as buttons, a touch screen, a joystick or other cursor control, a stylus, a microphone, a camera or other imaging device, a motion sensor, etc. The user device 115 may include one or more output components such as a display device (e.g., display screen), a speaker, etc. In an embodiment, the user device 115 may include a component such as, for example, a touchscreen, configured to perform input and output functionality to receive user input and present information for the user 120. The user device 115 may execute one or more instructions to run an instance of a software application and present user interfaces associated therewith, as further described herein. In an embodiment, the launch of a software application may initiate a user-network session with the computing platform 110.[P-59]
The consumer systems 520 may automatically create a rule 522 or allow for manual creation of a rule 522. For instance, the consumer systems 520 may be configured to automatically create a rule 522 once an OTA update 515 is validated, deployed, posted, or otherwise made available for distribution. Additionally, or alternatively, the consumer systems 520 may include a display device that is configured to present a user interface for a user of the consumer systems 520. The user interface may allow a user to provide user input to create a rule 522.[P-114]
The testing computing system 500 may provision one or more mocked external software services 640 (also referred to herein as “mocked dependencies 640”). The mocked external software services 640 may represent or simulate one or more of the external services 525 that may be called by the update controller in an actual, live environment. Within the virtual environment 600A, however, the behavior of the external services 525 can be mocked with explicit, contrived behaviors (“mocked behaviors”). A mocked behavior may be defined automatically by the modules associated with integration tests 645 based on the performance of live external software services 525. Additionally, or alternatively, a mocked behavior may be defined based on user input via a user interface and stored in the integration tests 645.[P-129]
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 2, 4-7, 10, 13, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Babayan et al. (US 20240394036 A1) in view of Nilsson et al. (EP 4372 598 A1).
In regards to claim 2, Babayan fails to teach the processor is configured to implement a virtual motion implementation logic configured to mimic at least one communication signal among a controller area network (CAN) signal and a CAN flexible data-rate (CAN FD) signal and change a signaling value of the mimicked communication signal.
Nilsson on the other hand teaches the processor is configured to implement a virtual motion implementation logic configured to mimic at least one communication signal among a controller area network (CAN) signal and a CAN flexible data-rate (CAN FD) signal and change a signaling value of the mimicked communication signal. (Paragraphs 25, 29, 34, 38)
The data bus 104 can be configured to use any protocol carried over ethernet or similar network technologies. For example, the data bus 104 may act as - or include - a Controller Area Network (CAN) interface, a CANopen interface, a CAN-FD interface, a FlexRay.sup.™ interface, a Local Interconnect Network (LIN) interface, a Data Distribution Service (DDS) interface, or a combination of one or more of these interfaces. The data bus 104 may further support AUTOSAR.sup.™, Protocol Buffers (Protobuf.sup.™), Nanoph, HTTP, and/or restbus, although some of these may not necessarily be regarded as complete data bus interfaces.[P-25]
To provide the platform-independent unified simulation model 150 (figure 1B), the method begins with a step of providing 212.1 a vehicle dynamic model 151 configured to simulate a time evolution of at least one motion state of the vehicle (see above). As used herein, the vehicle dynamic model is a model of the dynamics of the base vehicle, which could include motion in three dimensions. The dynamics include the motion and generated forces in the vehicle's chassis and its tires. The vehicle's dynamics (forces, torques, rotations, accelerations etc.) can be modeled based on first-principle physics equations. The fidelity of the vehicle dynamic model 151 depends on the use case at hand.[P-29]
In a next step 212.4, a communication sub-model 154 representing the data bus 104 is provided. It is recalled that a main functionality of the data bus 104 is to deliver bus messages 110 between pairs of ECUs 103. The communication sub-model 154 captures the use of a single message and/or signal definition. In the example of a CAN or CAN-FD bus, such definitions maybe deposited in a database file (DBC) file, which specifies how to encode physical or human-readable values into a format acceptable for use with the data bus 104, as well as corresponding decoding operations from the data-bus format. The communication sub-model 154 may further model the packing and unpacking functions in the (simulated) ECUs 103, as discussed above. Further still, the communication sub-model 154 may reflect specifics of the non-perfect connection between the cooperating ECUs 103 that the data bus 104 provides, with deterministic and non-deterministic delays, packet losses etc. It is noted that the communication sub-model 154 may support the use of communication databases designed to mitigate transcript errors, including manual errors.[P-34]
In some embodiments, the unified simulation model 150 further includes at least one further sub-model 156. The further sub-model(s) 156 may represent a safety supervisor, a base vehicle control algorithm and/or another vehicle subsystem. It is understood that a safety supervisor may have authority to override one or more ECUs 103 in the vehicle, and force actuators 102 to take a particular, safety-oriented action. A base vehicle control algorithm may include algorithms that control vehicle motion management from a higher level. The (motion) requests of a base vehicle control algorithm can then be handed over to actuator controllers for execution. The base vehicle control logic can also represent state machines and switches, i.e. in a non-continuous control mode. The further sub-model(s) 156 maybe formatted like the other models and included in the single executable.[P-38]
Here, we see Nilsson illustrating the processor is configured to implement a virtual motion implementation logic configured to mimic at least one communication signal among a controller area network (CAN) signal and a CAN flexible data-rate (CAN FD) signal and change a signaling value of the mimicked communication signal; A base vehicle control algorithm may include algorithms that control vehicle motion management from a higher level. The (motion) requests of a base vehicle control algorithm can then be handed over to actuator controllers for execution. The communication sub-model 154 captures the use of a single message and/or signal definition. In the example of a CAN or CAN-FD bus, such definitions maybe deposited in a database file (DBC) file, which specifies how to encode physical or human-readable values into a format acceptable for use with the data bus 104, as well as corresponding decoding operations from the data-bus format. The communication sub-model 154 may further model the packing and unpacking functions in the (simulated) ECUs 103.
Thereby it is obvious to one of ordinary skill in the art during the time of the filing date of the said invention to combine Nilsson’s teaching with Babayan’s teaching in order to more effectively enable the communication and more accurate imitation of a vehicular environment.
In regards to claim 4, Babayan modified teaches the virtual motion implementation logic is configured to transmit a signaling transmission suspension request signal to the at least one controller to suspend transmission of an actual signal corresponding to the mimicked communication signal (Paragraphs 12, 40, 44,Babayan)
In an embodiment, the mocked behavior is based on log data generated during communication between the update controller and the external software service in the live computing environment. The log data includes a request parameter associated with the update controller, a response payload provided by the external software service, and a response time indicating a duration of time until the external software service responded to the update controller.[P-12]
The update controller may be part of an ecosystem of a number of disparate systems that work together in a coordinated fashion in order to fulfill requests for OTA software updates, across a variety of use cases having varying levels of complexity. This may create a challenge in testing these use cases from end to end. For example, it may be helpful to test software changes made to the update controller end to end before updating the live environment where actual consumer systems and vehicles could be adversely affected (e.g., by latency, etc.) due to software issues.[P-40]
The technology of the present disclosure can provide a number of technical effects and computing improvements through its ability to mock external dependencies with contrived behaviors. For instance, instead of deploying individual mocked instances of all the external dependencies, a single proxy may be used by the update controller within the virtual environment for multiple (e.g., all) external dependencies. From the update controller's perspective, it may only be aware that it is calling a particular service with a given request, and expecting some response in a given schema. For example, the update controller (e.g., its simulated instance) may not know how the call is routed to a particular service or who is actually responding. In the virtual environment, the integration tests can set up the mocks necessary to exercise a given set of test cases. The integration tests can define the behavior of the external service using a full-featured mocking framework. This approach can keep the definition of expected behavior of the external service localized to the tests that are triggering it.[P-44]
By teaching the mimicking behaviour of the virtual environment, wherein communication between the update controller and the external software service in the real computing environment, includes a request parameter associated with the update controller, and a response payload provided by the external software service. One of ordinary skill in art may request the updating of the OTA software as one request parameter, another parameter requested can be request signal to suspend transmission of an actual signal corresponding to the mimicked communication signal (as it relates to OTA updates)in order to enable effective procedure for the OTA updating protocol, including accounting for errors, delays, troubleshooting, and effectively concluding the said protocol.
In regards to claim 5, Babayan modified teaches the at least one controller is configured to suspend transmission of the actual signal upon receiving the signaling transmission suspension request signal (Paragraphs 12, 40, 44 Babayan)
In an embodiment, the mocked behavior is based on log data generated during communication between the update controller and the external software service in the live computing environment. The log data includes a request parameter associated with the update controller, a response payload provided by the external software service, and a response time indicating a duration of time until the external software service responded to the update controller.[P-12]
The update controller may be part of an ecosystem of a number of disparate systems that work together in a coordinated fashion in order to fulfill requests for OTA software updates, across a variety of use cases having varying levels of complexity. This may create a challenge in testing these use cases from end to end. For example, it may be helpful to test software changes made to the update controller end to end before updating the live environment where actual consumer systems and vehicles could be adversely affected (e.g., by latency, etc.) due to software issues [P-40]
The technology of the present disclosure can provide a number of technical effects and computing improvements through its ability to mock external dependencies with contrived behaviors. For instance, instead of deploying individual mocked instances of all the external dependencies, a single proxy may be used by the update controller within the virtual environment for multiple (e.g., all) external dependencies. From the update controller's perspective, it may only be aware that it is calling a particular service with a given request, and expecting some response in a given schema. For example, the update controller (e.g., its simulated instance) may not know how the call is routed to a particular service or who is actually responding. In the virtual environment, the integration tests can set up the mocks necessary to exercise a given set of test cases. The integration tests can define the behavior of the external service using a full-featured mocking framework. This approach can keep the definition of expected behavior of the external service localized to the tests that are triggering it.[P-44]
By teaching the mimicking behaviour of the virtual environment, wherein communication between the update controller and the external software service in the real computing environment, includes a request parameter associated with the update controller, and a response payload provided by the external software service. One of ordinary skill in art may request the updating of the OTA software as one request parameter, another parameter requested can be request signal to suspend transmission of an actual signal corresponding to the mimicked communication signal (and in response suspend transmission of the actual signal) in order to enable effective procedure for the OTA updating protocol, including accounting for errors, delays, troubleshooting, and effectively concluding the said protocol.
In regards to claim 6, Babayan modified teaches the virtual motion implementation logic is configured to: generate an output request signal based on the mimicked communication signal and an input signal of another controller; and transmit the output request signal to an output processor to control display of a motion result of the virtual mode.(Paragraphs 87, 91, 174 , Babayan)
The vehicle 105 may include one or more human-machine interfaces (HMIs) 340. The human-machine interfaces 340 may include a display device, as described herein. The display device (e.g., touchscreen) may be viewable by a user of the vehicle 105 (e.g., user 120) that is located in the front of the vehicle 105 (e.g., driver's seat, front passenger seat). Additionally, or alternatively, a display device (e.g., rear unit) may be viewable by a user that is located in the rear of the vehicle 105 (e.g., back passenger seats). The human-machine interfaces 340 may present content 335 via a user interface for display to a user 120..[P-87]
The controllers 355A-C may be configured to send signals to another onboard system. The signals may encode data associated with a respective vehicle function. The encoded data may indicate, for example, a function setting, timing, etc. In an example, such data may be used to generate content for presentation via the display device 345 (e.g., showing a current setting). Additionally, or alternatively, such data can be included in vehicle data 335 and transmitted to the computing platform 110.[P-91]
The computing system 6005 may also include one or more user input components 6040 that receives user input. For example, the user input component 6040 may be a touch-sensitive component (e.g., a touch-sensitive display screen or a touch pad) that is sensitive to the touch of a user input object (e.g., a finger or a stylus). The touch-sensitive component may serve to implement a virtual keyboard. Other example user input components include a microphone, a traditional keyboard, cursor-device, joystick, or other devices by which a user may provide user input..[P-174]
In regards to claim 7, Babayan modified teaches the virtual motion implementation logic is configured to receive a feedback signal (SF) indicating a motion result of the virtual mode from the output processor.(Paragraphs 81, 90, Babayan)
The vehicle 105 may include one or more sensor systems 305. A sensor system may include or otherwise be in communication with a sensor of the vehicle 105 and a module for processing sensor data 310 associated with the sensor configured to acquire the sensor data 305. This may include sensor data 310 associated with the surrounding environment of the vehicle 105, sensor data associated with the interior of the vehicle 105, or sensor data associated with a particular vehicle function. The sensor data 310 may be indicative of conditions observed in the interior of the vehicle, exterior of the vehicle, or in the surrounding environment. For instance, the sensor data 305 may include image data, inside/outside temperature data, weather data, data indicative of a position of a user/object within the vehicle 105, weight data, motion/gesture data, audio data, or other types of data. The sensors may include one or more: cameras (e.g., visible spectrum cameras, infrared cameras), motion sensors, audio sensors (e.g., microphones), weight sensors (e.g., for a vehicle a seat), temperature sensors, humidity sensors, Light Detection and Ranging (LIDAR) systems, Radio Detection and Ranging (RADAR) systems, or other types of sensors. The vehicle 105 may include other sensors configured to acquire data associated with the vehicle 105. For example, the vehicle 105 may include inertial measurement units, wheel odometry devices, or other sensors.[P-81]
In an embodiment, a controller 355A-C for a particular vehicle function may include or otherwise be associated with a sensor that captures data indicative of the vehicle function being turned on or off, a setting of the vehicle function, etc. For example, a sensor may be an audio sensor or a motion sensor. The audio sensor may be a microphone configured to capture audio input from the user 120. For example, the user 120 may provide a voice command to activate the radio function of the vehicle 105 and request a particular station. The motion sensor may be a visual sensor (e.g., camera), infrared, RADAR, etc. configured to capture a gesture input from the user 120. For example, the user 120 may provide a hand gesture motion to adjust a temperature function of the vehicle 105 to lower the temperature of the vehicle interior.[P-90]
In regards to claim 10, Babayan fails to teach checking, by the processor, a pop-up for checking whether a precondition related to a safe state of a user is satisfied or an input for changing the precondition, to operate the updated function in the virtual mode.
Neillson on the other hand teaches checking, by the processor, a pop-up for checking whether a precondition related to a safe state of a user is satisfied or an input for changing the precondition, to operate the updated function in the virtual mode (Paragraph 38)
In some embodiments, the unified simulation model 150 further includes at least one further sub-model 156. The further sub-model(s) 156 may represent a safety supervisor, a base vehicle control algorithm and/or another vehicle subsystem. It is understood that a safety supervisor may have authority to override one or more ECUs 103 in the vehicle, and force actuators 102 to take a particular, safety-oriented action. A base vehicle control algorithm may include algorithms that control vehicle motion management from a higher level. The (motion) requests of a base vehicle control algorithm can then be handed over to actuator controllers for execution. The base vehicle control logic can also represent state machines and switches, i.e. in a non-continuous control mode. The further sub-model(s) 156 maybe formatted like the other models and included in the single executable.[P-38]
Here, we see Neilsson teach teaches checking, by the processor, a pop-up for checking whether a precondition related to a safe state of a user is satisfied or an input for changing the precondition by way of a safety supervisor module an input for changing the precondition, to operate the updated function in the virtual mode
Thereby it is obvious to one of ordinary skill in the art during the time of the filing date of the said invention to combine Nilsson’s teaching with Babayan’s teaching in order to more effectively enable a safe state configuration may be set with the vehicle.
In regards to claim 13, Babayan fails to teach mimicking the communication signal includes: mimicking, by the processor, at least one communication signal among a controller area network (CAN) signal and a CAN flexible data-rate (CAN FD) signal; and changing, by the processor, a signaling value of the mimicked communication signal.
Nilsson the other hand teaches mimicking the communication signal includes: mimicking, by the processor, at least one communication signal among a controller area network (CAN) signal and a CAN flexible data-rate (CAN FD) signal; and changing, by the processor, a signaling value of the mimicked communication signal(Paragraphs 25, 29, 34, 38)
The data bus 104 can be configured to use any protocol carried over ethernet or similar network technologies. For example, the data bus 104 may act as - or include - a Controller Area Network (CAN) interface, a CANopen interface, a CAN-FD interface, a FlexRay.sup.™ interface, a Local Interconnect Network (LIN) interface, a Data Distribution Service (DDS) interface, or a combination of one or more of these interfaces. The data bus 104 may further support AUTOSAR.sup.™, Protocol Buffers (Protobuf.sup.™), Nanoph, HTTP, and/or restbus, although some of these may not necessarily be regarded as complete data bus interfaces.[P-25]
To provide the platform-independent unified simulation model 150 (figure 1B), the method begins with a step of providing 212.1 a vehicle dynamic model 151 configured to simulate a time evolution of at least one motion state of the vehicle (see above). As used herein, the vehicle dynamic model is a model of the dynamics of the base vehicle, which could include motion in three dimensions. The dynamics include the motion and generated forces in the vehicle's chassis and its tires. The vehicle's dynamics (forces, torques, rotations, accelerations etc.) can be modeled based on first-principle physics equations. The fidelity of the vehicle dynamic model 151 depends on the use case at hand.[P-29]
In a next step 212.4, a communication sub-model 154 representing the data bus 104 is provided. It is recalled that a main functionality of the data bus 104 is to deliver bus messages 110 between pairs of ECUs 103. The communication sub-model 154 captures the use of a single message and/or signal definition. In the example of a CAN or CAN-FD bus, such definitions maybe deposited in a database file (DBC) file, which specifies how to encode physical or human-readable values into a format acceptable for use with the data bus 104, as well as corresponding decoding operations from the data-bus format. The communication sub-model 154 may further model the packing and unpacking functions in the (simulated) ECUs 103, as discussed above. Further still, the communication sub-model 154 may reflect specifics of the non-perfect connection between the cooperating ECUs 103 that the data bus 104 provides, with deterministic and non-deterministic delays, packet losses etc. It is noted that the communication sub-model 154 may support the use of communication databases designed to mitigate transcript errors, including manual errors.[P-34]
In some embodiments, the unified simulation model 150 further includes at least one further sub-model 156. The further sub-model(s) 156 may represent a safety supervisor, a base vehicle control algorithm and/or another vehicle subsystem. It is understood that a safety supervisor may have authority to override one or more ECUs 103 in the vehicle, and force actuators 102 to take a particular, safety-oriented action. A base vehicle control algorithm may include algorithms that control vehicle motion management from a higher level. The (motion) requests of a base vehicle control algorithm can then be handed over to actuator controllers for execution. The base vehicle control logic can also represent state machines and switches, i.e. in a non-continuous control mode. The further sub-model(s) 156 maybe formatted like the other models and included in the single executable.[P-38]
Here, we see Nilsson illustrating the processor is configured to implement a virtual motion implementation logic configured to mimic at least one communication signal among a controller area network (CAN) signal and a CAN flexible data-rate (CAN FD) signal and change a signaling value of the mimicked communication signal; A base vehicle control algorithm may include algorithms that control vehicle motion management from a higher level. The (motion) requests of a base vehicle control algorithm can then be handed over to actuator controllers for execution. The communication sub-model 154 captures the use of a single message and/or signal definition. In the example of a CAN or CAN-FD bus, such definitions maybe deposited in a database file (DBC) file, which specifies how to encode physical or human-readable values into a format acceptable for use with the data bus 104, as well as corresponding decoding operations from the data-bus format. The communication sub-model 154 may further model the packing and unpacking functions in the (simulated) ECUs 103.
Thereby it is obvious to one of ordinary skill in the art during the time of the filing date of the said invention to combine Nilsson’s teaching with Babayan’s teaching in order to more effectively enable the communication and more accurate imitation of a vehicular environment.
In regards to claim 19, Babayan fails to teach checking, by the processor, a pop-up for checking whether a precondition related to a safe state of a user is satisfied or an input for changing the precondition, to operate the updated function in the virtual mode.
Neillson on the other hand teaches checking, by the processor, a pop-up for checking whether a precondition related to a safe state of a user is satisfied or an input for changing the precondition, to operate the updated function in the virtual mode (Paragraph 38)
In some embodiments, the unified simulation model 150 further includes at least one further sub-model 156. The further sub-model(s) 156 may represent a safety supervisor, a base vehicle control algorithm and/or another vehicle subsystem. It is understood that a safety supervisor may have authority to override one or more ECUs 103 in the vehicle, and force actuators 102 to take a particular, safety-oriented action. A base vehicle control algorithm may include algorithms that control vehicle motion management from a higher level. The (motion) requests of a base vehicle control algorithm can then be handed over to actuator controllers for execution. The base vehicle control logic can also represent state machines and switches, i.e. in a non-continuous control mode. The further sub-model(s) 156 maybe formatted like the other models and included in the single executable.[P-38]
Here, we see Neilsson teach teaches checking, by the processor, a pop-up for checking whether a precondition related to a safe state of a user is satisfied or an input for changing the precondition by way of a safety supervisor module an input for changing the precondition, to operate the updated function in the virtual mode
Thereby it is obvious to one of ordinary skill in the art during the time of the filing date of the said invention to combine Nilsson’s teaching with Babayan’s teaching in order to more effectively enable a safe state configuration may be set with the vehicle.
Claim(s) 11 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Babayan et al. (US 20240394036 A1) in view of Jung (KR 20210043153 A).
In regards to claim 11, Babayan fails to teach the processor is configured to determine whether the updated function is an OTA software update for improving marketability of a vehicle, and wherein the OTA software update includes at least one of a vehicle function, a user setting mode (USM) setting, or a cluster navigation design setting.
Jung on the other hand teaches the processor is configured to determine whether the updated function is an OTA software update for improving marketability of a vehicle, and wherein the OTA software update includes at least one of a vehicle function, a user setting mode (USM) setting, or a cluster navigation design setting (Page 1, Paragraph 2; Page 2, Paragraph 1)
In general, software installed in a vehicle can be upgraded to wireless communication using wireless air data through OTA (Over The Air). The OTA update of such a vehicle can update software necessary for vehicle operation by performing wireless transmission and update to a customer vehicle through a server in order to improve the vehicle's additional marketability and efficiently respond when a quality problem occurs.[Pg 1, P-2]
In this, conventional OTA update method, the management controller 200 receives the firmware from the OTA server 100 through the communication module 210 for the controller wireless update, and the execution controller according to the OTA management logic based on vehicle state information ( 300) can be sent to the firmware. The performance controller 300 may perform an update based on the received firmware. In this case, the vehicle status information may include battery status information, driving status information, performance controller operation status information, and power status information.[Pg 2, P-1]
It would therefore be obvious to one of ordinary skill in the art during the time of the filing date to combine Jung’s teaching with Babayan’s teaching in order to more effectively update a vehicles firmware and effectively improve the vehicles function(s).
In regards to claim 20, Babayan fails to teach determining, by the processor, whether the updated function is an OTA software update for improving marketability of a vehicle, wherein the OTA software update includes at least one of a vehicle function, a user setting mode (USM) setting, or a cluster navigation design setting.
Jung on the other hand teaches the processor is configured to determine whether the updated function is an OTA software update for improving marketability of a vehicle, and wherein the OTA software update includes at least one of a vehicle function, a user setting mode (USM) setting, or a cluster navigation design setting (Page 1, Paragraph 2; Page 2, Paragraph 1)
In general, software installed in a vehicle can be upgraded to wireless communication using wireless air data through OTA (Over The Air). The OTA update of such a vehicle can update software necessary for vehicle operation by performing wireless transmission and update to a customer vehicle through a server in order to improve the vehicle's additional marketability and efficiently respond when a quality problem occurs.[Pg 1, P-2]
In this, conventional OTA update method, the management controller 200 receives the firmware from the OTA server 100 through the communication module 210 for the controller wireless update, and the execution controller according to the OTA management logic based on vehicle state information ( 300) can be sent to the firmware. The performance controller 300 may perform an update based on the received firmware. In this case, the vehicle status information may include battery status information, driving status information, performance controller operation status information, and power status information.[Pg 2, P-1]
It would therefore be obvious to one of ordinary skill in the art during the time of the filing date to combine Jung’s teaching with Babayan’s teaching in order to more effectively update a vehicles firmware and effectively improve the vehicles function(s).
Claim(s) 15-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Babayan et al. (US 20240394036 A1).
In regards to claim 15, Babayan fails to explicitly teach transmitting, by the processor, a signaling transmission suspension request signal to suspend transmission of an actual signal corresponding to the mimicked communication signal.
However, Babayan teaches
In an embodiment, the mocked behavior is based on log data generated during communication between the update controller and the external software service in the live computing environment. The log data includes a request parameter associated with the update controller, a response payload provided by the external software service, and a response time indicating a duration of time until the external software service responded to the update controller.[P-12]
The update controller may be part of an ecosystem of a number of disparate systems that work together in a coordinated fashion in order to fulfill requests for OTA software updates, across a variety of use cases having varying levels of complexity. This may create a challenge in testing these use cases from end to end. For example, it may be helpful to test software changes made to the update controller end to end before updating the live environment where actual consumer systems and vehicles could be adversely affected (e.g., by latency, etc.) due to software issues.[P-40]
The technology of the present disclosure can provide a number of technical effects and computing improvements through its ability to mock external dependencies with contrived behaviors. For instance, instead of deploying individual mocked instances of all the external dependencies, a single proxy may be used by the update controller within the virtual environment for multiple (e.g., all) external dependencies. From the update controller's perspective, it may only be aware that it is calling a particular service with a given request, and expecting some response in a given schema. For example, the update controller (e.g., its simulated instance) may not know how the call is routed to a particular service or who is actually responding. In the virtual environment, the integration tests can set up the mocks necessary to exercise a given set of test cases. The integration tests can define the behavior of the external service using a full-featured mocking framework. This approach can keep the definition of expected behavior of the external service localized to the tests that are triggering it.[P-44]
By teaching the mimicking behaviour of the virtual environment, wherein communication between the update controller and the external software service in the real computing environment, includes a request parameter associated with the update controller, and a response payload provided by the external software service. One of ordinary skill in art may request the updating of the OTA software as one request parameter, another parameter requested can be request signal to suspend transmission of an actual signal corresponding to the mimicked communication signal (as it relates to OTA updates)in order to enable effective procedure for the OTA updating protocol, including accounting for errors, delays, troubleshooting, and effectively concluding the said protocol.
In regards to claim 16, Babayan teaches generating, by the processor, an output request signal based on the mimicked communication signal and an input signal of another controller; and displaying, by the processor, a motion result of the virtual mode through the output request signal.(Paragraphs 87, 91,174)
The vehicle 105 may include one or more human-machine interfaces (HMIs) 340. The human-machine interfaces 340 may include a display device, as described herein. The display device (e.g., touchscreen) may be viewable by a user of the vehicle 105 (e.g., user 120) that is located in the front of the vehicle 105 (e.g., driver's seat, front passenger seat). Additionally, or alternatively, a display device (e.g., rear unit) may be viewable by a user that is located in the rear of the vehicle 105 (e.g., back passenger seats). The human-machine interfaces 340 may present content 335 via a user interface for display to a user 120.[P-87]
The controllers 355A-C may be configured to send signals to another onboard system. The signals may encode data associated with a respective vehicle function. The encoded data may indicate, for example, a function setting, timing, etc. In an example, such data may be used to generate content for presentation via the display device 345 (e.g., showing a current setting). Additionally, or alternatively, such data can be included in vehicle data 335 and transmitted to the computing platform 110.[P-91]
The computing system 6005 may also include one or more user input components 6040 that receives user input. For example, the user input component 6040 may be a touch-sensitive component (e.g., a touch-sensitive display screen or a touch pad) that is sensitive to the touch of a user input object (e.g., a finger or a stylus). The touch-sensitive component may serve to implement a virtual keyboard. Other example user input components include a microphone, a traditional keyboard, cursor-device, joystick, or other devices by which a user may provide user input..[P-174]
In regards to claim 17, Babayan teaches receiving, by the processor, a feedback signal on the motion result of the virtual mode.(Paragraphs 81, 90)
The vehicle 105 may include one or more sensor systems 305. A sensor system may include or otherwise be in communication with a sensor of the vehicle 105 and a module for processing sensor data 310 associated with the sensor configured to acquire the sensor data 305. This may include sensor data 310 associated with the surrounding environment of the vehicle 105, sensor data associated with the interior of the vehicle 105, or sensor data associated with a particular vehicle function. The sensor data 310 may be indicative of conditions observed in the interior of the vehicle, exterior of the vehicle, or in the surrounding environment. For instance, the sensor data 305 may include image data, inside/outside temperature data, weather data, data indicative of a position of a user/object within the vehicle 105, weight data, motion/gesture data, audio data, or other types of data. The sensors may include one or more: cameras (e.g., visible spectrum cameras, infrared cameras), motion sensors, audio sensors (e.g., microphones), weight sensors (e.g., for a vehicle a seat), temperature sensors, humidity sensors, Light Detection and Ranging (LIDAR) systems, Radio Detection and Ranging (RADAR) systems, or other types of sensors. The vehicle 105 may include other sensors configured to acquire data associated with the vehicle 105. For example, the vehicle 105 may include inertial measurement units, wheel odometry devices, or other sensors.[P-81]
In an embodiment, a controller 355A-C for a particular vehicle function may include or otherwise be associated with a sensor that captures data indicative of the vehicle function being turned on or off, a setting of the vehicle function, etc. For example, a sensor may be an audio sensor or a motion sensor. The audio sensor may be a microphone configured to capture audio input from the user 120. For example, the user 120 may provide a voice command to activate the radio function of the vehicle 105 and request a particular station. The motion sensor may be a visual sensor (e.g., camera), infrared, RADAR, etc. configured to capture a gesture input from the user 120. For example, the user 120 may provide a hand gesture motion to adjust a temperature function of the vehicle 105 to lower the temperature of the vehicle interior. [P-90]
Allowable Subject Matter
Claims 3, 8, 14 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claim 3, reads as, “The vehicle control apparatus of claim 1, wherein the processor is configured to set a signaling value of the mimicked communication signal to a value required to operate in the virtual mode, and wherein the value required to operate in the virtual mode is set to a value that adaptively varies based on the updated function.”
During the time of the filing date there is no prior art that teaches setting a signaling value of the mimicked communication signal to a value required to operate in the virtual mode, such that the value required to operate in the virtual mode is set to a value that adaptively varies based on the updated function. As a result, the examiner acknowledges the limitations as novel.
Claim 8, reads as, “The vehicle control apparatus of claim 2, further comprising a communication gateway controller configured to perform data transmission and a routing motion of a control period and including the at least one controller, wherein the routing motion includes a protocol conversion motion for transmitting data of a specific channel to another channel..”
During the time of the filing date there is no prior art that teaches a communication gateway controller configured to perform data transmission and a routing motion of a control period and including the at least one controller, wherein the routing motion includes a protocol conversion motion for transmitting data of a specific channel to another channel. As a result, the examiner acknowledges the limitations as novel.
Claim 14, reads as, “The vehicle control apparatus of claim 1, wherein the processor is configured to set a signaling value of the mimicked communication signal to a value required to operate in the virtual mode, and wherein the value required to operate in the virtual mode is set to a value that adaptively varies based on the updated function.”
During the time of the filing date there is no prior art that teaches setting a signaling value of the mimicked communication signal to a value required to operate in the virtual mode, such that the value required to operate in the virtual mode is set to a value that adaptively varies based on the updated function. As a result, the examiner acknowledges the limitations as novel.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANTHONY D AFRIFA-KYEI whose telephone number is (571)270-7826. The examiner can normally be reached Monday-Friday 10am-7pm.
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, BRIAN ZIMMERMAN can be reached at 571-272-3059. 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.
/ANTHONY D AFRIFA-KYEI/Examiner, Art Unit 2686
/BRIAN A ZIMMERMAN/Supervisory Patent Examiner, Art Unit 2686
Prosecution Insights