DETAILED ACTION
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 2/20/2026 has been entered.
The Office Action is in response to a request for continued examination filed 2/20/2026.
Claims 11 and 12 are newly added claims.
Claims 1-3 and 7-10 are amended claims.
Claims 1-12 are currently pending.
The rejection of claims 2-3 and 8 under 35 U.S.C. 112(b) has been withdrawn in view of the applicant’s amendments to claims 2-3 and 8 respectively.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3-4, 7, and 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over US 20220027143 Al hereinafter "Fukuyo" in view of US 20220357928 A1 hereinafter "Dauber" in view of US 20090005916 A1 hereinafter "Wainwright" and further in view of US 20140214515 A1 hereinafter “Quirk”.
With regards to claim 1, Fukuyo teaches,
A mobility service providing system, comprising:
a server configured to provide an application program for performing a process
(Fukuyo [0030], "The server 100 is in one example a computer device, such as a server or the
like installed in a particular center or the like, and is capable of transmitting respective update
data to each of a plurality of vehicles, for updating software of in vehicle devices of the vehicles.
The server 100 includes a communication unit (communication module) 111 for communicating
with the software updating device 50 and a control unit 112 for controlling the communication
unit 111. The functions of the control unit 112 are executed by one or more processors, one or
more microcontrollers, or the like. The server 1001s provided with a storage unit that is omitted
from illustration, and is also capable of externally accepting and storing data for updating
software for each of the in-vehicle devices") using a function of a vehicle; (Fukuyo [0004],
"Software that the processor executes (software) is stored in the nonvolatile storage unit.
Updating the software by rewriting to a newer version enables functions of the in-vehicle devices
to be improved and enhanced.")
an in-vehicle device installed in the vehicle and having at least one processor and
memory (Fukuyo [0022], "Although omitted from illustration, these in-vehicle devices include a nonvolatile second storage unit (storage) such as flash read-only memory (ROM) or the like, a
control unit (processor, microcontroller) that reads software out from the second storage unit and
executes the software, thereby performing various types of processing, and a transitory storage
unit such as random-access memory (RAM) that stores part of software and data.") configured
to obtain the application program from the server and execute the obtained application
program; wherein: (Fukuyo [0020], "The network system 1 includes a software updating
device 50. A plurality of busses 10, 20, 30 are connected to the software updating device
(over-the-air (OTA) master) 50. A plurality of in-vehicle devices (electronic control units
(ECUs)) 11, 12 is connected to the bus 10. A plurality of in-vehicle devices 21, 22 is
connected to the bus 20. A plurality of actuators 31, 32 1s connected to the bus 30. Although
in FIG. 1 and the following description, the busses 10, 20, and 30 are exemplified as busses, and
the in-vehicle devices 11, 12, 21, and 22 and the actuators 31 and 32 are exemplified as in vehicle
devices, the number thereof are not limiting. Note that various types of sensors for
acquiring the state of the vehicle and the surroundings of the vehicle are connected to the busses
10, 20, and 30, and the in-vehicle devices 11, 12, 21, and 22 as appropriate.")
one of the server, the in-vehicle device, or the additional computing device is
configured to obtain basic information that is information on the function of the vehicle in
which the in-vehicle device is installed; (Fukuyo [0035], "Usage information is information
representing the usage state of the vehicle. Usage information includes, for example, the time
when the vehicle was used in a plurality of times of the past, or average time thereof, and so
forth, although not limited to this. The time when the vehicle was used is, for example, the time
period that is from when the ignition is turned on until when the ignition is turned off and in
which the vehicle travels and stops. The usage information may include information representing the frequency of usage of a plurality of functions of the vehicle, for example. The frequency of
usage of the functions of the vehicle is the number of times or the like of user operations or the
like enabling the functions making up advanced driver-assistance systems (ADAS), such as lane
centering, cruise control, automated braking, proximity warning, and so forth, during a
predetermined number of times of traveling in the past, for example. Further, usage information
may include information generated based on a traveling plan set to the vehicle. A traveling plan
is a traveling route to a destination that is currently set to an automotive navigation system,
which is one of the in-vehicle devices, for example, and the usage information is estimated
required time to reach the destination calculated based on the traveling plan, for example. The
control unit 53 may acquire usage information generated by the in-vehicle devices, or may
generate usage information from information such as logs, traveling plans, and so forth, acquired
from the in-vehicle devices")
one of the server, the in-vehicle device, or the additional computing device is
configured to determine, when a request for downloading the application program from
the server to the in-vehicle device is made, whether the application program is usable in the
in-vehicle device [by comparing (a) the hardware requirement associated with the
application program to be downloaded with (b) the abstracted information possessed by
the in-vehicle device to which the application program is to be downloaded;] (Fukuyo
[0025], "Control of installing is not limited to executing installing alone, and may include a
series of processing relating to installing, such as determination regarding whether to execute
installing, transfer of update data, verification of update-version software, and so forth [when a
request for downloading the application program from the server to the in-vehicle device is
made]. Activating is processing of enabling (activating) the installed update-version software. Control of activating is not limited to executing activating alone, and may include a series of
control relating to activating, such as determination regarding whether to execute activating,
verification of activation results, and so forth [one of the server, the in-vehicle device, or the
additional computing device is configured to determine whether the application program is
usable in the in-vehicle device]")
Fukuyo does not teach:
one of the server, the in-vehicle device, or an additional computing device of the
mobility service providing system having at least one second processor and memory is
configured to store a hardware requirement required for executing the application
program;
one of the server, the in-vehicle device, or the additional computing device is
configured to obtain additional information that is information on a peripheral device
detachably attached to the vehicle;
[One of the server, the in-vehicle device, or the additional computing device is
configured to determine, when a request for downloading the application program from
the server to the in-vehicle device is made, whether the application program is usable in the
in-vehicle device] by comparing (a) the hardware requirement associated with the
application program to be downloaded with (b) the abstracted information possessed by
the in-vehicle device to which the application program is to be downloaded;
However, in an analogous art Dauber teaches one of the server, the in-vehicle device,
or an additional computing device of the mobility service providing system having at least
one second processor and memory is configured to store a hardware requirement required
for executing the application program; (Dauber [0018-19], "The following example illustrates an implementation scenario associated with a technical entity providing infrastructure sizing to a
client for determining necessary hardware to run new software across multiple environments.
The scenario is initiated when the technical entity determines the following two options for
sizing the client's hardware requirements: software and licensing requirements and technical
infrastructure specifications based on software needs. If the client specifies software needs and
requires infrastructure specifications, system 100 may be accessed via client login credentials for
execution of an associated software tool When system 100 has automatically run all necessary
scripts, associated data is uploaded into a project folder. Subsequently, automated check boxes
are presented adjacent to associated data collection points that have been successfully uploaded
to the project folder. The technical entity and client are able to view an audit trail associated with
a time period within the sizing process. Subsequently, 3 differing algorithms and associated code
are executed for providing the infrastructure sizing for determining necessary hardware to run
new software across multiple environments.")
one of the server, the in-vehicle device, or the additional computing device is
configured to obtain additional information that is information on a peripheral device
detachably attached to the vehicle; (Dauber FIG 5; and [0015-0017], "The specialized discrete
non-generic analog, digital, and logic-based circuitry (e.g., sensors/circuitry/logic 12, self-learning software/hardware code/engines/scripts 28, etc.) may include proprietary specially
designed components (e.g., a specialized integrated circuit, such as for example an application
Specific Integrated Circuit (ASIC) designed for only implementing an automated process for
improving software technology associated with cross-referencing metrics associated with plug-in
components, generating software code modules, and enabling operational functionality of target
cloud components. Sensors/circuitry/logic 12 may include any type of internal or external sensors including, inter alia, GPS sensors, Bluetooth beaconing sensors, cellular telephone
detection sensors, Wi-Fi positioning detection sensors, triangulation detection sensors, activity
tracking sensors, a temperature sensor, an ultrasonic sensor, an optical sensor, a video retrieval
device, humidity sensors, voltage sensors, network traffic sensors, etc. System 100 is
configured to be expanded via usage of additional plug-ins for every version and hardware
combination. Likewise, system 100 assembles collected data from all of plug-in components for
summarizing existing software and hardware infrastructure environments. System 100 will
additionally run a data collection script with respect to an existing environment resulting in
output generation")
[One of the server, the in-vehicle device, or the additional computing device is
configured to determine, when a request for downloading the application program from
the server to the in-vehicle device is made, whether the application program is usable in the
in-vehicle device] by comparing (a) the hardware requirement associated with the
application program to be downloaded with (b) the abstracted information possessed by
the in-vehicle device to which the application program is to be downloaded; (Dauber [0002],
"cross-referencing, by the processor, the metrics data with respect to operational sizing
recommendations for each plug-in component of the plurality of plug-in components based on
aggregated disparate sizing guidelines [by comparing the hardware requirement associated with
the application program to be downloaded with (b) the abstract information possessed by the in-vehicle device]; generating, by the processor, software code modules associated with results of
the cross-referencing; determining, by the processor based on results of executing the software
code modules, software and hardware requirements for enabling target computing components;
and enabling, by the processor based on the software and hardware requirements, operational functionality of the target computing components [to which the application program is to be
downloaded] in accordance with the software and hardware requirements.")
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Dauber into
the teachings of Fukuyo. This combination of teachings would have resulted in a mobility
providing service with a server and in-vehicle device to provide an application and vehicle
functionality information, as in Fukuyo, incorporating a system for storing hardware
requirements, additional peripheral information, and using the abstracted information to
determine application feasibility, as in Dauber. One of ordinary skill in the art would have been
motivated to combine these teachings for the purpose of providing a method and associated
system for cross-referencing metrics associated with plug-in components, generating software
code modules, and enabling operational functionality of target cloud/computing components (Dauber [0001]).
The combination of Fukuyo and Dauber does not explicitly teach:
one of the server, the in-vehicle device, or the additional computing device is
configured to-convert the basic information and the additional information that is the information on the peripheral device detachably attached to the vehicle into abstracted information, the abstracted information being information in a common format independent from the vehicle and the peripheral device;
the in-vehicle device is configured to download the application program in response
to a determination that the application program is usable in the in-vehicle device and to
execute the obtained application program after downloading.
However, in an analogous art Wainwright teaches one of the server, the in-vehicle
device, or the additional computing device is configured to-convert the basic information
and the additional information that is the information on the peripheral device detachably
attached to the vehicle into abstracted information, the abstracted information being
information in a common format independent from the vehicle and the peripheral device;
(Wainwright [0043], " In various exemplary embodiments, a data interface 210 may be provided
[that is the information on the peripheral device] as one or more available input/output ports to
facilitate communication with one or more of the vehicle systems 100-180 via available
connection means, including wired or wireless means [detachably attached to the vehicle]. When
the data interface is connected for wired communications, such data interface 210 may comprise
one or more ports according to MIL-STD-1553, RS-232, RS-422, RS-485, ARINC 429,
Ethernet, Discrete and/or Analog I/O ports. Any manner by which compatible data interaction
may be facilitated between one or more of the vehicle systems 100-180 and the interface unit 200
via such data interface 210 is contemplated. ") and (Wainwright [0056], "Resident within the
interface unit 200 in, for example, a data conversion unit 245, may be a capability to know the
multiple data formats that may be required to keep the system integrated. As such, when data is
received discretely, or on a continuous basis, from each of the individual vehicle systems 100-
180, the data conversion unit 245 may be available to individually translate the data to be usable
by each of the other individual vehicle systems 100-180, or may establish a common data format
to be shared among the individual vehicle systems 100-180 [into abstracted information, the
abstracted information being information in a common format independent from the vehicle and
the peripheral device]. As may be appropriate, a data verification unit 250 may be separately
provided to monitor the data conversion occurring in the data conversion unit 245 in order to
attempt to ensure that seamless integration occurs, and to reduce and/or substantially eliminate
errors due to, for example, data corruption. ")
the in-vehicle device is configured to download the application program in response
to a determination that the application program is usable in the in-vehicle device and to
execute the obtained application program after downloading. (Wainwright [0053], "In
various exemplary embodiments, the interface unit 200 is provided with a capability to update a
configuration of the interface unit 200 itself, or to be provided with information on updates,
upgrades, or modifications to, as well as replacement of, any one of the vehicle systems 100-180,
or individual components in, or associated with such systems, via, for example, a configuration
update unit 240. It is envisioned that compatible software to update the capability by which the
interface unit 200 may continue to provide a seamless integration and translation capability
between individual vehicle systems 100-180 may be provided through such a configuration
update unit 240 [the in-vehicle device is configured to download the application program in
response to a determination that the application program is usable in the in-vehicle device] and
may be stored, for example, in a data storage unit 235, or input via one or more of the interfaces
or in communication directly from the affected vehicle system in this regard, any manner by
which updating software and/or circuitry may need to be incorporated within the overall system
is envisioned to be housed within, or provided for, with the exemplary interface unit 200. Such
an interface unit 200 is envisioned to encompass the single point source within the overall
integrated vehicle system to manage configuration of the vehicle system and to be updatable to
continue to provide such capability [and to execute the obtained application program after
downloading] regardless of changes in individual components and/or individual system within
the integrated vehicle system.")
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Wainwright
into the teachings of Fukuyo in view of Dauber. This combination of teachings would have
resulted in a mobility providing service with a server and in-vehicle device to provide an
application and vehicle functionality information, as in Fukuyo, incorporating a system for
storing hardware requirements, additional peripheral information, and using the abstracted
information to determine application feasibility, as in Dauber, wherein the vehicle is capable of
converting communicating information from the vehicle in an independent format in order to
communicate information so as to determine if the application is downloadable, as in
Wainwright. One of ordinary skill in the art would have been motivated to combine these
teachings for the purpose of providing digital or serial communications gateway for integration
of data exchange capabilities between vehicle control components (Wainwright [0020]).
The combination of Fukuyo, Dauber, and Wainwright teaches an in-vehicle device but does not teach: the [in-vehicle device] is configured to receive a notice of download refusal regarding the download of the application program in response to a determination that the application program is not usable in the [in-vehicle] device.
However, in an analogous art Quirk teaches the [in-vehicle] device is configured to receive a notice of download refusal regarding the download of the application program in response to a determination that the application program is not usable in the [in-vehicle] device. (Quirk [0054], “the in-vehicle device is configured to receive a notice of download refusal regarding the download of the application program in response to a determination that the application program is not usable in the in-vehicle device … Nevertheless, when the decision 342 determines that the application program would be compatible with the requesting device, download of the application program to the requesting device can be permitted 344. Alternatively, when the decision 342 determines that the application program would not be compatible with the requesting device, an error message can be returned 346 the application program is not compatible with requesting device. Following the blocks 344 and 346, the compatibility check process 340 can end.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Quirk into the teachings of Fukuyo in view of Dauber and further in view of Wainwright. This combination of teachings would have resulted in a mobility providing service with a server and in-vehicle device to provide an application and vehicle functionality information, as in Fukuyo, incorporating a system for storing hardware requirements, additional peripheral information, and using the abstracted information to determine application feasibility, as in Dauber, wherein the vehicle is capable of converting communicating information from the vehicle in an independent format in order to communicate information so as to determine if the application is downloadable, as in
Wainwright, and if the application is not downloadable generating a message indication of incompatibility, as in Quirk. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of determining if the submitted application code is valid and indicating an error message if otherwise (Quirk [0045]).
With regards to claim 3, the rejection of claim 1 is incorporated.
Fukuyo further teaches [the server is configured to store the hardware requirement]
and to determine whether the application is usable in the in-vehicle device, (Fukuyo [0025],
"Control of installing is not limited to executing installing alone, and may include a series of
processing relating to installing, such as determination regarding whether to execute installing,
transfer of update data, verification of update-version software, and so forth. Activating is
processing of enabling (activating) the installed update-version software. Control of activating is
not limited to executing activating alone, and may include a series of control relating to
activating, such as determination regarding whether to execute activating, verification of
activation results, and so forth")
Fukuyo does not explicitly teach:
wherein the in-vehicle device is configured to obtain the basic information and the
additional information and to convert the basic information and the additional information
into abstracted information, [and to convert the basic information and the additional
information into abstracted information,]
the server is configured to store the hardware requirement [and to determine
whether the application is usable in the in-vehicle device,]
the server is further configured to obtain the abstracted information from the in-vehicle device [to which the application program is downloaded when the useability
determiner determines whether the application program is determined to be usable.]
However, in an analogous art Dauber teaches wherein the in-vehicle device is
configured to obtain the basic information (Dauber FIG 5; and [0015-0017], "The specialized
discrete non-generic analog, digital, and logic-based circuitry (e.g., sensors/circuitry/logic 12,
self-learning software/hardware code/engines/scripts 28, etc.) may include proprietary specially
designed components (e.g., a specialized integrated circuit, such as for example an application
Specific Integrated Circuit (ASIC) designed for only implementing an automated process for
improving software technology associated with cross-referencing metrics associated with plug-in
components, generating software code modules, and enabling operational functionality of target
cloud components. Sensors/circuitry/logic 12 may include any type of internal or external
sensors including, inter alia, GPS sensors, Bluetooth beaconing sensors, cellular telephone
detection sensors, Wi-Fi positioning detection sensors, triangulation detection sensors, activity
tracking sensors, a temperature sensor, an ultrasonic sensor, an optical sensor, a video retrieval
device, humidity sensors, voltage sensors, network traffic sensors, etc. System 100 is configured to be expanded via usage of additional plug-ins for every version and hardware combination. Likewise, system 100 assembles collected data from all of plug-in components for
summarizing existing software and hardware infrastructure environments. System 100 will
additionally run a data collection script with respect to an existing environment resulting in
output generation") and the additional information (Dauber FIG 5; and [0015-0017], "The
specialized discrete non-generic analog, digital, and logic-based circuitry (e.g.,
sensors/circuitry/logic 12, self-learning software/hardware code/engines/scripts 28, etc.) may
include proprietary specially designed components (e.g., a specialized integrated circuit, such as
for example an Application Specific Integrated Circuit (ASIC) designed for only implementing
an automated process for improving software technology associated with cross-referencing
metrics associated with plug-in components, generating software code modules, and enabling
operational functionality of target cloud components. Sensors/circuitry/logic 12 may include any
type of internal or external sensors including, inter alia, GPS sensors, Bluetooth beaconing
sensors, cellular telephone detection sensors, Wi-Fi positioning detection sensors, triangulation
detection sensors, activity tracking sensors, a temperature sensor, an ultrasonic sensor, an optical
sensor, a video retrieval device, humidity sensors, voltage sensors, network traffic sensors, etc.
System 100 is configured to be expanded via usage of additional plug-ins for every version and
hardware combination. Likewise, system 100 assembles collected data from all of plug-in
components for summarizing existing software and hardware infrastructure environments.
System 100 will additionally run a data collection script with respect to an existing environment
resulting in output generation")
the server is configured to store the hardware requirement [and to determine
whether the application is usable in the in-vehicle device,] (Dauber [0018-19], "The following
example illustrates an implementation scenario associated with a technical entity providing
infrastructure sizing to a client for determining necessary hardware to run new software across
multiple environments. The scenario is initiated when the technical entity determines the
following two options for sizing the client's hardware requirements: software and licensing
requirements and technical infrastructure specifications based on software needs. If the client
specifies software needs and requires infrastructure specifications, system 100 may be accessed
via client login credentials for execution of an associated software tool When system 100 has
automatically run all necessary scripts, associated data is uploaded into a project folder.
Subsequently, automated check boxes are presented adjacent to associated data collection points
that have been successfully uploaded to the project folder. The technical entity and client are able
to view an audit trail associated with a time period within the sizing process. Subsequently, 3
differing algorithms and associated code are executed for providing the infrastructure sizing for
determining necessary hardware to run new software across multiple environments.") and
the server is further configured to obtain the abstracted information from the in vehicle
device [to which the application program is downloaded when the useability
determiner determines whether the application program is determined to be usable.]
(Dauber [0004], "A third aspect of the invention provides a server hardware device comprising a
processor coupled to a computer-readable memory unit, the memory unit comprising instructions
that when executed by the computer processor implements an automated system capacity
optimization method comprising: retrieving, by the processor from a plurality of plug-in
components running on a plurality of hardware and software sources, metrics data associated
with the plurality of plug-in components; cross-referencing, by the processor, the metrics data
with respect to operational sizing recommendations for each plug-in component of the plurality of plug-in components based on aggregated disparate sizing guidelines; generating, by the
processor, software code modules associated with results of the cross-referencing; determining,
by the processor based on results of executing the software code modules, software and hardware
requirements for enabling target computing components; and enabling, by the processor based on
the software and hardware requirements, operational functionality of the target computing
components in accordance with the software and hardware requirements")
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Dauber into
the teachings of Fukuyo. This combination of teachings would have resulted in a mobility
providing service with a server and in-vehicle device to provide an application and vehicle
functionality information, as in Fukuyo, incorporating a server system to store system application
requirements and the means to determine application compatibility, as in Dauber, One of
ordinary skill in the art would have been motivated to combine these teachings for the purpose of
a method and associated system for cross-referencing metrics associated with plug-in
components, generating software code modules, and enabling operational functionality of target
cloud/computing components (Dauber [0001]).
The combination of Fukuyo and Dauber does not explicitly teach:
and to convert the basic information and the additional information into abstracted
information,
[the server is further configured to obtain the abstracted information from the in vehicle
device] to which the application program is downloaded when the useability determiner determines whether the application program is determined to be usable.
However, in an analogous art Wainwright teaches and to convert the basic information
and the additional information into abstracted information, (Wainwright [0056], "Resident
within the interface unit 200 in, for example, a data conversion unit 245, may be a capability to
know the multiple data formats that may be required to keep the system integrated. As such,
when data is received discretely, or on a continuous basis, from each of the individual vehicle
systems 100-180, the data conversion unit 245 may be available to individually translate the data
to be usable by each of the other individual vehicle systems 100-180, or may establish a common
data format to be shared among the individual vehicle systems 100-180. As may be appropriate,
a data verification unit 250 may be separately provided to monitor the data conversion occurring
in the data conversion unit 245 in order to attempt to ensure that seamless integration occurs, and
to reduce and/or substantially eliminate errors due to, for example, data corruption.)
[the server is further configured to obtain the abstracted information from the in vehicle
device] to which the application program is downloaded when the useability
determiner determines whether the application program is determined to be usable.
(Wainwright [0053], "In various exemplary embodiments, the interface unit 200 is provided with
a capability to update a configuration of the interface unit 200 itself, or to be provided with
information on updates, upgrades, or modifications to, as well as replacement of, any one of the
vehicle systems 100-180, or individual components in, or associated with such systems, via, for
example, a configuration update unit 240. It is envisioned that compatible software to update the
capability by which the interface unit 200 may continue to provide a seamless integration and
translation capability between individual vehicle systems 100-180 may be provided through such
a configuration update unit 240 [when the application program is determined to be usable] and
may be stored, for example, in a data storage unit 235, or input via one or more of the interfaces or in communication directly from the affected vehicle system in this regard, any manner by
which updating software and/or circuitry may need to be incorporated within the overall system is envisioned to be housed within, or provided for, with the exemplary interface unit 200. Such
an interface unit 200 is envisioned to encompass the single point source within the overall
integrated vehicle system to manage configuration of the vehicle system and to be updatable to
continue to provide such capability [to which the application program is downloaded] regardless
of changes in individual components and/or individual system within the integrated vehicle
system.")
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Wainwright
into the teachings of Fukuyo in view of Dauber. This combination of teachings would have
resulted in a mobility providing service with a server and in-vehicle device to provide an
application and vehicle functionality information, as in Fukuyo, incorporating a system for
storing hardware requirements, additional peripheral information, and using the abstracted
information to determine application feasibility, as in Dauber, wherein the vehicle is capable of
converting communicating information from the vehicle in an independent format in order to
communicate information so as to determine if the application is downloadable, as in
Wainwright. One of ordinary skill in the art would have been motivated to combine these
teachings for the purpose of providing digital or serial communications gateway for integration
of data exchange capabilities between vehicle control components (Wainwright [0020]).
The combination of Fukuyo, Dauber, and Wainwright teaches an in-vehicle device but does not teach: the [in-vehicle device] is configured to receive a notice of download refusal regarding the download of the application program in response to a determination that the application program is not usable in the [in-vehicle] device.
However, in an analogous art Quirk teaches the [in-vehicle] device is configured to receive a notice of download refusal regarding the download of the application program in response to a determination that the application program is not usable in the [in-vehicle] device. (Quirk [0054], “the in-vehicle device is configured to receive a notice of download refusal regarding the download of the application program in response to a determination that the application program is not usable in the in-vehicle device … Nevertheless, when the decision 342 determines that the application program would be compatible with the requesting device, download of the application program to the requesting device can be permitted 344. Alternatively, when the decision 342 determines that the application program would not be compatible with the requesting device, an error message can be returned 346 the application program is not compatible with requesting device. Following the blocks 344 and 346, the compatibility check process 340 can end.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Quirk into the teachings of Fukuyo in view of Dauber and further in view of Wainwright. This combination of teachings would have resulted in a mobility providing service with a server and in-vehicle device to provide an application and vehicle functionality information, as in Fukuyo, incorporating a system for storing hardware requirements, additional peripheral information, and using the abstracted information to determine application feasibility, as in Dauber, wherein the vehicle is capable of converting communicating information from the vehicle in an independent format in order to communicate information so as to determine if the application is downloadable, as in
Wainwright, and if the application is not downloadable generating a message indication of incompatibility, as in Quirk. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of determining if the submitted application code is valid and indicating an error message if otherwise (Quirk [0045]).
With regards to claim 4, the rejection of claim 1 is incorporated.
Fukuyo further teaches [the in-vehicle device is further configured to obtain, when the
in-vehicle device is initialized, specific information that is required for grasping a content
of the basic information] and is described in a format specific to a type of the vehicle
(Fukuyo 0029], "Note that such updating processing of software can be performed successively,
or in parallel, to each of the in-vehicle devices. Also note that update data is data used for
generating updating software, and includes, for example, the updating software itself, difference
data for generating the updating software, compressed data or divided data thereof, or the like, as
described above, and the content and the format thereof are not limited. The update data may
also include an identifier of the in-vehicle device (ECU ID) that is the target of software updating
(target ECU) and the identifier of the version of software prior to updating (ECU Software ID).")
Fukuyo does not teach:
the in-vehicle device is further configured to obtain, when the in-vehicle device is
initialized, specific information that is required for grasping a content of the basic
information [and is described in a format specific to a type of the vehicle]
However, in an analogous art Dauber teaches the in-vehicle device is further
configured to obtain, when the in-vehicle device is initialized, specific information that is
required for grasping a content of the basic information [and is described in a format
specific to a type of the vehicle] (Dauber [0014], "1. Metrics (e.g., rate of logging data per
application, number of applications, peak transactions per second (TPS), volume of an API call,
etc.) are collected from (software) plug-in components 25 running within existing software and
hardware infrastructure environments. The plug-in components 25 include respective data
collection (software) scripts generated based on the existing software and hardware infrastructure
environments. 2. The metrics are cross-referenced with sizing recommendations for each plug-in
component based on aggregating disparate sizing guidelines. 3. Disparate sizing guidelines are
retrieved and analyzed with respect to keywords to determine a logical order for the sizing
guidelines and an order for running each script. 4. A logical order of the sizing guidelines are
iteratively adjusted each time a new plug-in component is introduced to system 100.5. An
algorithm and associated code are generated for encompassing all sizing guidelines. The
algorithm and associated code are continually modified based on correlations identified between
the sizing guidelines. 6. Software and hardware needs (e.g., with respect to CPU, memory, disk
space, a number of persistent volumes, etc.) are determined with respect to target cloud
environments based on collected metrics and the algorithm and associated code generated.")
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Dauber into
the teachings of Fukuyo. This combination of teachings would have resulted in a mobility
providing service with a server and in-vehicle device to provide an application and vehicle
functionality information, as in Fukuyo, incorporating a server system to store system application
requirements and the means to determine application compatibility, as in Dauber, One of
ordinary skill in the art would have been motivated to combine these teachings for the purpose of
a method and associated system for cross-referencing metrics associated with plug-in
components, generating software code modules, and enabling operational functionality of target
cloud/computing components (Dauber [0001]).
With regards to claim 7, Fukuyo teaches
An in-vehicle device obtaining from a server and executing an application program
for performing a process (Fukuyo [0030], "The server 100 is in one example a computer device, such as a server or the like installed in a particular center or the like, and is capable of
transmitting respective update data to each of a plurality of vehicles, for updating software of in
vehicle devices of the vehicles. The server 100 includes a communication unit (communication
module) 111 for communicating with the software updating device 50 and a control unit 112 for
controlling the communication unit 111. The functions of the control unit 112 are executed by
one or more processors, one or more microcontrollers, or the like. The server 1001s provided
with a storage unit that is omitted from illustration, and is also capable of externally accepting
and storing data for updating software for each of the in-vehicle devices") using a function of a
vehicle; (Fukuyo [0004], "Software that the processor executes (software) is stored in the
nonvolatile storage unit. Updating the software by rewriting to a newer version enables functions
of the in-vehicle devices to be improved and enhanced.") the in-vehicle device being
configured to:
obtain basic information that is information on the function of the vehicle in which
the in-vehicle device is installed; (Fukuyo [0035], "Usage information is information
representing the usage state of the vehicle. Usage information includes, for example, the time
when the vehicle was used in a plurality of times of the past, or average time thereof, and so
forth, although not limited to this. The time when the vehicle was used is, for example, the time
period that is from when the ignition is turned on until when the ignition is turned off and in
which the vehicle travels and stops. The usage information may include information representing
the frequency of usage of a plurality of functions of the vehicle, for example. The frequency of
usage of the functions of the vehicle is the number of times or the like of user operations or the
like enabling the functions making up advanced driver-assistance systems (ADAS), such as lane
centering, cruise control, automated braking, proximity warning, and SO forth, during a predetermined number of times of traveling in the past, for example. Further, usage information
may include information generated based on a traveling plan set to the vehicle. A traveling plan
is a traveling route to a destination that is currently set to an automotive navigation system,
which is one of the in-vehicle devices, for example, and the usage information is estimated
required time to reach the destination calculated based on the traveling plan, for example. The
control unit 53 may acquire usage information generated by the in-vehicle devices, or may
generate usage information from information such as logs, traveling plans, and so forth, acquired
from the in-vehicle devices")
provide the server [with the abstracted information as] information for determining
whether the application program is downloadable; (Fukuyo [0023], "Also, the control unit 53
of the software updating device 50 controls and relays communication between the server 100
and the in-vehicle devices 11, 12, 21, and 22, communication among the in-vehicle devices 11,
12, 21, and 22, and communication between the in-vehicle devices 11, 12, 21, and 22 and the
actuators 31 and 32, over the busses 10, 20, and 30. Thus, the software updating device 50 also
functions as a relay device that relays communication. Alternatively, the software updating
device 50 may be provided as a part of such a relay device, or may be connected to one of the
busses 10, 20, and 30 separately from such a relay device.") and (Fukuyo [0025], "The control
unit 53 of the software updating device 50 is capable of updating software stored in the second
storage unit of each of the in-vehicle devices 11, 12, 21, and 22. That is to say, the software
updating device 50 performs control of downloading, control of installing, and further control of
activating. Downloading is processing of receiving and storing update data (distribution package)
for updating software of one of the in-vehicle devices 11, 12, 21, and 22 that has been
transmitted from the server 100. Control of downloading is not limited to executing downloading
alone, and may include a series of control of processing relating to downloading, such as
determination regarding whether to execute downloading, verification of update data, and so
forth. Installing is processing of writing update-version software (updating software) in the
second storage unit of the in-vehicle device that is the target of updating, based on the
downloaded update data. Control of installing is not limited to executing installing alone, and
may include a series of processing relating to installing, such as determination regarding whether
to execute installing, transfer of update data, verification of update-version software, and so
forth.")
Fukuyo does not teach:
obtain additional information that is information on a peripheral device detachably
attached to the vehicle;
However, in an analogous art Dauber teaches to obtain additional information that is
information on a peripheral device detachably attached to the vehicle; (Dauber FIG 5; and
[0015-0017], "The specialized discrete non-generic analog, digital, and logic-based circuitry
(e.g., sensors/circuitry/logic 12, self-learning software/hardware code/engines/scripts 28, etc.)
may include proprietary specially designed components (e.g., a specialized integrated circuit,
such as for example an Application Specific Integrated Circuit (ASIC) designed for only
implementing an automated process for improving software technology associated with cross referencing metrics associated with plug-in components, generating software code modules, and
enabling operational functionality of target cloud components. Sensors/circuitry/logic 12 may
include any type of internal or external sensors including, inter alia, GPS sensors, Bluetooth
beaconing sensors, cellular telephone detection sensors, Wi-Fi positioning detection sensors,
triangulation detection sensors, activity tracking sensors, a temperature sensor, an ultrasonic
sensor, an optical sensor, a video retrieval device, humidity sensors, voltage sensors, network
traffic sensors, etc. System 100 is configured to be expanded via usage of additional plug-ins
for every version and hardware combination. Likewise, system 100 assembles collected data
from all of plug-in components for summarizing existing software and hardware infrastructure
environments. System 100 will additionally run a data collection script with respect to an
existing environment resulting in output generation")
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Dauber into
the teachings of Fukuyo. This combination of teachings would have resulted in a mobility
providing service with a server and in-vehicle device to provide an application and vehicle
functionality information, as in Fukuyo, incorporating a server system to store system application
requirements and the means to determine application compatibility, as in Dauber, One of
ordinary skill in the art would have been motivated to combine these teachings for the purpose of
a method and associated system for cross-referencing metrics associated with plug-in
components, generating software code modules, and enabling operational functionality of target
cloud/computing components (Dauber [0001]).
The combination of Fukuyo and Dauber does not teach:
convert the basic information and the additional information that is the information
on the peripheral device detachable attached to the vehicle into abstracted information, the
abstracted information being information in a common format independent from vehicle
and the peripheral device;
[provide the server] with the abstracted information as [information for determining whether the application program is downloadable;]
wherein the in-vehicle device is configured to download the application program in
response to a determination by the server that the application program is usable in the in-vehicle device and to execute the obtained application program after downloading.
However, in an analogous art Wainwright teaches to convert the basic information and
the additional information that is the information on the peripheral device detachable
attached to the vehicle into abstracted information, the abstracted information being
information in a common format independent from vehicle and the peripheral device;
(Wainwright [0056], "Resident within the interface unit 200 in, for example, a data conversion
unit 245, may be a capability to know the multiple data formats that may be required to keep the
system integrated. As such, when data is received discretely, or on a continuous basis, from each
of the individual vehicle systems 100-180, the data conversion unit 245 may be available to
individually translate the data to be usable by each of the other individual vehicle systems 100-
180, or may establish a common data format to be shared among the individual vehicle systems
100-180. As may be appropriate, a data verification unit 250 may be separately provided to
monitor the data conversion occurring in the data conversion unit 245 in order to attempt to
ensure that seamless integration occurs, and to reduce and/or substantially eliminate errors due
to, for example, data corruption. ")
[provide the server] with the abstracted information as [information for
determining whether the application program is downloadable;] (Wainwright [0048], "In
various exemplary embodiments, one or both of a controller 220 and/or a processor 225 may be
provided to coordinate the individual functions of the interface unit 200. Such control and/or
processing may include coordination of data or other inputs received via one or more of the data
interfaces 210 [with the abstracted information as information], a user interface 215, a communication interface 255 and/or a sensor coordination interface 260. In addition, the
processor 225 may provide computational tasks such as mathematic and algorithmic processing
for the purpose of controlling or directing external vehicle systems as a mission computer. As
such, all processing and control of the functionalities of the interface unit 200 may be
coordinated by such individual control and processing units 220, 225.")
wherein the in-vehicle device is configured to download the application program in
response to a determination by the server that the application program is usable in the in-vehicle device and to execute the obtained application program after downloading. (Wainwright [0053], "In various exemplary embodiments, the interface unit 200 is provided with
a capability to update a configuration of the interface unit 200 itself, or to be provided with
information on updates, upgrades, or modifications to, as well as replacement of, any one of the
vehicle systems 100-180, or individual components in, or associated with such systems, via, for
example, a configuration update unit 240. It is envisioned that compatible software to update the
capability by which the interface unit 200 may continue to provide a seamless integration and
translation capability between individual vehicle systems 100-180 may be provided through such
a configuration update unit 240 [the in-vehicle device is configured to download the application
program in response to a determination that the application program is usable in the in-vehicle
device] and may be stored, for example, in a data storage unit 235, or input via one or more of
the interfaces or in communication directly from the affected vehicle system in this regard,
any manner by which updating software and/or circuitry may need to be incorporated within the
overall system is envisioned to be housed within, or provided for, with the exemplary interface
unit 200. Such an interface unit 200 is envisioned to encompass the single point source within
the overall integrated vehicle system to manage configuration of the vehicle system and to be updatable to continue to provide such capability [and to execute the obtained application
program after downloading] regardless of changes in individual components and/or individual
system within the integrated vehicle system.")
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Wainwright
into the teachings of Fukuyo in view of Dauber. This combination of teachings would have
resulted in a mobility providing service with a server and in-vehicle device to provide an
application and vehicle functionality information, as in Fukuyo, incorporating a system for
storing hardware requirements, additional peripheral information, and using the abstracted
information to determine application feasibility, as in Dauber, wherein the vehicle is capable of
converting communicating information from the vehicle in an independent format in order to
communicate information SO as to determine if the application is downloadable, as in
Wainwright. One of ordinary skill in the art would have been motivated to combine these
teachings for the purpose of providing digital or serial communications gateway for integration
of data exchange capabilities between vehicle control components (Wainwright [0020]).
The combination of Fukuyo, Dauber, and Wainwright teaches an in-vehicle device but does not teach: the [in-vehicle device] is configured to receive a notice of download refusal regarding the download of the application program in response to a determination that the application program is not usable in the [in-vehicle] device.
However, in an analogous art Quirk teaches the [in-vehicle] device is configured to receive a notice of download refusal regarding the download of the application program in response to a determination that the application program is not usable in the [in-vehicle] device. (Quirk [0054], “the in-vehicle device is configured to receive a notice of download refusal regarding the download of the application program in response to a determination that the application program is not usable in the in-vehicle device … Nevertheless, when the decision 342 determines that the application program would be compatible with the requesting device, download of the application program to the requesting device can be permitted 344. Alternatively, when the decision 342 determines that the application program would not be compatible with the requesting device, an error message can be returned 346 the application program is not compatible with requesting device. Following the blocks 344 and 346, the compatibility check process 340 can end.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Quirk into the teachings of Fukuyo in view of Dauber and further in view of Wainwright. This combination of teachings would have resulted in a mobility providing service with a server and in-vehicle device to provide an application and vehicle functionality information, as in Fukuyo, incorporating a system for storing hardware requirements, additional peripheral information, and using the abstracted information to determine application feasibility, as in Dauber, wherein the vehicle is capable of converting communicating information from the vehicle in an independent format in order to communicate information so as to determine if the application is downloadable, as in
Wainwright, and if the application is not downloadable generating a message indication of incompatibility, as in Quirk. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of determining if the submitted application code is valid and indicating an error message if otherwise (Quirk [0045]).
With regards to claim 9, Fukuyo teaches
A mobility service providing system, comprising: a server configured to provide an
application program (Fukuyo [0030], "The server 100 is in one example a computer device,
such as a server or the like installed in a particular center or the like, and is capable of
transmitting respective update data to each of a plurality of vehicles, for updating software of in
vehicle devices of the vehicles. The server 100 includes a communication unit (communication
module) 111 for communicating with the software updating device 50 and a control unit 112 for controlling the communication unit 111. The functions of the control unit 112 are executed by
one or more processors, one or more microcontrollers, or the like. The server 1001s provided
with a storage unit that is omitted from illustration, and is also capable of externally accepting
and storing data for updating software for each of the in-vehicle devices") using a function of a
vehicle; (Fukuyo [0004], "Software that the processor executes (software) is stored in the
nonvolatile storage unit. Updating the software by rewriting to a newer version enables functions
of the in-vehicle devices to be improved and enhanced.")
an in-vehicle device installed in the vehicle and configured to obtain the application
program from the server and execute the obtained application program; (Fukuyo [0020],
"The network system 1 includes a software updating device 50. A plurality of busses 10, 20, 30
are connected to the software updating device (over-the-air (OTA) master) 50. A plurality of
in-vehicle devices (electronic control units (ECUs)) 11, 12 is connected to the bus 10. A
plurality of in-vehicle devices 21, 22 is connected to the bus 20. A plurality of actuators 31, 32
1s connected to the bus 30. Although in FIG. 1 and the following description, the busses 10,
20, and 30 are exemplified as busses, and the in-vehicle devices 11, 12, 21, and 22 and the
actuators 31 and 32 are exemplified as in-vehicle devices, the number thereof are not limiting.
Note that various types of sensors for acquiring the state of the vehicle and the surroundings of
the vehicle is connected to the busses 10, 20, and 30, and the in-vehicle devices 11, 12, 21, and
22 as appropriate.")
a first obtainer configured to obtain basic information that is information on the
function of the vehicle in which the in-vehicle device is installed; (Fukuyo [0035], "Usage
information is information representing the usage state of the vehicle. Usage information
includes, for example, the time when the vehicle was used in a plurality of times of the past, or average time thereof, and SO forth, although not limited to this. The time when the vehicle was
used is, for example, the time period that is from when the ignition is turned on until when the
ignition is turned off and in which the vehicle travels and stops. The usage information may
include information representing the frequency of usage of a plurality of functions of the vehicle,
for example. The frequency of usage of the functions of the vehicle is the number of times or the
like of user operations or the like enabling the functions making up advanced driver-assistance
systems (ADAS), such as lane centering, cruise control, automated braking, proximity warning,
and SO forth, during a predetermined number of times of traveling in the past, for example.
Further, usage information may include information generated based on a traveling plan set to
the vehicle. A traveling plan is a traveling route to a destination that is currently set to an
automotive navigation system, which is one of the in-vehicle devices, for example, and the usage
information is estimated required time to reach the destination calculated based on the traveling
plan, for example. The control unit 53 may acquire usage information generated by the in-vehicle
devices, or may generate usage information from information such as logs, traveling plans, and
so forth, acquired from the in-vehicle devices")
a usability determiner configured to determine, when a request for downloading the
application program from the server to the in-vehicle device is made, whether the
application program is usable in the in-vehicle device [by comparing (a) the hardware
requirement associated with the application program to be downloaded with (b) the
abstracted information possessed by the in-vehicle device to which the application program
is to be downloaded;] (Fukuyo [0025], "Control of installing is not limited to executing
installing alone, and may include a series of processing relating to installing, such as
determination regarding whether to execute installing, transfer of update data, verification of update-version software, and so forth [when a request for downloading the application program
from the server to the in-vehicle device is made]. Activating is processing of enabling
(activating) the installed update-version software. Control of activating is not limited to
executing activating alone, and may include a series of control relating to activating, such as
determination regarding whether to execute activating, verification of activation results, and so
forth [one of the server, the in-vehicle device, or the additional computing device is configured to determine. whether the application program is usable in the in-vehicle device]")
Fukuyo does not teach:
a requirement storage unit configured to store a hardware requirement required for
executing the application program;
a second obtainer configured to obtain additional information that is information on
a peripheral device detachably attached to the vehicle;
[a usability determiner configured to determine, when a request for downloading
the application program from the server to the in-vehicle device is made, whether the
application program is usable in the in-vehicle device] by comparing (a) the hardware
requirement associated with the application program to be downloaded with (b) the
abstracted information possessed by the in-vehicle device to which the application program
is to be downloaded;
However, in an analogous art Dauber teaches a requirement storage unit configured to
store a hardware requirement required for executing the application program; (Dauber
[0018-19], "The following example illustrates an implementation scenario associated with a
technical entity providing infrastructure sizing to a client for determining necessary hardware to
run new software across multiple environments. The scenario is initiated when the technical entity determines the following two options for sizing the client's hardware requirements:
software and licensing requirements and technical infrastructure specifications based on software
needs. If the client specifies software needs and requires infrastructure specifications, system 100
may be accessed via client login credentials for execution of an associated software tool When
system 100 has automatically run all necessary scripts, associated data is uploaded into a project
folder. Subsequently, automated check boxes are presented adjacent to associated data collection
points that have been successfully uploaded to the project folder. The technical entity and client
are able to view an audit trail associated with a time period within the sizing process.
Subsequently, 3 differing algorithms and associated code are executed for providing the
infrastructure sizing for determining necessary hardware to run new software across multiple
environments.")
a second obtainer configured to obtain additional information that is information on
a peripheral device detachably attached to the vehicle; (Dauber FIG 5; and [0015-0017],
"The specialized discrete non-generic analog, digital, and logic-based circuitry (e.g.,
sensors/circuitry/logic 12, self-learning software/hardware code/engines/scripts 28, etc.) may
include proprietary specially designed components (e.g., a specialized integrated circuit, such as
for example an Application Specific Integrated Circuit (ASIC) designed for only implementing
an automated process for improving software technology associated with cross-referencing
metrics associated with plug-in components, generating software code modules, and enabling
operational functionality of target cloud components. Sensors/circuitry/logic 12 may include any
type of internal or external sensors including, inter alia, GPS sensors, Bluetooth beaconing
sensors, cellular telephone detection sensors, Wi-Fi positioning detection sensors, triangulation
detection sensors, activity tracking sensors, a temperature sensor, an ultrasonic sensor, an optical sensor, a video retrieval device, humidity sensors, voltage sensors, network traffic sensors, etc.
System 100 is configured to be expanded via usage of additional plug-ins for every version and
hardware combination. Likewise, system 100 assembles collected data from all of plug-in
components for summarizing existing software and hardware infrastructure environments.
System 100 will additionally run a data collection script with respect to an existing environment
resulting in output generation")
[a usability determiner configured to determine, when a request for downloading
the application program from the server to the in-vehicle device is made, whether the
application program is usable in the in-vehicle device] by comparing (a) the hardware
requirement associated with the application program to be downloaded with (b) the
abstracted information possessed by the in-vehicle device to which the application program
is to be downloaded; (Dauber [0002], "cross-referencing, by the processor, the metrics data with
respect to operational sizing recommendations for each plug-in component of the plurality of
plug-in components based on aggregated disparate sizing guidelines [by comparing the hardware
requirement associated with the application program to be downloaded with (b) the abstract
information possessed by the in-vehicle device]; generating, by the processor, software code
modules associated with results of the cross-referencing; determining, by the processor based on
results of executing the software code modules, software and hardware requirements for enabling
target computing components; and enabling, by the processor based on the software and
hardware requirements, operational functionality of the target computing components [to which
the application program is to be downloaded] in accordance with the software and hardware
requirements.")
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Dauber into
the teachings of Fukuyo. This combination of teachings would have resulted in a mobility
providing service with a server and in-vehicle device to provide an application and vehicle
functionality information, as in Fukuyo, incorporating a server system to store system application
requirements and the means to determine application compatibility, as in Dauber, One of
ordinary skill in the art would have been motivated to combine these teachings for the purpose of
a method and associated system for cross-referencing metrics associated with plug-in
components, generating software code modules, and enabling operational functionality of target
cloud/computing components (Dauber [0001]).
The combination of Fukuyo and Dauber does not teach:
an abstractor configured to-convert the basic information and the additional
information that is the information on the peripheral device detachably attached to the
vehicle into abstracted information, the abstracted information being information in a
common format independent from the vehicle and the peripheral device;
wherein the in-vehicle device is configured to download the application program in
response to a determination that the application program is usable in the in-vehicle device
and to execute the obtained application program after downloading.
However, in an analogous art Wainwright teaches an abstractor configured to-convert
the basic information and the additional information that is the information on the
peripheral device detachably attached to the vehicle into abstracted information, the
abstracted information being information in a common format independent from the
vehicle and the peripheral device; (Wainwright [0043], "In various exemplary embodiments, a data interface 210 may be provided [that is the information on the peripheral device] as one or
more available input/output ports to facilitate communication with one or more of the vehicle
systems 100-180 via available connection means, including wired or wireless means [detachably
attached to the vehicle]. When the data interface is connected for wired communications, such
data interface 210 may comprise one or more ports according to MIL-STD-1553, RS-232, RS-
422, RS-485, ARINC 429, Ethernet, Discrete and/or Analog I/O ports. Any manner by which
compatible data interaction may be facilitated between one or more of the vehicle systems 100-
180 and the interface unit 200 via such data interface 210 is contemplated. ") and (Wainwright
[0056], "Resident within the interface unit 200 in, for example, a data conversion unit 245, may
be a capability to know the multiple data formats that may be required to keep the system
integrated. As such, when data is received discretely, or on a continuous basis, from each of the
individual vehicle systems 100-180, the data conversion unit 245 may be available to
individually translate the data to be usable by each of the other individual vehicle systems 100-
180, or may establish a common data format to be shared among the individual vehicle systems
100-180 [into abstracted information, the abstracted information being information in a common
format independent from the vehicle and the peripheral device]. As may be appropriate, a data
verification unit 250 may be separately provided to monitor the data conversion occurring in the
data conversion unit 245 in order to attempt to ensure that seamless integration occurs, and to
reduce and/or substantially eliminate errors due to, for example, data corruption. ") and
wherein the in-vehicle device is configured to download the application program in
response to a determination that the application program is usable in the in-vehicle device
and to execute the obtained application program after downloading. (Wainwright [0053],
"In various exemplary embodiments, the interface unit 200 is provided with a capability to
update a configuration of the interface unit 200 itself, or to be provided with information on
updates, upgrades, or modifications to, as well as replacement of, any one of the vehicle systems
100-180, or individual components in, or associated with such systems, via, for example, a
configuration update unit 240. It is envisioned that compatible software to update the capability
by which the interface unit 200 may continue to provide a seamless integration and translation
capability between individual vehicle systems 100-180 may be provided through such a
configuration update unit 240 [the in-vehicle device is configured to download the application
program in response to a determination that the application program is usable in the in-vehicle
device] and may be stored, for example, in a data storage unit 235, or input via one or more of
the interfaces or in communication directly from the affected vehicle system in this regard,
any manner by which updating software and/or circuitry may need to be incorporated within the
overall system is envisioned to be housed within, or provided for, with the exemplary interface
unit 200. Such an interface unit 200 is envisioned to encompass the single point source within
the overall integrated vehicle system to manage configuration of the vehicle system and to be
updatable to continue to provide such capability [and to execute the obtained application
program after downloading] regardless of changes in individual components and/or individual
system within the integrated vehicle system.")
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Wainwright
into the teachings of Fukuyo in view of Dauber. This combination of teachings would have
resulted in a mobility providing service with a server and in-vehicle device to provide an
application and vehicle functionality information, as in Fukuyo, incorporating a system for
storing hardware requirements, additional peripheral information, and using the abstracted
information to determine application feasibility, as in Dauber, wherein the vehicle is capable of
converting communicating information from the vehicle in an independent format in order to
communicate information so as to determine if the application is downloadable, as in
Wainwright. One of ordinary skill in the art would have been motivated to combine these
teachings for the purpose of providing digital or serial communications gateway for integration
of data exchange capabilities between vehicle control components (Wainwright [0020]).
The combination of Fukuyo, Dauber, and Wainwright teaches an in-vehicle device but does not teach: the [in-vehicle device] is configured to receive a notice of download refusal regarding the download of the application program in response to a determination that the application program is not usable in the [in-vehicle] device.
However, in an analogous art Quirk teaches the [in-vehicle] device is configured to receive a notice of download refusal regarding the download of the application program in response to a determination that the application program is not usable in the [in-vehicle] device. (Quirk [0054], “the in-vehicle device is configured to receive a notice of download refusal regarding the download of the application program in response to a determination that the application program is not usable in the in-vehicle device … Nevertheless, when the decision 342 determines that the application program would be compatible with the requesting device, download of the application program to the requesting device can be permitted 344. Alternatively, when the decision 342 determines that the application program would not be compatible with the requesting device, an error message can be returned 346 the application program is not compatible with requesting device. Following the blocks 344 and 346, the compatibility check process 340 can end.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Quirk into the teachings of Fukuyo in view of Dauber and further in view of Wainwright. This combination of teachings would have resulted in a mobility providing service with a server and in-vehicle device to provide an application and vehicle functionality information, as in Fukuyo, incorporating a system for storing hardware requirements, additional peripheral information, and using the abstracted information to determine application feasibility, as in Dauber, wherein the vehicle is capable of converting communicating information from the vehicle in an independent format in order to communicate information so as to determine if the application is downloadable, as in
Wainwright, and if the application is not downloadable generating a message indication of incompatibility, as in Quirk. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of determining if the submitted application code is valid and indicating an error message if otherwise (Quirk [0045]).
With regards to claim 10, Fukuyo teaches
An in-vehicle device obtaining from a server and executing an application program
for performing a process (Fukuyo [0030], "The server 100 is in one example a computer
device, such as a server or the like installed in a particular center or the like, and is capable of
transmitting respective update data to each of a plurality of vehicles, for updating software of in
vehicle devices of the vehicles. The server 100 includes a communication unit (communication
module) 111 for communicating with the software updating device 50 and a control unit 112 for
controlling the communication unit 111. The functions of the control unit 112 are executed by
one or more processors, one or more microcontrollers, or the like. The server 1001s provided
with a storage unit that is omitted from illustration, and is also capable of externally accepting
and storing data for updating software for each of the in-vehicle devices") using a function of a
vehicle; (Fukuyo [0004], "Software that the processor executes (software) is stored in the
nonvolatile storage unit. Updating the software by rewriting to a newer version enables functions
of the in-vehicle devices to be improved and enhanced.") the in-vehicle device comprising:
a first obtainer configured to obtain basic information that is information on the
function of the vehicle in which the in-vehicle device is installed; (Fukuyo [0035], "Usage information is information representing the usage state of the vehicle. Usage information
includes, for example, the time when the vehicle was used in a plurality of times of the past, or
average time thereof, and so forth, although not limited to this. The time when the vehicle was
used is, for example, the time period that is from when the ignition is turned on until when the
ignition is turned off and in which the vehicle travels and stops. The usage information may
include information representing the frequency of usage of a plurality of functions of the vehicle,
for example. The frequency of usage of the functions of the vehicle is the number of times or the
like of user operations or the like enabling the functions making up advanced driver-assistance
systems (ADAS), such as lane centering, cruise control, automated braking, proximity warning,
and SO forth, during a predetermined number of times of traveling in the past, for example.
Further, usage information may include information generated based on a traveling plan set to
the vehicle. A traveling plan is a traveling route to a destination that is currently set to an
automotive navigation system, which is one of the in-vehicle devices, for example, and the usage
information is estimated required time to reach the destination calculated based on the traveling
plan, for example. The control unit 53 may acquire usage information generated by the in-vehicle
devices, or may generate usage information from information such as logs, traveling plans, and
so forth, acquired from the in-vehicle devices")
a provider configured to provide the server [with the abstracted information as information] for determining whether the application program is downloadable; (Fukuyo
[0023], "Also, the control unit 53 of the software updating device 50 controls and relays
communication between the server 100 and the in-vehicle devices 11, 12, 21, and 22,
communication among the in-vehicle devices 11, 12, 21, and 22, and communication between
the in-vehicle devices 11, 12, 21, and 22 and the actuators 31 and 32, over the busses 10, 20, and 30. Thus, the software updating device 50 also functions as a relay device that relays
communication. Alternatively, the software updating device 50 may be provided as a part of such
a relay device, or may be connected to one of the busses 10, 20, and 30 separately from such a
relay device.") and (Fukuyo [0025], "The control unit 53 of the software updating device 50 is
capable of updating software stored in the second storage unit of each of the in-vehicle devices
11, 12, 21, and 22. That is to say, the software updating device 50 performs control of
downloading, control of installing, and further control of activating. Downloading is processing
of receiving and storing update data (distribution package) for updating software of one of the in-vehicle devices 11, 12, 21, and 22 that has been transmitted from the server 100. Control of
downloading is not limited to executing downloading alone, and may include a series of control
of processing relating to downloading, such as determination regarding whether to execute
downloading, verification of update data, and so forth. Installing is processing of writing update version software (updating software) in the second storage unit of the in-vehicle device that is
the target of updating, based on the downloaded update data. Control of installing is not limited
to executing installing alone, and may include a series of processing relating to installing, such as
determination regarding whether to execute installing, transfer of update data, verification of
update-version software, and so forth.")
Fukuyo does not teach:
a second obtainer configured to obtain additional information that is information on
a peripheral device detachably attached to the vehicle;
However, in an analogous art Dauber teaches a second obtainer configured to obtain
additional information that is information on a peripheral device detachably attached to
the vehicle; (Dauber FIG 5; and [0015-0017], "The specialized discrete non-generic analog, digital, and logic-based circuitry (e.g., sensors/circuitry/logic 12, self-learning software/hardware
code/engines/scripts 28, etc.) may include proprietary specially designed components (e.g., a
specialized integrated circuit, such as for example an Application Specific Integrated Circuit
(ASIC) designed for only implementing an automated process for improving software
technology associated with cross-referencing metrics associated with plug-in components,
generating software code modules, and enabling operational functionality of target cloud
components. Sensors/circuitry/logic 12 may include any type of internal or external sensors
including, inter alia, GPS sensors, Bluetooth beaconing sensors, cellular telephone detection
sensors, Wi-Fi positioning detection sensors, triangulation detection sensors, activity tracking
sensors, a temperature sensor, an ultrasonic sensor, an optical sensor, a video retrieval device,
humidity sensors, voltage sensors, network traffic sensors, etc. System 100 is configured to be
expanded via usage of additional plug-ins for every version and hardware combination.
Likewise, system 100 assembles collected data from all of plug-in components for summarizing
existing software and hardware infrastructure environments. System 100 will additionally run a
data collection script with respect to an existing environment resulting in output generation")
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Dauber into
the teachings of Fukuyo. This combination of teachings would have resulted in a mobility
providing service with a server and in-vehicle device to provide an application and vehicle
functionality information, as in Fukuyo, incorporating a server system to store system application
requirements and the means to determine application compatibility, as in Dauber, One of
ordinary skill in the art would have been motivated to combine these teachings for the purpose of
a method and associated system for cross-referencing metrics associated with plug-in components, generating software code modules, and enabling operational functionality of target
cloud/computing components (Dauber [0001]).
The combination of Fukuyo and Dauber does not teach:
an abstractor configured to convert the basic information and the additional
information that is the information on the peripheral device detachable attached to the
vehicle into abstracted information, the abstracted information being information in a
common format independent from vehicle and the peripheral device;
[and a provider configured to provide the server] with the abstracted information as
information [for determining whether the application program is downloadable;]
However, in an analogous art Wainwright teaches an abstractor configured to convert
the basic information and the additional information that is the information on the
peripheral device detachable attached to the vehicle into abstracted information, the
abstracted information being information in a common format independent from vehicle
and the peripheral device; (Wainwright [0043], "In various exemplary embodiments, a data
interface 210 may be provided [that is the information on the peripheral device] as one or more
available input/output ports to facilitate communication with one or more of the vehicle systems
100-180 via available connection means, including wired or wireless means [detachably attached
to the vehicle]. When the data interface is connected for wired communications, such data
interface 210 may comprise one or more ports according to MIL-STD-1553, RS-232, RS-422,
RS-485, ARINC 429, Ethernet, Discrete and/or Analog I/O ports. Any manner by which
compatible data interaction may be facilitated between one or more of the vehicle systems 100-
180 and the interface unit 200 via such data interface 210 is contemplated.) and (Wainwright
[0056], "Resident within the interface unit 200 in, for example, a data conversion unit 245, may
be a capability to know the multiple data formats that may be required to keep the system
integrated. As such, when data is received discretely, or on a continuous basis, from each of the
individual vehicle systems 100-180, the data conversion unit 245 may be available to
individually translate the data to be usable by each of the other individual vehicle systems 100-
180, or may establish a common data format to be shared among the individual vehicle systems
100-180 [into abstracted information, the abstracted information being information in a common
format independent from the vehicle and the peripheral device]. As may be appropriate, a data
verification unit 250 may be separately provided to monitor the data conversion occurring in the
data conversion unit 245 in order to attempt to ensure that seamless integration occurs, and to
reduce and/or substantially eliminate errors due to, for example, data corruption. ") and
[and a provider configured to provide the server] with the abstracted information as
information [for determining whether the application program is downloadable;]
(Wainwright [0048], "In various exemplary embodiments, one or both of a controller 220 and/or
a processor 225 may be provided to coordinate the individual functions of the interface unit 200.
Such control and/or processing may include coordination of data or other inputs received via one
or more of the data interfaces 210 [with the abstracted information as information], a user
interface 215, a communication interface 255 and/or a sensor coordination interface 260. In
addition, the processor 225 may provide computational tasks such as mathematic and algorithmic
processing for the purpose of controlling or directing external vehicle systems as a mission
computer. As such, all processing and control of the functionalities of the interface unit 200 may
be coordinated by such individual control and processing units 220, 225.") wherein the in-vehicle device is configured to download the application program in response to a determination by the server that the application program is usable in the vehicle device and to execute the obtained application program after downloading. (Wainwright [0053], "In various exemplary embodiments, the interface unit 200 is provided with a capability to update a configuration of the interface unit 200 itself, or to be provided with information on updates, upgrades, or modifications to, as well as replacement of, any one of the vehicle systems 100-180, or individual components in, or associated with such systems, via, for example, a configuration update unit 240. It is envisioned that compatible software to update the capability by which the interface unit 200 may continue to provide a seamless integration and translation capability between individual vehicle systems 100-180 may be provided through such a configuration update unit 240 [the in-vehicle device is configured to download the application program in response to a determination that the application program is usable in the in-vehicle device] and may be stored, for example, in a data storage unit 235, or input via one or more of the interfaces or in communication directly from the affected vehicle system In this regard, any manner by which updating software and/or circuitry may need to be incorporated within the overall system is envisioned to be housed within, or provided for, with the exemplary interface unit 200. Such an interface unit 200 is envisioned to encompass the single point source within the overall integrated vehicle system to manage configuration of the vehicle system and to be updatable to continue to provide such capability [and to execute the obtained application program after downloading] regardless of changes in individual components and/or individual system within the integrated vehicle system.")
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Wainwright
into the teachings of Fukuyo in view of Dauber. This combination of teachings would have
resulted in a mobility providing service with a server and in-vehicle device to provide an application and vehicle functionality information, as in Fukuyo, incorporating a system for
storing hardware requirements, additional peripheral information, and using the abstracted
information to determine application feasibility, as in Dauber, wherein the vehicle is capable of
converting communicating information from the vehicle in an independent format in order to
communicate information so as to determine if the application is downloadable, as in
Wainwright. One of ordinary skill in the art would have been motivated to combine these
teachings for the purpose of providing digital or serial communications gateway for integration
of data exchange capabilities between vehicle control components (Wainwright [0020]).
The combination of Fukuyo, Dauber, and Wainwright teaches an in-vehicle device but does not teach: the [in-vehicle device] is configured to receive a notice of download refusal regarding the download of the application program in response to a determination that the application program is not usable in the [in-vehicle] device.
However, in an analogous art Quirk teaches the [in-vehicle] device is configured to receive a notice of download refusal regarding the download of the application program in response to a determination that the application program is not usable in the [in-vehicle] device. (Quirk [0054], “the in-vehicle device is configured to receive a notice of download refusal regarding the download of the application program in response to a determination that the application program is not usable in the in-vehicle device … Nevertheless, when the decision 342 determines that the application program would be compatible with the requesting device, download of the application program to the requesting device can be permitted 344. Alternatively, when the decision 342 determines that the application program would not be compatible with the requesting device, an error message can be returned 346 the application program is not compatible with requesting device. Following the blocks 344 and 346, the compatibility check process 340 can end.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Quirk into the teachings of Fukuyo in view of Dauber and further in view of Wainwright. This combination of teachings would have resulted in a mobility providing service with a server and in-vehicle device to provide an application and vehicle functionality information, as in Fukuyo, incorporating a system for storing hardware requirements, additional peripheral information, and using the abstracted information to determine application feasibility, as in Dauber, wherein the vehicle is capable of converting communicating information from the vehicle in an independent format in order to communicate information so as to determine if the application is downloadable, as in
Wainwright, and if the application is not downloadable generating a message indication of incompatibility, as in Quirk. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of determining if the submitted application code is valid and indicating an error message if otherwise (Quirk [0045]).
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Fukuyo in view of
Dauber in view of Wainwright in view of Quirk and further in view of US 20190141159 Al hereinafter "Kagara".
With regards to claim 2, Fukuyo further teaches
wherein the in-vehicle device is configured to obtain the basic information [and the
additional information] and to determine whether the application is usable in the in-vehicle
device, (Fukuyo [0035], "Usage information is information representing the usage state of the
vehicle. Usage information includes, for example, the time when the vehicle was used in a
plurality of times of the past, or average time thereof, and so forth, although not limited to this.
The time when the vehicle was used is, for example, the time period that is from when the
ignition is turned on until when the ignition is turned off and in which the vehicle travels and
stops. The usage information may include information representing the frequency of usage of a
plurality of functions of the vehicle, for example. The frequency of usage of the functions of the
vehicle is the number of times or the like of user operations or the like enabling the functions making up advanced driver-assistance systems (ADAS), such as lane centering, cruise control,
automated braking, proximity warning, and so forth, during a predetermined number of times of
traveling in the past, for example. Further, usage information may include information generated
based on a traveling plan set to the vehicle. A traveling plan is a traveling route to a destination
that is currently set to an automotive navigation system, which is one of the in-vehicle devices,
for example, and the usage information is estimated required time to reach the destination
calculated based on the traveling plan, for example. The control unit 53 may acquire usage
information generated by the in-vehicle devices, or may generate usage information from
information such as logs, traveling plans, and so forth, acquired from the in-vehicle devices")
(Fukuyo [0025], "Control of installing is not limited to executing installing alone, and may
include a series of processing relating to installing, such as determination regarding whether to
execute installing, transfer of update data, verification of update-version software, and SO forth.
Activating is processing of enabling (activating) the installed update-version software. Control of
activating is not limited to executing activating alone, and may include a series of control
relating to activating, such as determination regarding whether to execute activating, verification
of activation results, and so forth")
Fukuyo does not explicitly teach:
[wherein the in-vehicle device is configured to obtain the basic information] and the
additional information [and to determine whether the application is usable in the in-vehicle
device], the server is configured to store the hardware requirement
However, in an analogous art Dauber teaches [wherein the in-vehicle device is
configured to obtain the basic information] and the additional information [and to
determine whether the application is usable in the in-vehicle device], (Dauber FIG 5; and
[0015-0017], "The specialized discrete non-generic analog, digital, and logic-based circuitry
(e.g., sensors/circuitry/logic 12, self-learning software/hardware code/engines/scripts 28, etc.)
may include proprietary specially designed components (e.g., a specialized integrated circuit,
such as for example an Application Specific Integrated Circuit (ASIC) designed for only
implementing an automated process for improving software technology associated with cross referencing metrics associated with plug-in components, generating software code modules, and
enabling operational functionality of target cloud components. Sensors/circuitry/logic 12 may
include any type of internal or external sensors including, inter alia, GPS sensors, Bluetooth
beaconing sensors, cellular telephone detection sensors, Wi-Fi positioning detection sensors,
triangulation detection sensors, activity tracking sensors, a temperature sensor, an ultrasonic
sensor, an optical sensor, a video retrieval device, humidity sensors, voltage sensors, network
traffic sensors, etc. System 100 is configured to be expanded via usage of additional plug-ins
for every version and hardware combination. Likewise, system 100 assembles collected data
from all of plug-in components for summarizing existing software and hardware infrastructure
environments. System 100 will additionally run a data collection script with respect to an
existing environment resulting in output generation")
the server is configured to store the hardware requirement (Dauber [0018-19], "The
following example illustrates an implementation scenario associated with a technical entity
providing infrastructure sizing to a client for determining necessary hardware to run new
software across multiple environments. The scenario is initiated when the technical entity
determines the following two options for sizing the client's hardware requirements: software and
licensing requirements and technical infrastructure specifications based on software needs. If the
client specifies software needs and requires infrastructure specifications, system 100 may be
accessed via client login credentials for execution of an associated software tool When system
100 has automatically run all necessary scripts, associated data is uploaded into a project folder.
Subsequently, automated check boxes are presented adjacent to associated data collection points
that have been successfully uploaded to the project folder. The technical entity and client are able
to view an audit trail associated with a time period within the sizing process. Subsequently, 3
differing algorithms and associated code are executed for providing the infrastructure sizing for
determining necessary hardware to run new software across multiple environments.")
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Dauber into
the teachings of Fukuyo. This combination of teachings would have resulted in a mobility
providing service with a server and in-vehicle device to provide an application and vehicle
functionality information, as in Fukuyo, incorporating a server system to store system application
requirements and the means to determine application compatibility, as in Dauber, One of
ordinary skill in the art would have been motivated to combine these teachings for the purpose of
a method and associated system for cross-referencing metrics associated with plug-in
components, generating software code modules, and enabling operational functionality of target
cloud/computing components (Dauber [0001]).
The combination of Fukuyo and Dauber does not teach
and determine whether the application to convert the basic information and the
additional information into abstracted information,
However, in an analogous art Wainwright teaches and determine whether the
application to convert the basic information and the additional information into abstracted
information, (Wainwright [0055], "In various exemplary embodiments one or both of a data
conversion unit 245 and a data verification unit 250 may be provided to receive data input from
one or more of the vehicle systems 100-180 via, for example, a data interface 210, and may
convert that data as appropriate under control of the controller 220 and/or the processor 225, and
based possibly on information stored in the data storage unit 235, to make data input from any
one of the individual vehicle systems 100-180 compatible for output to, and use by, one or more
of the other vehicle systems 100-180 [the application to convert the basic information and the
additional information into abstracted information]. Such data conversion may be continuously
updated based on information provided via a configuration update unit 240 and stored in a data
storage unit 235 such that individual components may be upgraded without degrading an
integration capability of the overall vehicle system of systems simply by ensuring that the
interface unit 200 is provided with data and programming necessary to maintain the translating
and integrating function of the integrating unit 200 as individual components within individual
vehicle systems, or a system architecture of the vehicle in total, are modified. Conventional
means by which data may be translated between individual, differing, and potentially noncompatible formats is envisioned to be included within one or more of the data conversion unit 245 and/or the data verification unit 250 of the interface unit 200.")
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Wainwright
into the teachings of Fukuyo in view of Dauber. This combination of teachings would have
resulted in a mobility providing service with a server and in-vehicle device to provide an
application and vehicle functionality information, as in Fukuyo, incorporating a system for
storing hardware requirements, additional peripheral information, and using the abstracted
information to determine application feasibility, as in Dauber, wherein the vehicle is capable of
converting communicating information from the vehicle in an independent format in order to
communicate information so as to determine if the application is downloadable, as in
Wainwright. One of ordinary skill in the art would have been motivated to combine these
teachings for the purpose of providing digital or serial communications gateway for integration
of data exchange capabilities between vehicle control components (Wainwright [0020]).
The combination of Fukuyo, Dauber, Wainwright, and Quirk does not teach:
one of the server, the in-vehicle device, or the additional computing device is the
mobility service providing system further includes an information synchronizer configured
to synchronize the abstracted information between the in-vehicle device and the server.
However, in an analogous art Kagara teaches one of the server, the in-vehicle device, or
the additional computing device is the mobility service providing system further includes
an information synchronizer configured to synchronize the abstracted information between
the in-vehicle device and the server. (Kagara [0019], "The information communication device
10 includes a communication device 11, a processor 12, and a memory resource 13 as hardware
resources. A communication program referred to as a data manager 14 and data 15 scheduled to
be synchronized between the information communication devices 10, 20, 30 are stored in the
memory resource 13... The processor 12 transmits the data 15 to the information communication
devices 20, 30 through the communication device 11 by interpreting and executing the data
manager 14 to synchronize the data 15 between the information communication devices 10, 20,
30. A timing of synchronizing the data 15 may be, for example, set by an interval of a
predetermined constant period or a timing at which a predetermined event occurs. In a case
where the data 15 is the probe data, it is desirable to share the latest probe data between the
information communication devices 10, 20,30 by synchronizing the data 15 at the interval of the
constant period.")
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Kagara into
the teachings of Fukuyo in view of Dauber in view of Wainwright and further in view of Quirk. This combination of teachings would have resulted in a mobility providing service with a server and in-vehicle device to provide an application and vehicle functionality information, as in Fukuyo, incorporating a system for storing hardware requirements, additional peripheral information, and using the abstracted information to determine application feasibility, as in Dauber, wherein the vehicle is capable of converting communicating information from the vehicle in an independent format in order to communicate information so as to determine if the application is downloadable, as in Wainwright, and if the application is not downloadable generating a message indication of incompatibility, as in Quirk, and finally incorporating a unit for synchronizing data between the server and the in-vehicle device, as in Kagara. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of providing a means of synchronizing the latest data between a plurality of information computing devices (Kagara [0017]).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Fukuyo in view of
Dauber in view of Wainwright in view of Quirk and further in view of US 20080031139 A1 hereinafter "Muro".
With regards to claim 5, the rejection of claim 1 is incorporated.
Fukuyo further teaches wherein the basic information is obtained at least when the in-vehicle device is activated for a first time, (Fukuyo [0031], "This processing is typically started
in a state in which the power of the vehicle is on (ignition on, power on). Specifically, this
processing may be stared at a timing when the power of the vehicle is turned on") [Examiner
Note: Processing includes the step/method of obtaining additional information including vehicle
information each time (including the first time) the in-vehicle device is activated]
The combination of Fukuyo, Dauber, and Wainwright does not teach:
the additional information is obtained every time the in-vehicle device is activated.
However, in an analogous art Muro teaches the additional information is obtained
every time the in-vehicle device is activated. (Muro [0137], "The operation mode table 140
holds, as shown in FIG. 8, a mode 141 for sending observation information and a condition 142
for sending observation information as an event. Set as the mode 141 are an intermittent type
mode in which observation information is sent each time the CPU 103 is activated intermittently,
an event-driven type mode in which only observation information that meets the condition 142 is
sent, and other modes")
Therefore, it would have been obvious to one of ordinary skill in the art to have
incorporated the teachings of Muro into the teachings of Fukuyo in view of Dauber
in view of Wainwright and further in view of Quirk. This combination of teachings would have resulted in a mobility providing service with a server and in-vehicle device to provide an application and vehicle functionality information, as in Fukuyo, incorporating a system for storing hardware requirements, additional peripheral information, and using the abstracted information to determine application feasibility, as in Dauber, wherein the vehicle is capable of converting communicating information from the vehicle in an independent format in order to communicate information so as to determine if the application is downloadable, as in Wainwright, and if the application is not downloadable generating a message indication of incompatibility, as in Quirk, wherein the additional peripheral information is obtained each time the event is triggered including when the CPU/in-vehicle device is activated, as in Muro. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of ensuring urgent and beneficial information is transferred or obtained without being lost (Muro [0014]).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Fukuyo in view of
Dauber in view of Wainwright in view of Quirk and further in view of US 20110202905 A1 hereinafter "Mahajan".
With regards to claim 6, the rejection of claim 1 is incorporated.
The combination of Fukuyo, Dauber, and Wainwright does not teach:
one of the server, the in-vehicle device or the additional computing device is
configured to set the abstracted information via an external input.
However, in an analogous art Mahajan teaches one of the server, the in-vehicle device
or the additional computing device is configured to set the abstracted information via an
external input. (Mahajan [0030], "FIG. 3 is of a data flow diagram illustrating aspects of
application programming interface ("API") call abstraction in some embodiments of the SNAM.
In some implementations, a developer 301 may contemplate modifications to a code module
utilized by a multi-user social networking application. The developer 301 operating workstation
302 may provide input code 31 including such modifications to update such a code module.
For example, the developer may input a code module including commands similar to the
exemplary listing provided below. In some implementations, the input code may include
references to other code/application modules in order to provide the desired capabilities of the
updated code module. For example, the references may include API calls to other
code/application modules. An exemplary listing illustrating substantive aspects of including an
API call within a code module,")
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Mahajan into
the teachings of Fukuyo in view of Dauber in view of Wainwright and further in view of Quirk. This combination of teachings would have resulted in a mobility providing service with a server and in-vehicle device to provide an application and vehicle functionality information, as in Fukuyo, incorporating a system for storing hardware requirements, additional peripheral information, and using the abstracted information to determine application feasibility, as in Dauber, wherein the vehicle is capable of converting communicating information from the vehicle in an independent format in order to communicate information so as to determine if the application is downloadable, as in Wainwright, and if the application is not downloadable generating a message indication of incompatibility, as in Quirk, with a unit for the user to set the abstract information itself, as in Mahajan. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of using Application programming interfaces ("APIs") to allow programmers and users to access various libraries of software code where many systems are based on various web programming codes and APIs (Mahajan [0007]).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Dauber, in view of
Fukuyo, and further in view of Wainwright.
With regards to claim 8, Dauber teaches
A usability determination method for determining usability of an application program in an in-vehicle device that is installed in a vehicle, the application program for performing a process using a function of the vehicle, (Dauber FIG 2) the method comprising:
additional information that is information on a peripheral device detachably
attached to the installed vehicle; (Dauber FIG 5; and [0015-0017], "The specialized discrete
non-generic analog, digital, and logic-based circuitry (e.g., sensors/circuitry/logic 12, self-learning software/hardware code/engines/scripts 28, etc.) may include proprietary specially
designed components (e.g., a specialized integrated circuit, such as for example an application
Specific Integrated Circuit (ASIC) designed for only implementing an automated process for
improving software technology associated with cross-referencing metrics associated with plug-in
components, generating software code modules, and enabling operational functionality of target
cloud components. Sensors/circuitry/logic 12 may include any type of internal or external
sensors including, inter alia, GPS sensors, Bluetooth beaconing sensors, cellular telephone
detection sensors, Wi-Fi positioning detection sensors, triangulation detection sensors, activity
tracking sensors, a temperature sensor, an ultrasonic sensor, an optical sensor, a video retrieval
device, humidity sensors, voltage sensors, network traffic sensors, etc. System 10 is configured
to be expanded via usage of additional plug-ins for every version and hardware combination.
Likewise, system 100 assembles collected data from all of plug-in components for summarizing
existing software and hardware infrastructure environments. System 100 will additionally run a
data collection script with respect to an existing environment resulting in output generation")
determining usability of the application program in the in-vehicle device by
comparing a hardware requirement required for executing the application program that
was designated and the abstracted information possessed by the in-vehicle device that
executes the application program. (Dauber [0002], "cross-referencing, by the processor, the
metrics data with respect to operational sizing recommendations for each plug-in component of
the plurality of plug-in components based on aggregated disparate sizing guidelines [by
comparing a hardware requirement required for executing the application program that was
designated and the abstracted information possessed by the in-vehicle device that executes the
application program]; generating, by the processor, software code modules associated with
results of the cross-referencing; determining, by the processor based on results of executing the
software code modules, software and hardware requirements for enabling target computing
components; and enabling, by the processor based on the software and hardware requirements,
operational functionality of the target computing components [for which the application program
is to be downloaded] in accordance with the software and hardware requirements.")
Dauber does not teach
obtaining basic information that is information on the function of the vehicle in
which the in-vehicle device is installed;
However, in an analogous art Fukuyo teaches obtaining basic information that is
information on the function of the vehicle in which the in-vehicle device is installed;
(Fukuyo [0035], "Usage information is information representing the usage state of the vehicle.
Usage information includes, for example, the time when the vehicle was used in a plurality of
times of the past, or average time thereof, and so forth, although not limited to this. The time
when the vehicle was used is, for example, the time period that is from when the ignition is
turned on until when the ignition is turned off and in which the vehicle travels and stops. The
usage information may include information representing the frequency of usage of a plurality of
functions of the vehicle, for example. The frequency of usage of the functions of the vehicle is
the number of times or the like of user operations or the like enabling the functions making up
advanced driver-assistance systems (ADAS), such as lane centering, cruise control, automated
braking, proximity warning, and so forth, during a predetermined number of times of traveling in
the past, for example. Further, usage information may include information generated based on a
traveling plan set to the vehicle. A traveling plan is a traveling route to a destination that is
currently set to an automotive navigation system, which is one of the in-vehicle devices, for
example, and the usage information is estimated required time to reach the destination calculated
based on the traveling plan, for example. The control unit 53 may acquire usage information
generated by the in-vehicle devices, or may generate usage information from information such as
logs, traveling plans, and so forth, acquired from the in-vehicle devices")
Therefore, it would have been obvious before the effective filing date of the claimed
invention to have incorporated the teachings of Fukuyo into the teachings of Dauber. This
combination of teachings would have resulted in a usability determination method obtaining
additional peripheral information, as in Dauber, and obtaining vehicle functionality information,
as in Fukuyo. One of ordinary skill in the art would have been motivated to combine these
teachings for the purpose of exchanging messages between devices to undertake vehicle
functionality (Fukuyo [0003]).
The combination of Dauber and Fukuyo does not teach:
converting the basic information and the additional information that is the information on the peripheral device detachably attached to the vehicle into abstracted information, the abstracted information being in a common format independent from the vehicle and the peripheral device;
downloading, with the in-vehicle device, the application program in response to a
determination that the application is usable in the in-vehicle device, and
executing, with the in-vehicle device, the application program after downloading.
However, in an analogous art Wainwright teaches converting the basic information and
the additional information that is the information on the peripheral device detachably
attached to the vehicle into abstracted information, the abstracted information being in a
common format independent from the vehicle and the peripheral device; (Wainwright
[0043], "In various exemplary embodiments, a data interface 210 may be provided [that is the
information on the peripheral device] as one or more available input/output ports to facilitate
communication with one or more of the vehicle systems 100-180 via available connection
means, including wired or wireless means [detachably attached to the vehicle]. When the data
interface is connected for wired communications, such data interface 210 may comprise one or
more ports according to MIL-STD-1553, RS-232, RS-422, RS-485, ARINC 429, Ethernet,
Discrete and/or Analog I/O ports. Any manner by which compatible data interaction may be
facilitated between one or more of the vehicle systems 100-180 and the interface unit 200 via
such data interface 210 is contemplated. ") and (Wainwright [0056], "Resident within the
interface unit 200 in, for example, a data conversion unit 245, may be a capability to know the
multiple data formats that may be required to keep the system integrated. As such, when data is
received discretely, or on a continuous basis, from each of the individual vehicle systems 100-
180, the data conversion unit 245 may be available to individually translate the data to be usable
by each of the other individual vehicle systems 100-180, or may establish a common data format
to be shared among the individual vehicle systems 100-180 [into abstracted information, the
abstracted information being information in a common format independent from the vehicle and
the peripheral device]. As may be appropriate, a data verification unit 250 may be separately
provided to monitor the data conversion occurring in the data conversion unit 245 in order to
attempt to ensure that seamless integration occurs, and to reduce and/or substantially eliminate
errors due to, for example, data corruption. ")
downloading, with the in-vehicle device, the application program in response to a
determination that the application is usable in the in-vehicle device, and
executing, with the in-vehicle device, the application program after downloading.
(Wainwright [0053], "In various exemplary embodiments, the interface unit 200 is provided with a capability to update a configuration of the interface unit 200 itself, or to be provided with information on updates, upgrades, or modifications to, as well as replacement of, any one of the vehicle systems 100-180, or individual components in, or associated with such systems, via, for example, a configuration update unit 240. It is envisioned that compatible software to update the capability by which the interface unit 200 may continue to provide a seamless integration and translation capability between individual vehicle systems 100-180 may be provided through such a configuration update unit 240 [downloading, with the in-vehicle device, the application program in response to a determination that the application is usable in the in-vehicle device] and may be stored, for example, in a data storage unit 235, or input via one or more of the interfaces or in communication directly from the affected vehicle system. In this regard, any manner by which updating software and/or circuitry may need to be incorporated within the overall system is envisioned to be housed within, or provided for, with the exemplary interface unit 200. Such an interface unit 200 is envisioned to encompass the single point source within the overall integrated vehicle system to manage configuration of the vehicle system and to be updatable to continue to provide such capability [executing, with the in-vehicle device, the
application program after downloading] regardless of changes in individual components and/or
individual system within the integrated vehicle system.")
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Wainwright
into the teachings of Dauber in view of Fukuyo. This combination of teachings would have
resulted in a usability determination method obtaining additional peripheral information, as in
Dauber, and obtaining vehicle functionality information, as in Fukuyo, wherein the vehicle is
capable of converting communicating information from the vehicle in an independent format in
order to communicate information SO as to determine if the application is downloadable, as in
Wainwright. One of ordinary skill in the art would have been motivated to combine these
teachings for the purpose of providing digital or serial communications gateway for integration
of data exchange capabilities between vehicle control components (Wainwright [0020]).
The combination of Fukuyo, Dauber, and Wainwright teaches an in-vehicle device but does not teach: the [in-vehicle device] is configured to receive a notice of download refusal regarding the download of the application program in response to a determination that the application program is not usable in the [in-vehicle] device.
However, in an analogous art Quirk teaches the [in-vehicle] device is configured to receive a notice of download refusal regarding the download of the application program in response to a determination that the application program is not usable in the [in-vehicle] device. (Quirk [0054], “the in-vehicle device is configured to receive a notice of download refusal regarding the download of the application program in response to a determination that the application program is not usable in the in-vehicle device … Nevertheless, when the decision 342 determines that the application program would be compatible with the requesting device, download of the application program to the requesting device can be permitted 344. Alternatively, when the decision 342 determines that the application program would not be compatible with the requesting device, an error message can be returned 346 the application program is not compatible with requesting device. Following the blocks 344 and 346, the compatibility check process 340 can end.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Quirk into the teachings of Dauber in view of Fukuyo and further in view of Wainwright. This combination of teachings would have resulted in a usability determination method obtaining additional peripheral information, as in Dauber, and obtaining vehicle functionality information, as in Fukuyo, wherein the vehicle is capable of converting communicating information from the vehicle in an independent format in order to communicate information SO as to determine if the application is downloadable, as in Wainwright, and if the application is not downloadable generating a message indication of incompatibility, as in Quirk. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of determining if the submitted application code is valid and indicating an error message if otherwise (Quirk [0045]).
Allowable Subject Matter
Claims 11-12 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.
Response to Arguments
Applicant Argues:
the usability determiner does not generate a software code module and does not execute such a software code module to make a determination of anything, as is described in the cited Dauber reference. Rather, in the present application, a determination of usability is made by comparing (a) the hardware requirement associated with the application program to be downloaded with (b) the abstracted information possessed by the in-vehicle device to which the application program is to be downloaded.
Examiner’s Response:
Examiner Respectfully disagrees. The Dauber reference describes the cross-referencing component to generate software. The cross-referencing is performed in the reference in order to determine generation, which can encompass the process of downloading software. Thus, the current rejection under 35 U.S.C. 103 is proper and therefore maintained.
Applicant’s arguments with respect to claims 1-10 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Sui (US 20230393966 A1) teaches a software releasing method that comprises: acquiring a software identifier contained in a software combination; in each first period, selecting a target software for each software identifier from a plurality of candidate software that have passed a functional test to generate a first software group which is to be subjected to an integration test in a computing device; in each second period, selecting at least one software group from a plurality of said first software groups that have passed the integration test in the corresponding period as a second software group which is to be subjected to an integration test of a next second period in the computing device; and in each second period, taking the second software group that has passed the integration test as the software combination to be released.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TRAVIS VIET TRAN whose telephone number is (571)272-3720. The examiner can normally be reached Monday-Friday 8:30AM-5PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Wei Mui can be reached at 571-272-3708. 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.
/T.V.T./ Examiner, Art Unit 2191
/WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights