DETAILED ACTION
Response to Amendment
This Final Office Action is in response to the applicant’s remarks and arguments filed on November 19, 2025.
Claims 1-2, 4, 6-8, 11, 13-14, 17 and 20 were amended.
Claims 1-20 remain pending in the application. Claims 1-20 are being considered on the merits.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 09/16/2025 and 12/10/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments
Applicant argues that:
“a second version of an operating system, wherein the second version of the operating system is different from a first version of an operating system,… to enable the second version of the operating system to process the information relating to the application executing in the application layer exposed by the first version of the operating system." The cited portions of the applied references fail to disclose or suggest at least this combination of features.
Examiner respectfully disagree and submit that:
Applicant’s arguments with respect to the newly added limitations have been considered but are moot because the arguments do not apply to the newly cited reference Blaser et al. (US 8,843,903) being used in the current rejection.
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
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) 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over IM , Jin Woo et al. (WO2020/059957, published in March 26, 2020, examiner relies on US PUB. IM et al. US 2020/0290530 as the official translation document of the WO2020/059957, IM, hereinafter) in view of Srivastava et al. (US 2016/0306966, Srivastava hereinafter) and Blaser et al. (US 8,843,903, Blaser hereinafter).
Claim 1, IM teaches a method comprising:
executing, by one or more processors (e.g., “processor 111”, FIG. 2) of a cartridge in a vehicle (e.g., see FIG. 2 and 8 , para [[0041] Referring to FIG. 2, the hardware 110 may include an exemplary architectural configuration of the hardware 110 of the vehicle software control device 10 according to the embodiment. Generally, the hardware 110 may include a processor 111, a display unit 112, a storage unit 113, a memory unit 114, a control unit 115, and an input-and-output (I/O) device 116.
[0042] The processor 111 may be a vehicle infotainment-based processor 111.), a second version of an operating system (e.g., [0019] “operating systems”, “ versions of the operating systems “, para [0073] the vehicle software control device 10 according to the embodiment may access each hardware component even when various chip manufacturers provide a hardware dependent library only in a predetermined operating system version, and thus improved compatibility may be provided. That is, the vehicle software control device 10 may be independent of a type or version of the operating system.
Thus, the one of the “versions of the operating systems” include a second version); and
receiving a stream via an interface (e.g., see FIG. 9, para [0107] “ the user receives an input for voice control through the plurality of I/O systems 2100a, 2100b, and 2100n by executing the first application, a voice output corresponding to the input may be provided to the user”. “ the voice output through the application may be streamed to a speaker among the vehicle components or transmitted to an interface selected by the user”. Thus, the “an input for voice” coupled with “voice output “, “ streamed” represent the stream) and from an application layer exposed by a first version of the operating system executing on one or more processors of a head unit of a vehicule, information relating to an application executing in the application layer exposed by the first version of the operating system (e.g., “170 second application”, “150 first application”, FIG. 1, see para [0077] Further, the first calling unit 144 and the second calling unit 131 may include a hardware abstraction layer (HAL). “, “ a plurality of library modules.” and “Linux”, “ operating system of the vehicle infotainment. For example, the operating system may be any one of QNX, GENIVI, and Automotive Grade Linux (AGL)” in para 49 and 50.
Also, see FIG. 6, para [0078]-[0079] “ the kernel 120 may initiate an operation of the first operating system (e.g., Linux) “ a system file L1 in the first connecting unit 140 may include the same information as that of the system file in the kernel 120”, “a library file L1 in the first connecting unit 140 may include a library file L1a which is applicable to the second operating system and a library file L1b which is the same as a library file L2 in the kernel 120”
Thus, “ application”, “150 first application “ coupled with “abstraction layer (HAL” , “a plurality of library modules “ include an application layer, “Linux” include a first version ), wherein the information relating to the application executing in the application layer exposed by the first version of the operating system comprises a first function call that conforms with the first version of the operating system ,the cartridge being communicatively coupled to the head unit (e.g., the “driver” to “perform a call “ coupled with “call signal”, “function as that of the open device driver” in para 11 and 75 include a first function call)
wherein the interface transforms the first function call that conforms operating system with the second version of the (e.g., para [0088] The converted library may be converted into a signal suitable for the operating system of the vehicle software control device in the system library and transmitted to the kernel. The kernel may control the hardware in response to the signal.) (e.g., see Figs 4 and 5 para [0060] Referring to FIGS. 4 and 5, the first connecting unit 140 of the vehicle software control device 10 according to the embodiment may include a first application library 141, a conversion unit 142, a transmission unit 143, and a first calling unit 144.
[0061] The first application library 141 may include a library necessary for execution of the first application 150. When the first application 150 is executed, the necessary library may be called. For example, the first application library 141 may implement common functions such as I/O and string manipulation (e.g., “C library”), graphics library, database library, communication library, and other libraries for the executed first application 150. The first application library 141 may provide the called library to the conversion unit 142.
[ 0062] The conversion unit 142 may receive the called library and convert the received library so as to interface with the system library 130.
[0063] For example, the conversion unit 142 may convert the called library on the basis of the system library 130 of the vehicle software control device 10. The operating system of the vehicle software control device 10 and the operating system in which the first application 150 is executable may be Linux-based operating systems).
However, IM does not explicitly teach wherein the second version of the operating system is different from a first version of an operating system, transforms the first function call to a second function call, and enables the second version of the operating system to process the information relating to the application executing in the application layer exposed by the first version of the operating system.
Srivastava teaches an interface transforms a first function call to a second function call (e.g., see FIG. 11, [0098] For example, the infotainment application may request to send information on a central bus (1110, 1120). This request is converted by the infotainment application into a system call that is made to the OS (1200). The OS makes a driver call to the associated driver stack based upon the system call (1210). The paravirtualized driver front-end intercepts this driver call, converts it into a hyper call, and passes it to the hypervisor (1220). The hypervisor passes the hyper call to the policy module in a separate virtualized environment from the OS (and infotainment application) (1230).
see FIG. 3, para [0081] … a driver call is received by the system from either an application program through the operating system of the host processor or from the operating system of the host processor directly 301”, “The driver call is translated into a hyper call by the hypervisor or a front-end paravirtualized driver 303. The hyper call is then analyzed in a policy module, which resides in a virtualized environment 304.
Thus, the “driver call “ represent the first function call , the “hyper call” represents the second function call, “the “driver call, converts it into a hyper call” , therefore an interface transforms a first function call to a second function call ). Thus, 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 method of IM by adopting the teachings of Srivastava to provide “ a hardware barrier that prevents the untrusted operating system and the untrusted driver from accessing code/data of the policy module (see Srivastava, para 75) .
Blaser teaches wherein the second version of the operating system is different from a first version of an operating system (e.g., col. 17, lines 65-67 and col. 18, lines 1-3, “an application layer of version 1.0 of an application carries a priority of 50.0, an application layer containing version 2.0 of the application might be prioritized anywhere between 30.000 . . . 1 and 49.999 . . “ and ) , transforms the first function call to a second function call, and enables the second version of the operating system to process the information relating to the application executing in the application layer exposed by the first version of the operating system ( e.g., See FIG. 3, col. 24, lines 24-49, “a Microsoft Windows 2000, ME, XP or the like. Adaptations can be made for other versions of those operating systems, or to entirely different operating systems” , “Virtual Software Packages (VSPs), , “the operating systems 314 noted above, which includes a registry subsystem 316 and a file system subsystem 318 for accessing and handling files. Installed to the operating system is an FSL system driver 312, which in the exemplary implementation is named "FSLX.SYS" and may reside in the system32/drivers directory of the Windows directory. That driver includes functions to replace the ordinary file system calls such as open, read, write, etc., other functions needed to manage layers in an enabled state, and functions for determining priorities.“, “makes calls to the FSL driver 312 through the redirected file system calls”, “applications 304 can access the layers the same way through FSL driver 312” and “a newer version of an application layer may be assigned slightly higher priority than and older version, ensuring that the new version is seen over the old should both be enabled in the layered system.”, “Versions of applications may also be the basis of a layer” in col. 29, lines 27-30.
Thus, the “That driver includes functions to replace the ordinary file system calls”, “makes calls to the FSL driver 312 through the redirected file system calls” . Therefore , transforms the first function call to a second function call ). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the method of IM and Srivastava by adopting the teachings of Blaser, to provide “ improved treatment for application updates made through a standard installation process, such as the Microsoft Installer (MSI.) (see Blaser, col. 30, lines 21-22) .
As to Claim 2 , IM teaches presenting, by the one or more processors of the cartridge, the interface (e.g., para [0060] Referring to FIGS. 4 and 5, the first connecting unit 140 of the vehicle software control device 10 according to the embodiment may include a first application library 141, a conversion unit 142, a transmission unit 143, and a first calling unit 144).
As to Claim 3, IM teaches further generating, by an application executing in an application layer exposed by the second version of the operating system, a third function call that conforms with the second version of the operating system in response to the first function call (e.g., para [0048] Referring to FIG. 3, the kernel 120 may be connected to the hardware 110 to provide control signals to the hardware 110. The kernel 120 is a region for managing and controlling most basic functions of the devices which provide functions such as interrupt processing, process management, memory management, file system management, and programming interface. Generally, the kernel 120 may be loaded into an inaccessible memory and may be regarded as a type of application program interface (API) for controlling hardware. The hardware 110 may perform functions in response to the control signals received from the kernel 120. [0061] The first application library 141 may include a library necessary for execution of the first application 150. When the first application 150 is executed, the necessary library may be called. For example, the first application library 141 may implement common functions such as I/O and string manipulation (e.g., “C library”), graphics library, database library, communication library, and other libraries for the executed first application 150. The first application library 141 may provide the called library to the conversion unit 142.. Thus, another one of the “functions” include a third function call ) ; receiving, at the interface from the second version of the operating system, the third function call; transforming, by the interface, the third function call (e.g., para 0062] The conversion unit 142 may receive the called library and convert the received library so as to interface with the system library 130. [0063] For example, the conversion unit 142 may convert the called library on the basis of the system library 130 of the vehicle software control device 10. The operating system of the vehicle software control device 10 and the operating system in which the first application 150 is executable may be Linux-based operating systems.) , a fourth function call (e.g., another one of the “functions” include a fourth function call ) that conforms with the first version of the operating system; and transmitting, by the interface to the first version of the operating system, the fourth function call (e.g., see FIG. 4, para [0065] As described above, the Linux-based kernel may be designed with the processor 111 different from the Android-based kernel, but the Linux-based kernel may be the same as the Android kernel in that the kernel is designed based on Linux. Accordingly, the conversion unit 142 may convert the first application 150 executed on the Android-based kernel into the system library 130 of the vehicle software control device 10 such that the first application 150 executed on the Android-based kernel acts on the hardware 110 including a touch screen, a mobile connection (Global System for Mobile Communications (GSM)/Enhanced Data rates for GSM Evolution (EDGE), code division multiple access (CDMA), Wi-Fi, etc.) module, a battery management module, a GPS module, an accelerometer, and a camera module. [0066] In addition, the library converted by the conversion unit 142 may be transmitted to the hardware 110 through the system library 130 and the kernel 120 as a control request. The hardware 110 may be controlled in response to the control request. [0067] The kernel 120 may receive a control result from the hardware 110 and transmit the control result to the system library 130. A library for the control result transmitted to the system library 130 may be transmitted to the transmission unit 143. The transmission unit 143 may transmit the library for the control result to the conversion unit 142, and the conversion unit 142 may match the transmitted library for the control result with the first application library 141 and convert the library. That is, the library for the control result may be converted so as to match the interface of the first application library 141, and the control result for the hardware 110 may be transmitted to the first application 150 and provided to the user on the display.
[0068] The transmission unit 143 may transmit the converted library to the system library 130. Further, the transmission unit 143 may receive the library for the control result as described above. However, IM does not teach transforming to the fourth function call. Srivastava teaches an interface transforming to the fourth function call function call (e.g., see FIG. 11, para [0097] FIG. 11 shows a schematic of a paravirtualized security threat protection system, in accordance with an embodiment of the present invention, implemented in an automotive environment. FIG. 12 shows a flow chart of logical processes applicable the embodiment of FIG. 11. An automobile may contain a plurality of electronic control units (ECUs) that are in communication with each other over one or more different busses. For example, one electronic control unit (ECU) within an automobile may contain a CPU with an OS that runs an infotainment application (playing media, connecting to the driver's phone, etc.) 1100.
[0098] For example, the infotainment application may request to send information on a central bus (1110, 1120). This request is converted by the infotainment application into a system call that is made to the OS (1200). The OS makes a driver call to the associated driver stack based upon the system call (1210). The paravirtualized driver front-end intercepts this driver call, converts it into a hyper call, and passes it to the hypervisor (1220). The hypervisor passes the hyper call to the policy module in a separate virtualized environment from the OS (and infotainment application) (1230). The analysis module of the policy module parses the call being made by the infotainment application to determine if the call addresses one of the safety-critical systems on the bus (e.g. airbags, brakes) and forwards these results to the security module (1240). If the request is addressed to a safety critical system, the security module does not allow the transmission of the hyper call to the paravirtualized driver back end (1250). If the request is not addressed to a safety critical system, then the security module copies the request into a new hyper call and passes it to the hypervisor (1260). The hypervisor passes the hyper call to the paravirtualized driver back-end in a third, separate virtual machine from both the OS and the policy module (1270). The paravirtualized driver back-end processes the request by sending the data on the centralized bus (e.g. CAN or FlexRay) (1280). This approach provides the additional security benefit that a malicious actor that gains root access on the infotainment system still cannot communicate with safety-critical systems). Thus, 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 method of IM by adopting the teachings of Srivastava to provide “ a hardware barrier that prevents the untrusted operating system and the untrusted driver from accessing code/data of the policy module (see Srivastava, para 75) .
Claim 4, IM teaches further generating streaming, via the interface and to a kernel layer exposed by the first version of the operating system, information relating to an application executing in the application layer exposed by the second version of the operating system, wherein the information relating to the application executing in the application layer exposed by the second version of the operating system comprises a fifth function call that conforms with the second version of the operating system (e.g., para [0048] Referring to FIG. 3, the kernel 120 may be connected to the hardware 110 to provide control signals to the hardware 110. The kernel 120 is a region for managing and controlling most basic functions of the devices which provide functions such as interrupt processing, process management, memory management, file system management, and programming interface. Generally, the kernel 120 may be loaded into an inaccessible memory and may be regarded as a type of application program interface (API) for controlling hardware. The hardware 110 may perform functions in response to the control signals received from the kernel 120. [0061] The first application library 141 may include a library necessary for execution of the first application 150. When the first application 150 is executed, the necessary library may be called. For example, the first application library 141 may implement common functions such as I/O and string manipulation (e.g., “C library”), graphics library, database library, communication library, and other libraries for the executed first application 150. The first application library 141 may provide the called library to the conversion unit 142.. Thus, another one of the “functions” include fifth function); transforming, by the interface, the fifth function call , a sixth function call that conforms with the first version of the operating system (e.g., para 0062] The conversion unit 142 may receive the called library and convert the received library so as to interface with the system library 130.
[0063] For example, the conversion unit 142 may convert the called library on the basis of the system library 130 of the vehicle software control device 10. The operating system of the vehicle software control device 10 and the operating system in which the first application 150 is executable may be Linux-based operating systems. Thus, another one of the “functions” include sixth function call); and transmitting, by the interface, the sixth function call to the first version of the operating system (e.g., see FIG. 4, para [0065] As described above, the Linux-based kernel may be designed with the processor 111 different from the Android-based kernel, but the Linux-based kernel may be the same as the Android kernel in that the kernel is designed based on Linux. Accordingly, the conversion unit 142 may convert the first application 150 executed on the Android-based kernel into the system library 130 of the vehicle software control device 10 such that the first application 150 executed on the Android-based kernel acts on the hardware 110 including a touch screen, a mobile connection (Global System for Mobile Communications (GSM)/Enhanced Data rates for GSM Evolution (EDGE), code division multiple access (CDMA), Wi-Fi, etc.) module, a battery management module, a GPS module, an accelerometer, and a camera module.
[0066] In addition, the library converted by the conversion unit 142 may be transmitted to the hardware 110 through the system library 130 and the kernel 120 as a control request. The hardware 110 may be controlled in response to the control request.
[0067] The kernel 120 may receive a control result from the hardware 110 and transmit the control result to the system library 130. A library for the control result transmitted to the system library 130 may be transmitted to the transmission unit 143. The transmission unit 143 may transmit the library for the control result to the conversion unit 142, and the conversion unit 142 may match the transmitted library for the control result with the first application library 141 and convert the library. That is, the library for the control result may be converted so as to match the interface of the first application library 141, and the control result for the hardware 110 may be transmitted to the first application 150 and provided to the user on the display.
[0068] The transmission unit 143 may transmit the converted library to the system library 130. Further, the transmission unit 143 may receive the library for the control result as described above).
However, IM does not teach transforming to the sixth function.
Srivastava teaches an interface transforming to the sixth function (e.g., see FIG. 11, para [0097] FIG. 11 shows a schematic of a paravirtualized security threat protection system, in accordance with an embodiment of the present invention, implemented in an automotive environment. FIG. 12 shows a flow chart of logical processes applicable the embodiment of FIG. 11. An automobile may contain a plurality of electronic control units (ECUs) that are in communication with each other over one or more different busses. For example, one electronic control unit (ECU) within an automobile may contain a CPU with an OS that runs an infotainment application (playing media, connecting to the driver's phone, etc.) 1100.
[0098] For example, the infotainment application may request to send information on a central bus (1110, 1120). This request is converted by the infotainment application into a system call that is made to the OS (1200). The OS makes a driver call to the associated driver stack based upon the system call (1210). The paravirtualized driver front-end intercepts this driver call, converts it into a hyper call, and passes it to the hypervisor (1220). The hypervisor passes the hyper call to the policy module in a separate virtualized environment from the OS (and infotainment application) (1230). The analysis module of the policy module parses the call being made by the infotainment application to determine if the call addresses one of the safety-critical systems on the bus (e.g. airbags, brakes) and forwards these results to the security module (1240). If the request is addressed to a safety critical system, the security module does not allow the transmission of the hyper call to the paravirtualized driver back end (1250). If the request is not addressed to a safety critical system, then the security module copies the request into a new hyper call and passes it to the hypervisor (1260). The hypervisor passes the hyper call to the paravirtualized driver back-end in a third, separate virtual machine from both the OS and the policy module (1270). The paravirtualized driver back-end processes the request by sending the data on the centralized bus (e.g. CAN or FlexRay) (1280). This approach provides the additional security benefit that a malicious actor that gains root access on the infotainment system still cannot communicate with safety-critical systems). Thus, 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 method of IM by adopting the teachings of Srivastava to provide “ a hardware barrier that prevents the untrusted operating system and the untrusted driver from accessing code/data of the policy module (see Srivastava, para 75) .
Claim 5 , IM teaches further receiving, by the interface, a seventh function call that conforms with the first version of the operating system in response to the sixth function call ((e.g., para [0048] Referring to FIG. 3, the kernel 120 may be connected to the hardware 110 to provide control signals to the hardware 110. The kernel 120 is a region for managing and controlling most basic functions of the devices which provide functions such as interrupt processing, process management, memory management, file system management, and programming interface. Generally, the kernel 120 may be loaded into an inaccessible memory and may be regarded as a type of application program interface (API) for controlling hardware. The hardware 110 may perform functions in response to the control signals received from the kernel 120. [0061] The first application library 141 may include a library necessary for execution of the first application 150. When the first application 150 is executed, the necessary library may be called. For example, the first application library 141 may implement common functions such as I/O and string manipulation (e.g., “C library”), graphics library, database library, communication library, and other libraries for the executed first application 150. The first application library 141 may provide the called library to the conversion unit 142.. Thus, another one of the “functions” include seventh function call); transforming, by the interface, the seventh function call , an eighth function call that conforms with the second version of the operating system (e.g., para 0062] The conversion unit 142 may receive the called library and convert the received library so as to interface with the system library 130.
[0063] For example, the conversion unit 142 may convert the called library on the basis of the system library 130 of the vehicle software control device 10. The operating system of the vehicle software control device 10 and the operating system in which the first application 150 is executable may be Linux-based operating systems. Thus, another one of the “functions” include an eighth function); and processing, by the second version of the operating system, the eighth function call e.g., see FIG. 4, para [0065] As described above, the Linux-based kernel may be designed with the processor 111 different from the Android-based kernel, but the Linux-based kernel may be the same as the Android kernel in that the kernel is designed based on Linux. Accordingly, the conversion unit 142 may convert the first application 150 executed on the Android-based kernel into the system library 130 of the vehicle software control device 10 such that the first application 150 executed on the Android-based kernel acts on the hardware 110 including a touch screen, a mobile connection (Global System for Mobile Communications (GSM)/Enhanced Data rates for GSM Evolution (EDGE), code division multiple access (CDMA), Wi-Fi, etc.) module, a battery management module, a GPS module, an accelerometer, and a camera module.
[0066] In addition, the library converted by the conversion unit 142 may be transmitted to the hardware 110 through the system library 130 and the kernel 120 as a control request. The hardware 110 may be controlled in response to the control request.
[0067] The kernel 120 may receive a control result from the hardware 110 and transmit the control result to the system library 130. A library for the control result transmitted to the system library 130 may be transmitted to the transmission unit 143. The transmission unit 143 may transmit the library for the control result to the conversion unit 142, and the conversion unit 142 may match the transmitted library for the control result with the first application library 141 and convert the library. That is, the library for the control result may be converted so as to match the interface of the first application library 141, and the control result for the hardware 110 may be transmitted to the first application 150 and provided to the user on the display.
[0068] The transmission unit 143 may transmit the converted library to the system library 130. Further, the transmission unit 143 may receive the library for the control result as described above). However, IM does not teach transforming to the eighth function call. Srivastava teaches an interface transforming to the eighth function call (e.g., see FIG. 11, para [0097] FIG. 11 shows a schematic of a paravirtualized security threat protection system, in accordance with an embodiment of the present invention, implemented in an automotive environment. FIG. 12 shows a flow chart of logical processes applicable the embodiment of FIG. 11. An automobile may contain a plurality of electronic control units (ECUs) that are in communication with each other over one or more different busses. For example, one electronic control unit (ECU) within an automobile may contain a CPU with an OS that runs an infotainment application (playing media, connecting to the driver's phone, etc.) 1100.
[0098] For example, the infotainment application may request to send information on a central bus (1110, 1120). This request is converted by the infotainment application into a system call that is made to the OS (1200). The OS makes a driver call to the associated driver stack based upon the system call (1210). The paravirtualized driver front-end intercepts this driver call, converts it into a hyper call, and passes it to the hypervisor (1220). The hypervisor passes the hyper call to the policy module in a separate virtualized environment from the OS (and infotainment application) (1230). The analysis module of the policy module parses the call being made by the infotainment application to determine if the call addresses one of the safety-critical systems on the bus (e.g. airbags, brakes) and forwards these results to the security module (1240). If the request is addressed to a safety critical system, the security module does not allow the transmission of the hyper call to the paravirtualized driver back end (1250). If the request is not addressed to a safety critical system, then the security module copies the request into a new hyper call and passes it to the hypervisor (1260). The hypervisor passes the hyper call to the paravirtualized driver back-end in a third, separate virtual machine from both the OS and the policy module (1270). The paravirtualized driver back-end processes the request by sending the data on the centralized bus (e.g. CAN or FlexRay) (1280). This approach provides the additional security benefit that a malicious actor that gains root access on the infotainment system still cannot communicate with safety-critical systems). Thus, 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 method of IM by adopting the teachings of Srivastava to provide “ a hardware barrier that prevents the untrusted operating system and the untrusted driver from accessing code/data of the policy module (see Srivastava, para 75) .
As to Claim 6, IM does not teach wherein the first interface is configured to provide security for communications between the first version of the operating system and the second version of the operating system. However, Srivastava teaches wherein the first interface is configured to provide security for communications between the first version of the operating system and the second version of the operating system (e.g., para [0075] Embodiments of the present invention use a hypervisor-based architecture to intercept and screen hardware requests for security threats. In traditional operating system environments, hardware drivers operate inside of the operating system kernel and interact directly with the hardware. Embodiments of the present invention decouple the driver from the host operating system and create a dedicated virtual environment in which the driver resides. Additionally, a policy module, which evaluates the hardware requests and implements a security policy, is also placed inside of a virtual environment.
“[0076] In one embodiment, since the driver lives within its own virtualized environment, the driver cannot be exploited to propagate out into the OS/application layer if the API between the operating system and the driver remains static (which is generally the case), the policy module can support multiple operating system versions and driver versions.”). Thus, 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 method of IM by adopting the teachings of Srivastava to provide “ a hardware barrier that prevents the untrusted operating system and the untrusted driver from accessing code/data of the policy module (see Srivastava, para 75) .
As to Claim 7 , IM teaches wherein the first interface is configured to list available properties of the vehicle, read a property value, write the property value, subscribe to property updates, and unsubscribe to the property updates (e.g., para [0045] The control unit 115 may control various devices or components in the vehicle. For example, the touch screen display may be controlled by the control unit 115.
[0046] The I/O device 116 may include ports (not shown) or buttons (not shown) and other user interface components that can be employed in the vehicle software control device 10. For example, the buttons may include a click wheel, a scroll wheel, a QWERTY keyboard, and the like. Further, the other user interface components may include Global Positioning System (GPS) devices, local area network (LAN) connectivity, microphones, speakers, cameras, accelerometers, Memory Stick (MS)/MultiMediaCard (MMC)/Secure Digital (SD)/Secure Digital Input Output (SDIO) card interfaces, and the like. However, the present disclosure is not limited thereto.
[0047] In addition, the hardware 110 may include a power supply 117 and various interface components such as a communication device and the like in addition to the above components. For example, the power supply 117 may be connected to a battery. Accordingly, the power supply 117 may receive information on an electrical state and the like from the battery. In such a configuration, the power supply 117 may manage a power source of the vehicle software control device 10
[0054] The kernel 120 may initialize the driver for the hardware 110 device. In this case, the kernel 120 may initialize memory protection, virtual memory modules, and schedule caching. Further, the kernel 120 may initialize the operating system. In an embodiment, the kernel 120 may execute processes of the vehicle software control device 10 to read configuration files describing system services and additional system parameters for the Android-based operating system.).
As to Claim 8 , IM teaches wherein the interface comprises a hardware abstraction layer (e.g., para [0077] Further, the first calling unit 144 and the second calling unit 131 may include a hardware abstraction layer (HAL). Accordingly, the first calling unit 144 and the second calling unit 131 may be composed of a plurality of library modules..
As to Claim 9 , IM teaches wherein the first version of the operating system and the second version of the operating system communicate via a universal automotive link (e.g., para [0102] Applications which are accessible through the processing modules 1200 may include, for example, a dial, gauges (e.g., a cyclometer, a speedometer, an oil pressure, an engine temperature, indoor/outdoor temperature, a trip computer, a maintenance tire pressure, vehicle/part performance monitoring, and other vehicle-related detection information), an application associated with a handicap and accessibility graphic user interface (e.g., large fonts, controls, text-to-speech conversion, text interface, voice command interface, etc.), an e-mail client, a web browser, a communication application (e.g., an e-mail application, a text messaging application, a telephony application, etc.), games (e.g., a solo or multi-party game, access to other multimedia files, specifically audio and/or video files, watching, or listening), a satellite positioning system receiver application (e.g., location tracking, vehicle tracking, map applications, medical information applications, and emergency services applications), a noise suppression application, a news-related application, a biometric first application (e.g., an iris recognition system for user identification, etc.), and a travel application.
[0103] The bus 1300 may be connected to each of the processing modules 1200. The bus 1300 may include a standardized communication network. The standardized communication network may include Ethernet, Wi-Fi, Universal Serial Bus (USB), Inter-Integrated Circuit (I.sup.2C), Recommended Standard 232 (RS232), RS485, and FireWire. For example, the bus 1300 may include and support buses 1300 with a standardized communication network such as a campus area network (CAN).
Thus, the “Wi-Fi, Universal Serial Bus (USB), Inter-Integrated Circuit (I.sup.2C), Recommended Standard 232 (RS232), RS485, and FireWire.” Include type a universal automotive link).
As to Claim 10 , IM teaches wherein the first version of the operating system and the second version of the operating system communicate via a USB connection ([0103] The bus 1300 may be connected to each of the processing modules 1200. The bus 1300 may include a standardized communication network. The standardized communication network may include Ethernet, Wi-Fi, Universal Serial Bus (USB), Inter-Integrated Circuit (I.sup.2C), Recommended Standard 232 (RS232), RS485, and FireWire. For example, the bus 1300 may include and support buses 1300 with a standardized communication network such as a campus area network (CAN).
As to Claim 11 , IM teaches wherein the first version of the operating system and the second version of the operating system communicate via a remote procedure call (e.g., para 48, wherein “Generally, the kernel 120 may be loaded into an inaccessible memory and may be regarded as a type of application program interface (API) for controlling hardware. The hardware 110 may perform functions in response to the control signals received from the kernel 120.”. Thus, communicate via a remote procedure call would have been inherent) .
As to Claim 12 , IM teaches wherein the cartridge is a removable device (e.g., para [0049] In the vehicle software control device 10, the kernel 120 may execute an operating system. That is, the operating system may be executed on the kernel 120. In particular, the operating system may be a manager applied to the vehicle software control device 10 via an interface with the hardware 110 through the kernel 120. For example, in a laptop computer, an operating system may include Linux, Mac OS X, or Windows 7. In addition, a mobile operating system may include Android, Apple iOS (for iPhone and iPad), Microsoft Windows Mobile (replaced with Windows Phone 7), Nokia Symbian, or Palm OS (replaced with HP webOS). Here, the kernel 120 will be described below on the assumption that tasks are performed by Linux.. Thus, wherein the cartridge is a removable device would have been inherent)
As to Claim 13 , IM teaches wherein the first interface provides a bidirectional stream for exchanging function calls between the first version of the operating system and the second version of the operating system (e.g., see FIG.5, para [0076] In the above-described manner, the kernel 120 may receive control information from the first connecting unit 140. In addition, even when the kernel 120 receives an event input through the hardware, the order is reversed and the rest is performed in the same manner.
[0077] Further, the first calling unit 144 and the second calling unit 131 may include a hardware abstraction layer (HAL). Accordingly, the first calling unit 144 and the second calling unit 131 may be composed of a plurality of library modules” . Thus, “the order is reversed and the rest is performed in the same manner” include exchanging function calls between the first version of the operating system and the second version of the operating system) .
As to Claim 14, see rejection of claim 1 above . IM teaches further a cartridge (e.g., FIG. 2) comprising: a memory; and one or more processors implemented in circuitry and communicatively coupled to the memory, the one or more processors being configured to (e.g., para [0041] Referring to FIG. 2, the hardware 110 may include an exemplary architectural configuration of the hardware 110 of the vehicle software control device 10 according to the embodiment. Generally, the hardware 110 may include a processor 111, a display unit 112, a storage unit 113, a memory unit 114, a control unit 115, and an input-and-output (I/O) device 116.).
As to claims 15-19, see rejection of claims 2-5 and 12 above.
As to Claim 20 , see rejection of claim 1 above. IM teaches further a non-transitory computer-readable storage medium having instructions stored thereon that, when executed, cause one or more processors of a cartridge to: (e.g., para [0041] Referring to FIG. 2, the hardware 110 may include an exemplary architectural configuration of the hardware 110 of the vehicle software control device 10 according to the embodiment. Generally, the hardware 110 may include a processor 111, a display unit 112, a storage unit 113, a memory unit 114, a control unit 115, and an input-and-output (I/O) device 116.
[0042] The processor 111 may be a vehicle infotainment-based processor 111. For example, the processor 111 may include an Advanced reduced instruction set computer (RISC) Machine (ARM)-based processor 111 such as a Texas Instruments OMAP3430, a Marvell PXA320, a Freescale iMX51, or a Qualcomm QSD8650/8250. Further, the processor 111 may be, for example, another appropriate ARM-based processor 111 on the basis of architecture of an x86-based processor 111 or architecture of another processor 111 such as architecture of another RISC-based processor 111. However, the present disclosure is not limited thereto, and the processor 111 may include various processing devices for performing control.).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDOU K SEYE whose telephone number is (571)270-1062. The examiner can normally be reached M-F 9-5:30.
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, Pierre Vital can be reached at 5712724215. 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.
/ABDOU K SEYE/Examiner, Art Unit 2198
/PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198