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-4, and 6-15 are rejected under 35 U.S.C. 103 as being unpatentable over Holden et al. (US-20100235454-A1), herein after will be referred to as Holden, in view of Richardson et al. (US-20160321452-A1), herein after will be referred to as Richardson.
Regarding Claim 1
Disclosure by Holden
Holden teaches:
A method
See at least (0154): "FIG. 15 is a flow diagram of process 1500 that can be executed by an application manager at a mobile computing device to establish and manage a session according to some embodiments of the invention."
Rationale: Holden’s “process 1500” that “can be executed” at the mobile computing device is a method.
of dynamically configuring
See at least (0119): "In response to detecting that an accessory is connected, the mobile computing device can request that the accessory provide its supported application protocols…"
Rationale: Because the steps occur “In response to detecting” that the accessory is connected, Holden teaches of dynamically configuring.
one of a first vehicle or a first vehicle accessory
See at least (0031): "For example, accessory 113 can be any device capable of communicating with mobile computing device 102 such as, for example, … an automobile; an automobile accessory (e.g., a car stereo system or car navigation system) …"
Rationale: Holden expressly places the disclosure in a context including “an automobile” and “an automobile accessory,” corresponding to one of a first vehicle or a first vehicle accessory.
to interact with
See at least (0154): "…process 1500 … to establish and manage a session …"
Rationale: “establish and manage a session” is interaction behavior consistent with to interact with.
one of another vehicle or another vehicle accessory,
See at least (0031): "… accessory 113 can be any device … such as … an automobile; an automobile accessory (e.g., a car stereo system or car navigation system) …"
Rationale: Holden’s “accessory” expressly includes “an automobile” and “an automobile accessory,” corresponding to one of another vehicle or another vehicle accessory.
the method comprising;
See at least (0154): "FIG. 15 is a flow diagram of process 1500 … Process 1500 can start …"
Rationale: A “flow diagram of process 1500” with multiple blocks corresponds to the method comprising.
Detecting,
See at least (0118): "Process 700 can start at block 702, where the mobile computing device can detect whether an accessory has been connected." ([0118])
Rationale: Holden expressly teaches Detecting (“can detect whether an accessory has been connected”).
by the first vehicle or first vehicle accessory,
See at least (0118): "… where the mobile computing device can detect whether an accessory has been connected."
Rationale: The “mobile computing device” performs the detecting, satisfying by the first vehicle or first vehicle accessory.
the other vehicle or other vehicle accessory
See at least (0118): "… detect whether an accessory has been connected."
Rationale: The “accessory” is the detected counterpart, satisfying the other vehicle or other vehicle accessory.
prior to the first vehicle or first vehicle accessory being physically attached to the other vehicle or vehicle accessory
See at least (0118): "An accessory might be physically coupled to the mobile computing device by using … a connector. In other cases, the accessory might be wirelessly coupled to the mobile computing device."
Rationale: Holden expressly teaches “wirelessly coupled” as an alternative to “physically coupled,” supporting prior to … being physically attached.
and responsive to the first vehicle or first vehicle accessory detecting the other vehicle or other vehicle accessory:
See at least (0119): "In response to detecting that an accessory is connected, the mobile computing device can request that the accessory provide its supported application protocols." ([0119])
Rationale: Holden expressly teaches the “In response to detecting” condition, satisfying and responsive to … detecting ….
receiving,
See at least (0119): "… request that the accessory provide its supported application protocols." ([0119])
Rationale: The accessory “provide” its supported application protocols in response to the request, satisfying receiving in the connection workflow.
by the first vehicle or first vehicle accessory,
See at least (0119): "… the mobile computing device can request …"
Rationale: The step is performed at the “mobile computing device,” satisfying by the first vehicle or first vehicle accessory.
an application identifier
See at least (0129): "… include an identifier of a preferred application for use with the accessory. This identifier might be a URL … a unique product identifier for the preferred application in a particular application store …"
Rationale: Holden expressly discloses “an identifier of a preferred application,” satisfying an application identifier.
from the other vehicle or other vehicle accessory
See at least (0129): "… the accessory information provided to the mobile computing device can include an identifier of a preferred application …"
Rationale: The “accessory information” is “provided” by the accessory, satisfying from the other vehicle or other vehicle accessory.
for an application
See at least (0129): "… an identifier of a preferred application …" ([0129])
Rationale: Holden’s identifier is explicitly “of a preferred application,” satisfying for an application.
to be executed on the first vehicle or first vehicle accessory
See at least (0135): "… the compatible application can be launched, thereby enabling the accessory and the compatible application to communicate."
Rationale: Holden teaches the “compatible application can be launched” on the host side, satisfying to be executed on the first vehicle or first vehicle accessory.
to access functionality associated with
See at least (0135): "… thereby enabling the accessory and the compatible application to communicate." ([0135])
Rationale: “enabling … to communicate” corresponds to using the application to access functionality associated with the other device/accessory.
a corresponding application executable on the other vehicle or other vehicle accessory;
See at least (0131): "… the compatible application may already be available on the mobile computing device, or a compatible application may be pre-stored on the accessory itself."
Rationale: Holden expressly teaches a “compatible application … pre-stored on the accessory itself,” supporting a corresponding application executable on the other vehicle or other vehicle accessory.
processing the application identifier and/or downloaded authenticated application
See at least (0129): "… This identifier might be a URL … a unique product identifier …" ([0129])
Rationale: Holden’s “identifier … URL … product identifier” is used in Holden’s acquisition flow, supporting processing the application identifier.
to determine one or more configuration settings
See at least (0093): "… an application protocol name 335 (e.g., “com.Holden.temp”) can be stored in a protocol lookup table 340. … use of a reverse domain name in the application protocol name 335 can ensure uniqueness …"
Rationale: Storing the “application protocol name” in the “protocol lookup table” reflects determining settings used for subsequent interaction, satisfying to determine one or more configuration settings.
for the first vehicle or first vehicle accessory;
See at least (0093): "… can be stored in a protocol lookup table 340."
Rationale: The “protocol lookup table” is on the host side (mobile computing device), satisfying for the first vehicle or first vehicle accessory
and reconfiguring the first vehicle or first vehicle accessory
See at least (0154): "… process 1500 … to establish and manage a session …" ([0154])
Rationale: Establishing/managing the session reflects changing the operating state of the host for the accessory, satisfying reconfiguring the first vehicle or first vehicle accessory.
by applying the one or more configuration settings
See at least (0093): "… can be stored in a protocol lookup table 340." ([0093])
Rationale: The act of storing the protocol identifier in the lookup table reflects applying those settings, satisfying by applying the one or more configuration settings.
to the first vehicle or first vehicle accessory;
See at least (0093): "… can be stored in a protocol lookup table 340." ([0093])
Rationale: The “stored” configuration is in the host-side table, satisfying to the first vehicle or first vehicle accessory.
responsive to subsequently physically attaching
See at least (0053): "Connection can be achieved by physical attachment, for example, between respective mating connectors of mobile computing device 200 and accessory 202. Alternatively, connection can be achieved by a wireless connection." ([0053])
Rationale: Holden expressly teaches “physical attachment” as a connection mechanism, supporting responsive to subsequently physically attaching in the connection-responsive workflow.
the first vehicle or first vehicle accessory
See at least (0053): "… between respective mating connectors of mobile computing device 200 and accessory 202." ([0053])
Rationale: The “mobile computing device 200” is one of the physically attached entities, satisfying the first vehicle or first vehicle accessory.
to the other vehicle or other vehicle accessory:
See at least (0053): "… between respective mating connectors of mobile computing device 200 and accessory 202." ([0053])
Rationale: The “accessory 202” is the other entity, satisfying to the other vehicle or other vehicle accessory.
loading the application; and
See at least (0131): "In one embodiment, the compatible application can be installed immediately upon downloading." ([0131])
Rationale: Holden’s “installed … upon downloading” supports that the application is placed on-device for use, satisfying loading the application; and in the acquisition/installation flow.
executing the application.
See at least (0135): "… the compatible application can be launched …" ([0135])
Rationale: Holden expressly teaches the application “can be launched,” satisfying executing the application.
Claim Limitations Not Explicitly Disclosed by Holden
Holden does not explicitly teach:
authenticating the application identifier
by using information determined from the application identifier
to determine if the application can be loaded onto the first vehicle or first vehicle accessory
from a trusted application source,
and if so,
automatically downloading the authenticated application
from the trusted application source;
Disclosure by Richardson
Richardson teaches:
authenticating the application identifier
See at least (0041): "… receiving … a first application identifier and a first source identifier … setting … a first state designation … values including trusted and untrusted …"
Rationale: Richardson evaluates a “first application identifier” and assigns a “state designation” including “trusted” and “untrusted,” satisfying authenticating the application identifier.
by using information determined from the application identifier
See at least (0143): "In one embodiment, the first source identifier is based on a signature of the first application."
Rationale: Richardson ties the “first source identifier” to the “signature of the first application,” satisfying by using information determined from the application identifier for authentication/validation.
to determine if the application can be loaded onto the first vehicle or first vehicle accessory
See at least (0086): " In various embodiments, a mobile device on which an application is being installed stores state data. The state data includes a mobile device state and an application state for each application stored on or installed on the mobile device. The mobile device state may have values including trusted, untrusted, and unknown. The state of unknown indicates that a determination has not yet been made whether the mobile device is trusted or untrusted, or that an event has occurred on the device which could require re-assessment and could change the mobile device state. application having a state of untrusted will, for example, not be executed"
Rationale: Richardson’s trusted/untrusted state controls whether the application proceeds to execution, supporting to determine if the application can be loaded onto the first vehicle or first vehicle accessory as part of allow/deny handling.
from a trusted application source,
See at least (0042): "… determine whether the first source identifier matches a white list of source identifiers (e.g. a list of trusted channel identifiers) …" ([0042])
Rationale: Richardson expressly describes a whitelist as “a list of trusted channel identifiers,” satisfying from a trusted application source.
and if so,
See at least (0042): "… determine whether the first source identifier matches a white list … or … matches a black list …" ([0042])
Rationale: The whitelist/blacklist evaluation reflects conditional handling, satisfying and if so.
automatically downloading the authenticated application
See at least (Holden, 0131): "In one embodiment, the compatible application can be installed immediately upon downloading." ([0131])
See at least (Richardson, 0042): "… white list of source identifiers (e.g. a list of trusted channel identifiers) …" ([0042])
Rationale: Given Holden’s “installed immediately upon downloading” acquisition flow and Richardson’s trusted-channel gate (“white list … trusted channel identifiers”), automatically downloading the authenticated application (i.e., initiating the download upon the trusted determination without further user action) would have been an obvious and predictable implementation choice to a PHOSITA to achieve the same established function—obtaining the compatible application—while applying the trusted-source requirement.
from the trusted application source;
See at least (0354): "If the source of the information of “channel ID” is calling “getInstallerPackageName()”, then there will typically be a non-null answer only for Google Play or the Amazon store or the Samsung store… If the actual source of the app can be determined as the network location or URL used to download the app, than that network location is the source ID or channel ID for the application."
Rationale: Richardson ties the “network location or URL used to download the app” to the “source ID or channel ID” and distinguishes trusted vs untrusted, satisfying from the trusted application source.
Motivation to Combine Holden and Richardson
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Holden and Richardson before them, to modify Holden’s accessory-provided “identifier of a preferred application … a URL … a unique product identifier … in a particular application store” workflow by incorporating Richardson’s “white list … trusted channel identifiers” and “trusted/untrusted” state designation based on “source identifier” (including “network location or URL used to download the app”), because Holden’s workflow uses externally supplied accessory information to locate/install/launch an application, which predictably implicates the known security problem of preventing loading/execution of applications from untrusted sources, and Richardson teaches the compatible and established solution of authenticating the application/source identifiers using identifier-derived information and permitting downstream install/execute behavior only when the application source is trusted, yielding the predictable result of trusted-source application provisioning for accessory interaction.
Regarding Claim 2
The combination of Holden and Richardson establishes the method of Claim 1, which is the basis for Claim 2.
Disclosure by Holden
Holden teaches:
wherein the one or more vehicle configuration settings
See at least (0095): "In some embodiments, based on the received application protocol information, the mobile computing device can populate port map 325, accessory information table 330 and/or other lookup tables (e.g., application protocol information table 340) (FIG. 3)."
Rationale: Holden expressly describes that, “based on the received application protocol information,” the device “can populate … lookup tables,” which are the claimed one or more vehicle configuration settings.
reconfigures one or more internal system settings
See at least (0095): "… the mobile computing device can populate port map 325, accessory information table 330 and/or other lookup tables (e.g., application protocol information table 340) (FIG. 3)." ([0095])
Rationale: As established, “populate … lookup tables” on the device is a change to internal stored operational data structures, i.e., reconfigures one or more internal system settings.
and/or external interfaces
See at least (0079): "In some embodiments, mobile computing device 200 can associate specific application protocols with specific ports 305. For example, in some embodiments, mobile computing device 200 can maintain a dynamic port map 325 that identifies the network location (e.g., port address, port number, etc.) of each currently connected accessory…" ([0079])
Rationale: Holden expressly ties protocol association to “specific … ports” and “network location (e.g., port address, port number, etc.),” which are external communication interfaces, thus meeting and/or external interfaces.
to enable the first vehicle or first vehicle accessory
See at least (0079): "… mobile computing device 200 can associate specific application protocols with specific ports 305. …"
Rationale: The “mobile computing device 200” is the platform being configured (the host device side), thus meeting to enable the first vehicle or first vehicle accessory.
to: load the application;
See at least (0131): "In some embodiments, applications can be installed immediately upon downloading." ([0131])
Rationale: Holden expressly states applications “can be installed immediately upon downloading,” which places the application onto the device for use, satisfying to: load the application;.
execute the application;
See at least (0134): "At block 722, the compatible application can be launched." ([0134])
Rationale: Holden expressly recites the application “can be launched,” which satisfies execute the application;.
and communicate with the other vehicle or other vehicle accessory.
See at least (0135): "At block 724, the application can communicate with the accessory." ([0135])
Rationale: Holden expressly states the application “can communicate with the accessory,” satisfying and communicate with the other vehicle or other vehicle accessory.
Motivation to Combine Holden and Richardson
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Holden and Richardson before them, to implement Claim 2’s dependent limitations in the combined Claim 1 method by applying Richardson’s trusted/untrusted source-designation gate to Holden’s accessory-driven workflow that (i) dynamically populates internal tables (e.g., “port map 325,” “accessory information table 330,” and “other lookup tables”) and (ii) obtains/installs/launches the compatible application and communicates with the accessory, because Holden’s workflow predictably benefits from ensuring that any application obtained for accessory interaction is permitted to load/execute only when authenticated as sourced from a trusted channel, and Richardson provides the established, compatible mechanism for determining trusted/untrusted source status and controlling downstream execution, yielding the predictable result that the configuration settings and interface behavior enabling load/execute/communication are securely conditioned on trusted-source authentication.
Regarding Claim 3
The combination of Holden and Richardson establishes the method of Claim 1, which is the basis for Claim 3.
Disclosure by Holden
Holden teaches:
further comprising the first vehicle or first vehicle accessory:
See at least (0154): "… executed by an application manager at a mobile computing device…"
Rationale: Holden’s “mobile computing device” performs the additional further comprising the first vehicle or first vehicle accessory operations.
loading the application;
See at least (0134): "… If not, the application can be launched at block 722."
Rationale: Loading the application is an inherent and predictable prerequisite to “launched,” as launching an application necessarily entails loading it for execution.
executing the application;
See at least (0068): "… an application executing on mobile computing device 200 can include program code that when executed by processor 230, can control, interface with, interoperate with, and/or receive signals from the accessory specific hardware 275 at accessory 202."
Rationale: Holden expressly recites executing the application (“an application executing on mobile computing device 200”).
establishing a data communications link with the other vehicle or other vehicle accessory;
See at least (0154): "… executed by an application manager at a mobile computing device to establish and manage a session …"; "… has created a session 406 … Session 406 can provide, among other things, an input stream and an output stream whose contents are, respectively, received from and delivered to application 404." ([0095])
Rationale: Holden’s “session” that is “establish[ed] and manage[d]” and that provides “input stream” / “output stream” constitutes establishing a data communications link with the other vehicle or other vehicle accessory.
and accessing functionality of the corresponding application
See at least (0068): "… the application executing on mobile computing device 200 can exchange messages with a control program executing on controller 260 of accessory 202, thereby instructing controller 260 to communicate with and/or control operation of accessory specific hardware 275." ([0068])
Rationale: Exchanging messages with the accessory-side “control program” to instruct operation reflects accessing functionality of the corresponding application (i.e., functionality provided via the accessory-side program).
when the corresponding application is executing
See at least (0068): "… exchange messages with a control program executing on controller 260 of accessory 202 …" ([0068])
Rationale: Holden expressly recites the accessory-side program is “executing,” satisfying when the corresponding application is executing.
on the other vehicle or other vehicle accessory
See at least (0068): "… a control program executing on controller 260 of accessory 202 …" ([0068])
Rationale: The “control program” is executing “on … accessory 202,” satisfying on the other vehicle or other vehicle accessory.
via the data communications link.
See at least (0095): "… Session 406 can provide, among other things, an input stream and an output stream whose contents are, respectively, received from and delivered to application 404."; "At block 724, the application can communicate with the accessory. In some embodiments, block 724 can include creating a session and sending and/or receiving application protocol commands via the session…" ([0135])
Rationale: Holden’s “session” used for “sending and/or receiving … via the session” provides the pathway via the data communications link.
Motivation to Combine Holden and Richardson
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Holden and Richardson before them, to incorporate Richardson’s trusted/untrusted source/channel identification control into Holden’s accessory-driven application identification / acquisition workflow, because Holden’s workflow obtains/uses applications responsive to accessory-provided information and Richardson teaches the compatible, well-known security mechanism of gating software load/execute based on whether the application/source is trusted, yielding the predictable result of secure application provisioning without changing Holden’s session-based communication operation.
Regarding Claim 4
The combination of Holden and Richardson establishes the method of Claim 1, which is the basis for Claim 4.
Disclosure by Holden
Holden teaches:
further comprising synchronizing the resulting first vehicle or first vehicle accessory reconfiguration
See at least (0040): "Asset management program 250 can synchronize the master database 232 with the database maintained on storage device 225 of mobile computing device 200. … Asset management program 250 can automatically synchronize the master database 232 with the database maintained on mobile computing device 200 …" ([0040])
Rationale: Holden expressly teaches “synchronize” and “automatically synchronize,” which corresponds to synchronizing the resulting reconfiguration state of the device produced by the Claim 1 workflow.
with a remote database of vehicle or vehicle accessory configuration records.
See at least (0040): "… host computer 20 maintains a master database 232 … Asset management program 250 can synchronize the master database 232 with the database maintained on storage device 225 of mobile computing device 200. … In addition, master database 232 can access other databases, for example, through the Internet. …"
Rationale: Holden expressly teaches a database maintained at “host computer 20” (“master database 232”) and also teaches access to “other databases … through the Internet,” i.e., a remote database relative to the mobile computing device. In the Claim 1 context (vehicle/vehicle accessory embodiments), the synchronized records correspond to configuration/state records associated with the device’s reconfiguration.
Motivation to Combine Holden and Richardson
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Holden and Richardson before them, to incorporate Richardson’s trusted/untrusted source-identification controls into Holden’s accessory-driven application identification/acquisition workflow (as mapped for Claim 1), because Holden’s workflow involves obtaining/using software in response to external accessory-provided information, which predictably raises the known security concern of preventing install/load/execute from untrusted sources, and Richardson teaches compatible allow/deny gating based on identifiers and trusted-channel/source determinations, yielding the predictable result of secure application provisioning while retaining Holden’s session establishment/management and synchronization behaviors for maintaining configuration/state consistency.
Regarding Claim 5
The combination of Holden and Richardson establishes the method of Claim 1, which is the basis for Claim 5.
Disclosure by Holden
Holden teaches:
further comprising: detecting, by the first vehicle or first vehicle accessory,
See at least (0118): “Process 700 can start at block 702, where the mobile computing device detects whether an accessory has been connected.”
Rationale: Holden teaches the method further comprising: detecting, by the first vehicle or first vehicle accessory, by disclosing block 702 where the host platform (e.g., a car navigation system) detects an accessory connection.
the other vehicle or other vehicle accessory
See at least (0031): “Accessory 113 can be any device capable of communicating with mobile computing device 102 such as, for example... an automobile; an automobile accessory (e.g., a car stereo system or car navigation system)...”
Rationale: Holden teaches that the detected entity is the other vehicle or other vehicle accessory by explicitly defining the accessory 113 as potentially being an automobile or automobile accessory.
prior to the first vehicle or first vehicle accessory being physically attached to the other vehicle or vehicle accessory;
See at least (0118): “In other cases, the accessory might be wirelessly coupled to the mobile computing device, e.g., by establishing a Bluetooth connection.”
Rationale: Holden teaches detecting the accessory prior to the first vehicle or first vehicle accessory being physically attached to the other vehicle or vehicle accessory; by disclosing a wireless coupling mode. Because wireless coupling occurs without mechanical mating, the detection and identification of the accessory are performed before any physical attachment occurs.
subsequently physically attaching the first vehicle or first vehicle accessory to the other vehicle or other vehicle accessory;
See at least (0053): “Connection can be achieved by physical attachment (e.g., between respective mating connectors of mobile computing device 200 and accessory 202)...”
Rationale: Holden teaches subsequently physically attaching the first vehicle or first vehicle accessory to the other vehicle or other vehicle accessory; by disclosing that the connection established after initial discovery can be achieved through physical attachment using mating connectors.
and responsive to subsequently physically attaching the first vehicle or first vehicle accessory to the other vehicle or other vehicle accessory:
See at least (0169): “...when an accessory connects with a mobile computing device... if preferred application is not executing on the application and is stored in memory at the mobile computing device, the application can be automatically launched.”
Rationale: Holden teaches that the launch occurs and responsive to subsequently physically attaching the first vehicle or first vehicle accessory to the other vehicle or other vehicle accessory: by disclosing that software execution (automatic launch) is triggered when the connection—which Holden defines as including physical attachment via mating connectors —is established.
loading the application;
See at least: “...the compatible application can be installed immediately upon downloading...” ([0131]); “...is stored in memory at the mobile computing device, the application can be automatically launched.” ([0169])
Rationale: Holden teaches loading the application; by disclosing the installation and storage of the software in device memory, which is a prerequisite for launching the application.
and executing the application.
See at least (0169): “...the application can be automatically launched.”
Rationale: Holden teaches and executing the application. by disclosing the automatic launching of the software process on the host device's processor.
Motivation to Combine Holden and Richardson
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Holden and Richardson before them, to incorporate the authentication gate of Richardson into the detection-to-attachment workflow of Holden. Holden teaches a multi-stage connection sequence where an accessory is discovered (wireless) and then used for interaction (physical attachment). Richardson teaches that whenever a device installs or executes software from an external source, it is essential to determine if that source is trusted to prevent the execution of malicious code. A PHOSITA would find it obvious to apply Richardson's trust determination to Holden's pre-attachment discovery phase. This combination ensures that during the time "prior to" physical attachment, the application identifier provided by the accessory is authenticated and the software is downloaded from a "trusted application source." This sequence allows the vehicle system to complete the time-intensive security and download tasks while the devices are still wirelessly coupled, so that the application is ready for "loading" and "executing" the moment the user "subsequently" completes the "physical attachment," yielding a secure and seamless user experience.
Regarding Claim 6
The combination of Holden and Richardson establishes the method of Claim 1, which is the basis for Claim 6.
Disclosure by Holden
Holden teaches:
wherein the application identifier
See at least (0129): “...in some embodiments, the accessory information provided to the mobile computing device at block 706 can include an identifier of a preferred application for use with the accessory. This identifier might be a URL... a unique product identifier for the preferred application in a particular application store, or the like.”
Rationale: Holden teaches wherein the application identifier is a product identifier or URL received from the accessory to identify the required software.
of a structured data object,
See at least (0120): “In some embodiments, the application protocol information can be sent in a metadata format.”; “...accessory information that includes meta-data specifying a preferred application.” ([0169])
Rationale: Holden teaches that the identifier is part of a structured data object by disclosing that the accessory provides information in a "metadata format." A metadata format is a structured collection of data fields.
wherein the structured data object includes meta-data
See at least (0169): “...the accessory can send accessory information that includes meta-data specifying a preferred application.”
Rationale: Holden expressly teaches wherein the structured data object includes meta-data by disclosing the use of metadata to specify the preferred software.
providing vehicle configuration data.
See at least (0119): “The information provided by the accessory can include... preferred initial operating states of the mobile computing device (e.g., whether audio and/or video signal exchange should initially be enabled or disabled, a preferred format for audio and/or video signaling, and so on).”; (0031): “Accessory 113 can be any device... such as, for example... an automobile; an automobile accessory (e.g., a car stereo system or car navigation system)...”
Rationale: Holden teaches providing vehicle configuration data. by disclosing that the accessory—which may be an automobile or automobile accessory—provides data defining "preferred initial operating states" and "preferred format[s]" for signaling. In the context of a vehicular host platform, these parameters configure the system's operational state for the interaction.
Claim Limitation Not Explicitly Disclosed by Holden
Holden does not explicitly teach:
is provided by a package name
Disclosure by Richardson
Richardson teaches:
is provided by a package name
See at least (0081): “An application identifier is also associated with the software for tracking data related to the application. In one embodiment, an application identifier is an identifier used to identify a particular application. Examples of such identifiers include an application package name, an application title and version...”
Rationale: Richardson teaches the application identifier is provided by a package name by explicitly listing "an application package name" as a type of application identifier used for software tracking and identification.
Motivation to Combine Holden and Richardson
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Holden and Richardson before them, to use the "application package name" taught by Richardson as the specific form of application identifier within the structured metadata object taught by Holden. Holden teaches a discovery process where an accessory provides metadata containing an identifier to help a host system locate the correct interaction software. Richardson teaches that application identifiers in mobile environments are commonly and effectively represented by "package names." A PHOSITA would find it obvious to use package names as the identifier within Holden’s metadata format because package names are the industry-standard way to uniquely identify software packages in structured computing environments (such as the Android and iOS ecosystems referenced in the prior art). Utilizing a package name ensures that the vehicular system can accurately and predictably identify, download, and launch the correct software associated with the detected vehicle or accessory, representing the use of a known type of identifier in a known metadata structure to achieve the predictable result of reliable software discovery.
Regarding Claim 7
The combination of Holden and Richardson establishes the method of Claim 1, which is the basis for Claim 7.
Disclosure by Holden
Holden teaches:
wherein the application identifier
See at least (0129): “...in some embodiments, the accessory information provided to the mobile computing device at block 706 can include an identifier of a preferred application for use with the accessory.”
Rationale: Holden teaches wherein the application identifier is the identifier of a preferred application provided by the accessory to the host platform.
of a structured data object,
See at least (0120): “In some embodiments, the application protocol information can be sent in a metadata format.”
Rationale: Holden teaches the identifier is part of a structured data object by disclosing that the protocol information is communicated in a metadata format, which represents a structured organization of data fields.
wherein the structured data object includes meta-data
See at least (0169): “...accessory information that includes meta-data specifying a preferred application.”
Rationale: Holden teaches wherein the structured data object includes meta-data by explicitly disclosing that the information sent from the accessory includes metadata used to specify the required software.
providing an address
See at least (0129): “This identifier might be a URL (uniform resource locator, e.g., a World Wide Web page address), a unique product identifier for the preferred application in a particular application store, or the like.”
Rationale: Holden teaches that the metadata is providing an address by disclosing that the identifier can be a URL or a World Wide Web page address.
for a source
See at least (0129): “The mobile computing device can use this information to locate the preferred application... For example, the mobile computing device can direct the user to an application store (e.g., the iTunes(R) Store provided by Holden Inc.) or other resource for purchasing and/or downloading applications.”
Rationale: Holden teaches the address is for a source by explaining that the URL or identifier is used to locate and obtain applications from an application store or other resource.
of vehicle configuration data.
See at least (0031): “Accessory 113 can be any device... such as, for example... an automobile; an automobile accessory (e.g., a car stereo system or car navigation system)...”; (0119): “The information provided by the accessory can include... preferred initial operating states of the mobile computing device (e.g., whether audio and/or video signal exchange should initially be enabled or disabled, a preferred format for audio and/or video signaling, and so on).”
Rationale: Holden teaches providing an address for a source of vehicle configuration data. by disclosing that the accessory—defined as an automobile accessory—provides metadata specifying "preferred initial operating states" and signaling formats for the mobile host. These operating parameters, retrieved via the provided address, constitute vehicle configuration data used to set up the host for interaction.
Claim Limitation Not Explicitly Disclosed by Holden
Holden does not explicitly teach:
is provided by a package name
Disclosure by Richardson
Richardson teaches:
is provided by a package name
See at least (0081): “An application identifier is also associated with the software for tracking data related to the application. In one embodiment, an application identifier is an identifier used to identify a particular application. Examples of such identifiers include an application package name, an application title and version...”
Rationale: Richardson teaches the application identifier is provided by a package name by explicitly listing "an application package name" as a type of identifier used to track and identify software.
Motivation to Combine Holden and Richardson
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Holden and Richardson before them, to use the "application package name" taught by Richardson as the specific form of "application identifier" within the "metadata format" taught by Holden. Holden teaches a discovery sequence where an accessory provides a metadata object containing an identifier (such as a URL) to help a host system locate a source for downloading software. Richardson teaches that application identifiers in modern mobile operating systems (which Holden's MCD exemplifies) are effectively uniquely identified by "package names." A PHOSITA would find it obvious to use a package name within Holden's structured metadata because package names are the art-recognized standard for uniquely identifying software entities across repositories. By utilizing a package name, the vehicle system can more reliably resolve the "address" (URL) to the correct software repository (the source), ensuring the "vehicle configuration data" (operating states) is retrieved from the intended provider, thereby achieving the predictable result of robust and accurate software discovery for accessory-specific interaction.
Regarding Claim 8
The combination of Holden and Richardson establishes the method of Claim 7, which is the basis for Claim 8.
Disclosure by Holden
Holden teaches:
wherein the address for the source of vehicle configuration datais provided as one of: a predefined service universally unique identifier, UUID, associated with the authenticated application;
See at least (0129): “... include an identifier of a preferred application for use with the accessory. This identifier might be ... a unique product identifier for the preferred application in a particular application store, or the like.”
Rationale: Is provided as one of: a predefined service universally unique identifier, UUID is met by Holden’s disclosure that the identifier “might be ... a unique product identifier ...”, i.e., a unique identifier that can serve as the claimed “UUID” option for the address; and the identifier is “for the preferred application”, i.e., associated with the ... application (with “authenticated” supplied by Richardson, below).
and a predefined service universal resource indicator, URI associated with the authenticated application.
See at least (0129): “... This identifier might be a URL (uniform resource locator, e.g., a World Wide Web page address), ...”
Rationale: A predefined service universal resource indicator, URI is met by Holden’s explicit disclosure of a “URL (uniform resource locator, e.g., a World Wide Web page address)”, i.e., a URI-type address option, and the identifier is again disclosed as being “of a preferred application”, i.e., associated with the ... application (with “authenticated” supplied by Richardson, below).
Claim Limitations Not Explicitly Disclosed by Holden
Holden does not explicitly teach:
associated with the authenticated application (as recited for each alternative)
Disclosure by Richardson
Richardson teaches:
associated with the authenticated application
See at least (0041): “... the state designation can be set to values including trusted and untrusted; ... receiving ... a first application identifier and a first source identifier ... for a first application ...”
Rationale: Associated with the authenticated application is met because Richardson explicitly provides an authentication/trust state (“trusted”) for an application and ties that state to “a first application identifier” for “a first application”; thus, when Holden’s “URL ...” option or “unique product identifier ...” option is used for an application that has been set to “trusted”, the claimed URI associated with the authenticated application or UUID associated with the authenticated application is satisfied.
Motivation to Combine Holden and Richardson
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Holden and Richardson before them, to use Holden’s disclosed application identifier formats (i.e., “a URL ...” or “a unique product identifier ...”) as the claimed address alternatives for the source associated with an application, while using Richardson’s disclosed application trust/state designation (“trusted”) to ensure that the identifier corresponds to (i.e., is associated with) an authenticated application, because both references address managing applications and their identifiers in a predictable, interoperable manner, and the substitution/association of known identifier types (URL/unique identifier) with a trusted/authenticated application state yields predictable results (i.e., an address/identifier bound to an authenticated application).
Regarding Claim 9,
Disclosure by Holden
Holden teaches:
A method
See at least: “FIG. 7 is a flow diagram of process 700 for identifying an accessory and compatible application …” (0018).
Rationale: The cited passage expressly describes an operational “process” with defined steps, which corresponds to the recited method.
of remotely causing reconfiguration
See at least: “The accessory can send a command to the mobile computing device specifying a second application to execute. … The mobile computing device can then execute the second application in response to receiving the command.” (0173).
Rationale: The cited passage expressly describes that a command originating from the accessory causes the mobile computing device to execute a different application, which corresponds to remotely causing reconfiguration.
of a first vehicle or vehicle accessory
See at least: “a mobile computing device 102 coupled with an accessory device 113 …” (0029).
Rationale: The cited passage expressly describes a first computing device and an accessory device in a coupled arrangement, which corresponds to the recited first vehicle or vehicle accessory only to the extent that the reference discloses a “mobile computing device” and an “accessory device,” but does not explicitly recite “vehicle.”
for interaction with another vehicle or another vehicle accessory,
See at least: “communication between accessory devices and a mobile computing device” (0026).
Rationale: The cited passage expressly describes interaction/communication between two distinct devices (an accessory device and a mobile computing device), which corresponds to interaction with another vehicle or another vehicle accessory.
the method comprising,
See at least: “Process 700 can start at block 702.” (0118).
Rationale: The cited passage expressly introduces a stepwise process with blocks/operations, which corresponds to the transitional “the method comprising.”
responsive to the other vehicle or other vehicle accessory detecting the first vehicle or first vehicle accessory:
See at least: “The mobile computing device can determine whether an accessory has been connected … block 704 can include detecting the opening of such a channel.” (0118).
Rationale: The cited passage expressly describes detection of connectivity/opening of a wired or wireless communication channel between the devices, which corresponds to detecting the other device as a condition precedent to subsequent operations.
transmitting, by the other vehicle or other vehicle accessory, an application identifier to the first vehicle or first vehicle accessory,
See at least: “At block 706, the mobile computing device can receive application protocol information from the accessory. … The information provided by the accessory can include text strings for the name(s) of the application communication protocol(s) supported by the accessory.” (0119).
Rationale: The cited passage expressly describes that the accessory provides protocol “name(s)” (i.e., identifying text strings) to the mobile computing device after connection detection, which corresponds to transmitting an application identifier to the first device.
the application identifier being associated with an application to be executed on the first vehicle or first vehicle accessory
See at least: “the accessory can specify that the preferred application must match an application at the mobile computing device and the preferred application must be downloaded to interact with the accessory” (0172).
Rationale: The cited passage expressly describes that the accessory’s provided information/metadata identifies a “preferred application” that must be present (downloaded) and used for interaction, which corresponds to the identifier being associated with an application to be executed on the first device.
to access functionality associated with a corresponding application
See at least: “Mobile computing device 200 can execute a temperature application … that communicates with a thermometer using the application protocol … to make temperature readings.” (0093).
Rationale: The cited passage expressly describes that executing the application and using the identified application protocol enables performance of device functionality (e.g., making temperature readings), which corresponds to accessing functionality associated with a corresponding application.
executable on the other vehicle or other vehicle accessory.
See at least: “an accessory can communicate with a mobile computing device using an accessory communication protocol” (0026).
Rationale: The cited passage expressly describes that the accessory participates in protocol-based operations required for the interaction; however, Holden does not explicitly recite that the other device includes a “corresponding application” that is “executable” on that other device.
Claim limitations Not Explicitly Disclosed by Holden
Holden does not explicitly teach:
of a first vehicle or vehicle accessory (to the extent “vehicle” is explicitly required)
executable on the other vehicle or other vehicle accessory. (to the extent “corresponding application executable on” the other device is explicitly required)
Disclosure by Richardson
Richardson teaches:
of a first vehicle or vehicle accessory
See at least: “In one embodiment, the first computing device is a vehicle … or a computing device that is embedded in a vehicle or other piece of machinery.” (0134).
Rationale: The cited passage expressly recites that the first computing device can be a vehicle or embedded in a vehicle, which supplies the explicit vehicle context not expressly recited in Holden.
executable on the other vehicle or other vehicle accessory.
See at least: “storing, by a first computing device, data for a plurality of applications associated with a second computing device … receiving, by the first computing device from the second computing device, a first application identifier …” (0135).
Rationale: The cited passage expressly describes applications associated with another computing device and exchange of a first application identifier between devices, which corresponds to the other device having an application context that is executable on that other device.
Motivation to Combine Holden and Richardson
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Holden and Richardson before them, to modify the inter-device interaction of Holden (in which a connected device provides protocol identifiers/metadata enabling selection/execution of an application for device-to-device interaction) to be implemented in the expressly vehicle-embedded computing device context of Richardson and to leverage Richardson’s multi-device application-identifier exchange framework, because both references are directed to interoperability between distinct computing devices via identifiers associated with applications, and adapting the known identifier-based device interaction techniques of Holden to vehicles/vehicle-embedded devices and to a multi-device application-identifier ecosystem would have yielded the predictable result of enabling compatible application-driven interactions between a vehicle/vehicle accessory and another device.
Regarding Claim 10
The combination of Holden and Richardson establishes the method of Claim 9, which is the basis for Claim 10.
Disclosure by Holden
Holden teaches:
wherein the application identifier is automatically sent in a message
See at least: “...Upon connection, the thermometer can identify its supported application protocol by sending … the reverse domain name … ‘com.temprus.thermometer1’. This reverse domain name can be sent to the mobile computing device using the accessory communication protocol...” ([0092]); “...To communicate a message … to accessory 402 … application 404 generates the message and writes it as data to an output stream of session 406...” ([0096]); “...Session 406 detects the presence of data in the output stream and sends a corresponding send (SND) instruction to protocol manager 410.” ([0097])
Rationale: Holden teaches the application identifier being sent by disclosing that, “Upon connection,” the accessory sends the reverse domain name “com.temprus.thermometer1” to the mobile computing device using the accessory communication protocol. Holden further teaches that communication occurs via a “message,” and that the sending is performed automatically by system components (e.g., “Session 406 detects … and sends …”), thereby meeting the requirement that the application identifier is automatically sent in a message.
responsive to the other vehicle or other vehicle accessory sensing the proximity of the first vehicle or vehicle accessory
See at least (0092): “...mobile computing device 200 can be wirelessly connected with a thermometer … Upon connection, the thermometer can identify its supported application protocol by sending … ‘com.temprus.thermometer1’...”
Rationale: Holden teaches responsiveness to the other vehicle/accessory sensing proximity by expressly tying the accessory’s sending behavior to “Upon connection,” where the thermometer (other vehicle/other vehicle accessory) acts when it becomes wirelessly connected to the mobile computing device (first vehicle/vehicle accessory), which is a proximity/connection condition that triggers the sending step.
Motivation to Combine Holden and Richardson
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Holden and Richardson before them, to implement the application identifier exchange of Holden in a manner that is automatically sent in a message responsive to the other vehicle/vehicle accessory sensing the proximity of the first vehicle/vehicle accessory, because both references are directed to device-to-device ecosystems in which automated communications are triggered by connection/proximity-related conditions to enable configuration and interoperability with predictable results. Holden teaches proximity/connection-triggered messaging behavior (“Upon connection… sending…”) and message-based transmission mechanics (“message…”, “Session… detects… and sends…”). Richardson teaches remote/fleet configuration paradigms that rely on automated, policy-driven device communications. A PHOSITA would have been motivated to combine these teachings so that, when proximity/connection is sensed/established between peer devices, the application identifier is automatically sent in a message to streamline configuration and application interoperability, yielding the predictable result of faster, reliable pairing and reconfiguration for interaction.
Regarding Claim 11
The combination of Holden and Richardson establishes the method of Claim 9, which is the basis for Claim 11.
Disclosure by Holden
Holden teaches:
further comprising automatically executing the corresponding application on the other vehicle or vehicle accessory
See at least (0068, 0163): “...can exchange messages with a control program executing on controller 260 of accessory 202... Process 1700 can start at block 1702, when an accessory becomes connected with the mobile computing device.” ([0068], [0163])
Rationale: Holden teaches further comprising automatically executing the corresponding application on the other vehicle or vehicle accessory by disclosing that the accessory-side "control program" or "Process 1700" (which corresponds to the claimed application) "can start" and execute on the accessory controller immediately upon the establishment of a connection. As an automated software response to a connection event, this constitutes automatic execution.
in response to the other vehicle or vehicle accessory being attached to the first vehicle or first vehicle accessory.
See at least (0163, 0053): “Process 1700 can start at block 1702, when an accessory becomes connected with the mobile computing device... Connection can be achieved by physical attachment (e.g., between respective mating connectors of mobile computing device 200 and accessory 202)...” ([0163], [0053])
Rationale: Holden teaches that the execution of the accessory-side software is in response to the other vehicle or vehicle accessory being attached to the first vehicle or first vehicle accessory. by disclosing that the connection event (block 1702), which serves as the trigger for the process to start, is achieved through "physical attachment" between the respective mating connectors of the devices.
Disclosure by Richardson
Richardson further reinforces the teachings:
further comprising automatically executing the corresponding application on the other vehicle or vehicle accessory
See at least (0015): “The attachment of the accessory to the user device or vice versa may trigger various actions, such as automatically executing certain software on the user device and/or the accessory.”
Rationale: Richardson teaches further comprising automatically executing the corresponding application on the other vehicle or vehicle accessory by explicitly disclosing that the "attachment" of an accessory—which Richardson defines as including a "vehicle"—triggers the "automatically executing" of software on the accessory itself.
in response to the other vehicle or vehicle accessory being attached to the first vehicle or first vehicle accessory.
See at least (0017): “In some embodiments, the user device and/or the accessory may perform one or more actions in response to being attached to each other. These actions may be referred to as an 'automatic response.' An automatic response may include, for example, executing an application...”
Rationale: Richardson teaches the step is performed in response to the other vehicle or vehicle accessory being attached to the first vehicle or first vehicle accessory. by describing an "automatic response" mechanism specifically triggered when the devices are "attached to each other."
Motivation to Combine Holden and Richardson
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Holden and Richardson before them, to utilize the automatic attachment-triggered execution logic of Richardson within the accessory interaction framework of Holden. Holden teaches a distributed vehicular environment where an accessory (Other) connects to a host system (First) to perform specialized tasks using a control program. Richardson teaches that in such environments, the "attachment" event should serve as a high-integrity hardware trigger to "automatically execute" corresponding software on the accessory or vehicle system. A PHOSITA would find it obvious to apply Richardson's automatic execution paradigm to Holden's system to ensure that the accessory's "corresponding application" (Process 1700) starts without manual user intervention the moment physical attachment is completed. This provides the predictable result of a seamless, plug-and-play experience where the hardware connection immediately and automatically activates the necessary interaction logic on both the vehicle system and the accessory, thereby improving operational efficiency in a modular vehicular ecosystem.
Regarding Claim 11
The combination of Holden and Richardson establishes the method of Claim 9, which is the basis for Claim 11.
Disclosure by Holden
Holden teaches:
the corresponding application
See at least (0068): “...an application executing on mobile computing device 200 can exchange messages with a control program executing on controller 260 of accessory 202... Such messages can be exchanged using an application protocol...”
Rationale: Holden teaches a host application and an accessory control program that exchange messages using an application protocol ([0068]), which establishes the software interactant pair for the corresponding application used in the interaction.
on the other vehicle or vehicle accessory
See at least (0068): “...exchange messages with a control program executing on controller 260 of accessory 202.” ([0068])
Rationale: Holden teaches the software is on the other vehicle or vehicle accessory by disclosing that the control program is "executing on controller 260 of accessory 202".
the other vehicle or other vehicle accessory
See at least (0053): “...mobile computing device 200 and accessory 202 are ‘connected’ whenever a communication channel... is open... Connection can be achieved by physical attachment...” ([0053])
Rationale: Holden teaches that the other vehicle or other vehicle accessory is the "accessory 202" that is the target of the connection.
being attached
See at least (0053): “Connection can be achieved by physical attachment (e.g., between respective mating connectors of mobile computing device 200 and accessory 202)...” ([0053])
Rationale: Holden teaches that the devices are being attached by disclosing that "connection can be achieved by physical attachment (e.g., between respective mating connectors...)".
to the first vehicle or first vehicle accessory.
See at least (0053): “Connection can be achieved by physical attachment (e.g., between respective mating connectors of mobile computing device 200 and accessory 202)...”
Rationale: Holden teaches the attachment is to the first vehicle or first vehicle accessory by disclosing the mechanical link is made with the "mobile computing device 200".
Claim Limitations Not Explicitly Disclosed by Holden
Holden does not explicitly teach:
automatically executing
in response to
Disclosure by Richardson
Richardson provides teachings for the following remaining missing elements:
automatically executing
See at least (0015): “The attachment of the accessory to the user device or vice versa may trigger various actions, such as automatically executing certain software on the user device and/or the accessory.”
Rationale: Richardson teaches automatically executing the software by explicitly disclosing that an attachment event "may trigger various actions, such as automatically executing certain software".
in response to
See at least (0017): “In some embodiments, the user device and/or the accessory may perform one or more actions in response to being attached to each other. These actions may be referred to as an ‘automatic response.’ An automatic response may include, for example, executing an application...”
Rationale: Richardson teaches the execution is performed in response to the attachment by describing an "automatic response" mechanism where devices perform actions "in response to being attached to each other," such as "executing an application".
Motivation to Combine Holden and Richardson
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Holden and Richardson before them, to incorporate Richardson’s attachment-triggered automatic response logic into Holden’s accessory communication framework. Holden teaches a vehicular interaction model where a main computing system (first vehicle) and an external accessory (other vehicle) connect via physical attachment and exchange data between a host application and an accessory-side control program. Richardson explicitly teaches that the attachment of an accessory to a device triggers an automatic response, including automatically executing an application on the accessory. A person having ordinary skill in the art would have found it obvious to combine these teachings to automate the initialization of Holden’s accessory-side software upon attachment. This modification represents the predictable implementation of starting the accessory-side interactant software (Holden's control program) as the specific "application" that is executed as the "automatic response" (Richardson) when the devices are physically attached, achieving a plug-and-play initialization of the interaction session.
Regarding Claim 12,
The combination of Holden and Richardson establishes the method of Claim 1, which is the basis for Claim 12.
Disclosure by Holden
Holden discloses:
A vehicle or vehicle accessory
See at least: "an automobile; an automobile accessory (e.g., a car stereo system or car navigation system)" ([0031])
Rationale: The reference explicitly discloses an automobile accessory such as a car stereo system, which falls within the scope of a vehicle or vehicle accessory.
including an electronic control unit, ECU,
See at least: "accessory 202 can include controller 260" ([0041]); "Controller 260 can include, e.g., a microprocessor or microcontroller executing program code to perform various functions such as... controlling of accessory functionality" ([0043])
Rationale: The reference discloses an accessory containing a controller that is a microprocessor/microcontroller executing code to control the accessory's functions. A PHOSITA would understand this controller to be an electronic control unit (ECU) when implemented within the disclosed automobile accessory context.
and wireless communications apparatus,
See at least: "a wireless interface (e.g., Bluetooth or the like)" ([0039]); "a communication channel... wireless channels such as Bluetooth... WiFi" ([0053])
Rationale: The reference explicitly discloses that the mobile computing device and accessory can include wireless interfaces and communicate over wireless channels, which constitutes wireless communications apparatus.
the vehicle or vehicle apparatus further comprising:
Rationale: This is a transitional phrase introducing the components of the claimed apparatus. The disclosure of the automobile accessory with the following components fulfills this element.
memory;
See at least: "memory 265 can be implemented using any type of memory, disk, or other storage medium" ([0045]); "storage device 225" ([0036])
Rationale: The reference explicitly discloses memory (265) within the accessory and a storage device (225) in the mobile computing device, which is a form of memory.
one or more processors or processing circuitry;
See at least: "processor 230" ([0033]); "Controller 260 can include, e.g., a microprocessor or microcontroller" ([0043])
Rationale: The reference discloses processor 230 in the mobile device and a microprocessor or microcontroller as the controller in the accessory, which are one or more processors or processing circuitry.
and computer code,
See at least: "accessory specific software 280" ([0045]); "application programs (Apps) 226" ([0037])
Rationale: The reference discloses software and application programs, which are forms of computer code stored in memory and executable by a processor.
wherein the computer code, when loaded by the ECU
See at least: "accessory specific software 280 that can provide instructions for controller 260" ([0045]); "processor 230 can also manage communication with accessories" ([0033])
Rationale: The reference teaches that software provides instructions for the controller (i.e., the ECU), implying it is loaded by the controller/ECU for execution.
from the memory
See at least: "memory 265 can store accessory specific software 280" ([0045]); "storage device 225 can store application programs 226" ([0036])
Rationale: The reference explicitly states that the software/computer code is stored in the memory/storage device, from where it is accessed and loaded.
and executed by the one or more processors or processing circuitry
See at least: "Controller 260 can include, e.g., a microprocessor or microcontroller executing program code" ([0043]); "processor 230, which can be implemented as one or more integrated circuits... can control the operation of mobile computing device 200" ([0033])
Rationale: The reference explicitly teaches that the microprocessor or microcontroller (i.e., processor/processing circuitry) performs the action of executing program code.
causes the vehicle or vehicle accessory to execute a method
See at least: "application 404 executing on mobile computing device 400 to communicate with accessory 402 using an application protocol" ([0094], Fig. 4); "an application executing on mobile computing device 200 can exchange messages with a control program executing on controller 260 of accessory 202, thereby instructing controller 260 to communicate with and/or control operation of accessory specific hardware 275" ([0068])
Rationale: The reference discloses that executing an application or software on the processor causes the mobile device and/or the accessory to perform operations, such as communicating via a protocol or controlling hardware, which constitutes executing a method.
Motivation to Combine Holden and Richardson
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Holden and Richardson before them, to incorporate Richardson’s over-the-air remote configuration functionality into Holden’s vehicle/accessory application-execution and communications framework so that the ECU-based vehicle or vehicle accessory executes the remotely-caused reconfiguration method of Claim 1. Holden provides the vehicle/accessory execution environment (processor executing code from memory) and the communications framework for establishing interaction between a host device and an accessory application. Richardson provides remote, over-the-air configuration and update mechanisms that cause a device to change configuration based on remotely delivered data. A PHOSITA would combine these teachings to use Holden’s established in-vehicle execution and communication pathway as the predictable vehicle-side implementation platform for Richardson’s remote reconfiguration, thereby enabling the vehicle/accessory to execute the claimed remotely-caused reconfiguration method in a plug-and-play, managed manner.
Regarding Claim 13,
The combination of Holden and Richardson establishes the method of Claim 9, which is the basis for Claim 13.
Disclosure by Holden
Holden discloses:
A vehicle or vehicle accessory
See at least: "an automobile; an automobile accessory (e.g., a car stereo system or car navigation system)" ([0031])
Rationale: The reference explicitly discloses an automobile accessory such as a car stereo system, which falls within the scope of a vehicle or vehicle accessory.
including an electronic control unit, ECU,
See at least: "accessory 202 can include controller 260" ([0041]); "Controller 260 can include, e.g., a microprocessor or microcontroller executing program code to perform various functions such as... controlling of accessory functionality" ([0043])
Rationale: The reference discloses an accessory containing a controller that is a microprocessor/microcontroller executing code to control the accessory's functions. A PHOSITA would understand this controller to be an electronic control unit (ECU) when implemented within the disclosed automobile accessory context.
and wireless communications apparatus,
See at least: "a wireless interface (e.g., Bluetooth or the like)" ([0039]); "a communication channel... wireless channels such as Bluetooth... WiFi" ([0053])
Rationale: The reference explicitly discloses that the mobile computing device and accessory can include wireless interfaces and communicate over wireless channels, which constitutes wireless communications apparatus.
the vehicle or vehicle apparatus further comprising: memory;
See at least: "memory 265 can be implemented using any type of memory, disk, or other storage medium" ([0045]); "storage device 225" ([0036])
Rationale: The reference explicitly discloses memory (265) within the accessory and a storage device (225) in the mobile computing device, which is a form of memory.
one or more processors or processing circuitry;
See at least: "processor 230" ([0033]); "Controller 260 can include, e.g., a microprocessor or microcontroller" ([0043])
Rationale: The reference discloses processor 230 in the mobile device and a microprocessor or microcontroller as the controller in the accessory, which are one or more processors or processing circuitry.
and computer code,
See at least: "accessory specific software 280" ([0045]); "application programs (Apps) 226" ([0037])
Rationale: The reference discloses software and application programs, which are forms of computer code stored in memory and executable by a processor.
wherein the computer code, when loaded by the ECU
See at least: "accessory specific software 280 that can provide instructions for controller 260" ([0045]); "processor 230 can also manage communication with accessories" ([0033])
Rationale: The reference teaches that software provides instructions for the controller (i.e., the ECU), implying it is loaded by the controller/ECU for execution.
from the memory
See at least: "memory 265 can store accessory specific software 280" ([0045]); "storage device 225 can store application programs 226" ([0036])
Rationale: The reference explicitly states that the software/computer code is stored in the memory/storage device, from where it is accessed and loaded.
and executed by the one or more processors or processing circuitry
See at least: "Controller 260 can include, e.g., a microprocessor or microcontroller executing program code" ([0043]); "processor 230, which can be implemented as one or more integrated circuits... can control the operation of mobile computing device 200" ([0033])
Rationale: The reference explicitly teaches that the microprocessor or microcontroller (i.e., processor/processing circuitry) performs the action of executing program code.
causes the vehicle or vehicle accessory to execute a method
See at least: "application 404 executing on mobile computing device 400 to communicate with accessory 402 using an application protocol" ([0094], Fig. 4); "an application executing on mobile computing device 200 can exchange messages with a control program executing on controller 260 of accessory 202, thereby instructing controller 260 to communicate with and/or control operation of accessory specific hardware 275" ([0068])
Rationale: The reference discloses that executing an application or software on the processor causes the mobile device and/or the accessory to perform operations, such as communicating via a protocol or controlling hardware, which constitutes executing a method.
Motivation to Combine Holden and Richardson
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Holden and Richardson before them, to incorporate Richardson’s over-the-air remote configuration functionality into Holden’s vehicle/accessory application-execution and communications framework so that the ECU-based vehicle or vehicle accessory executes the remotely-caused reconfiguration method of Claim 9. Holden provides the vehicle/accessory execution environment (processor executing code from memory) and the communications framework for establishing interaction between a host device and an accessory application. Richardson provides remote, over-the-air configuration and update mechanisms that cause a device to change configuration based on remotely delivered data. A PHOSITA would combine these teachings to use Holden’s established in-vehicle execution and communication pathway as the predictable vehicle-side implementation platform for Richardson’s remote reconfiguration, thereby enabling the vehicle/accessory to execute the claimed remotely-caused reconfiguration method in a plug-and-play, managed manner.
Regarding Claim 14
The combination of Holden and Richardson establishes the system of Claim 12, which is the basis for Claim 14.
Disclosure by Holden
Holden discloses:
A system
See at least (0029): “In some embodiments, system 100 includes a mobile computing device 102 … and an accessory 113 ….”
Rationale: Holden discloses a multi-component system including a primary computing device and an accessory that interoperate via defined communications and software procedures.
for configuring a first vehicle or first vehicle accessory
See at least (0031): “Accessory 113 can be any device capable of communicating with mobile computing device 102 such as, for example, … an automobile; an automobile accessory (e.g., a car stereo system or car navigation system) ….” ([0031])
Rationale: Holden discloses configuration/enablement of an in-vehicle endpoint by expressly identifying an “automobile” and “automobile accessory” as the accessory-side endpoints that participate in the described application/session establishment framework.
with an application
See at least (0129): “In some embodiments, the accessory information … can include an identifier of a preferred application for use with the accessory.”
Rationale: Holden discloses provisioning/configuring the first-side device “with an application” by providing an identifier for a “preferred application” for use with the connected accessory.
which executes automatically
See at least (0132): “In some embodiments … if preferred application is not executing on the [mobile computing device] … the application can be automatically launched.”
Rationale: Holden expressly discloses automatic execution behavior by stating the preferred application can be “automatically launched.”
when another vehicle or another vehicle accessory is attached to the first vehicle or vehicle accessory,
See at least (0053): “Connection can be achieved by physical attachment (e.g., between respective mating connectors of mobile computing device 200 and accessory 202) ….” ([0053])
Rationale: Holden discloses the required attachment condition by describing a connection achieved via “physical attachment” between the first-side device and the other-side accessory.
the system comprising: a first vehicle or first vehicle accessory
See at least (0031): “Accessory 113 can be any device … such as … an automobile; an automobile accessory ….”
Rationale: Holden discloses a system implementation including a vehicle/vehicle-accessory endpoint as part of the system hardware environment.
and one or more servers
See at least (0120): “In some embodiments, application protocol can be specified by reference to an application store and/or server … the mobile computing device can request application protocol information … from the application store and/or server ….” ([0120])
Rationale: Holden expressly discloses “one or more servers” by describing an “application store and/or server” that is contacted to provide application/protocol information.
configured to act as trusted sources for applications
See at least (0120): “In some embodiments, the mobile computing device can request application protocol information … from the application store and/or server ….” ([0120])
Rationale: Holden discloses server-side infrastructure that supplies authoritative application-related information to the vehicle/accessory ecosystem, consistent with server(s) operating as the source used to obtain/validate the relevant application/protocol for the interaction.
associated with application identifiers
See at least (0129): “This identifier might be a URL … [or] a unique product identifier for the preferred application ….” ([0129])
Rationale: Holden expressly discloses application identifiers (URL / unique product identifier) that are associated with the preferred application to be used for the accessory interaction.
transmitted by the other vehicle or vehicle accessory
See at least (0163): “At block 1704 the accessory can send a message to the mobile computing device ….” ([0163])
Rationale: Holden discloses transmission originating from the accessory-side device (the “other” side) by stating the “accessory can send a message” to the first-side device.
to the first vehicle or vehicle accessory.
See at least (0163): “At block 1704 the accessory can send a message to the mobile computing device ….” ([0163])
Rationale: Holden expressly discloses the destination of the transmission (“to the mobile computing device”), which corresponds to the first-side vehicle/vehicle accessory endpoint in the system pairing.
Claim Limitations Not Explicitly Disclosed by Holden
Holden does not explicitly teach:
configured to act as trusted sources for applications (with explicit trust designation)
Disclosure by Richardson
Richardson teaches:
configured to act as trusted sources for applications
See at least (0077): “White-listed channels are trusted, and black-listed channels are untrusted.” ([0077]); “For example, the Google Play Store may be considered by an administrator server to be a trusted source for most applications downloaded to a device.” ([0083])
Rationale: Richardson expressly discloses a trust designation for software distribution sources (“channels”), establishing that particular sources are treated as “trusted” for obtaining applications/software. Richardson also expressly ties “trusted source” status to server-governed policy (“administrator server”), supporting the limitation that server-side infrastructure is configured such that applications are obtained from sources treated as trusted.
Motivation to Combine Holden and Richardson
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Holden and Richardson before them, to implement Richardson’s server-governed trusted-source policy for application acquisition within Holden’s vehicle/accessory application-identification and application-store/server retrieval framework, so that the server(s) used to obtain the application corresponding to the transmitted application identifier are restricted to (or validated as) trusted sources, yielding the predictable result of improved integrity and security when configuring the first vehicle/vehicle accessory with the application that automatically executes upon attachment.
Regarding Claim 15
The combination of Holden and Richardson establishes the system of Claim 14, which is the basis for Claim 15.
Disclosure by Holden
Holden discloses:
further comprises an off-board database
See at least (0040): "In one embodiment, the host computer maintains a master database of media assets and/or applications and can access other databases, for example, through the Internet..."
Rationale: Holden discloses that the system further comprises an off-board database by describing a "host computer" that is external to the mobile device and maintains a "master database" accessible over a network.
and wherein the method further comprises synchronizing a first vehicle or first vehicle accessory reconfiguration
See at least (0040): "...the asset management program synchronizes the master database with the database maintained on storage device 225 of mobile computing device 200 automatically whenever mobile computing device 200 connects to the host computer."; (0091): "Based on the received information, mobile computing device 200 of FIG. 3 can populate port map 325, accessory information table 330... with information Such as accessory type, accessory identifier, application protocol name..."
Rationale: Holden teaches and wherein the method further comprises synchronizing a first vehicle or first vehicle accessory reconfiguration by disclosing that the host computer "synchronizes" with the database on the mobile device (first vehicle). This local database contains the port maps and accessory tables that define the interaction state, representing the reconfiguration of the vehicle system. Examiner interprets ‘the method” as the method established in claim 1. The combination of Holden and Richardson establishes the method of Claim 1.
in the off-board database.
See at least (0040): "...the host computer maintains a master database..."
Rationale: Holden discloses the synchronization occurs in the off-board database (the master database maintained on the host computer).
Claim Limitations Not Explicitly Disclosed by Holden
Holden does not explicitly disclose:
of vehicle and vehicle accessory configurations,
with a corresponding vehicle or vehicle accessory record
Disclosure by Richardson
Richardson discloses:
of vehicle and vehicle accessory configurations,
See at least (0012): "MDM functionality can include over-the-air distribution of applications, data and configuration settings for all types of mobile devices, including mobile phones, smartphones, tablet computers... [and] automobiles..."
Rationale: Richardson discloses a database of vehicle and vehicle accessory configurations, by describing a mobile device management (MDM) system that distributes and maintains "configuration settings" for devices explicitly including "automobiles."
with a corresponding vehicle or vehicle accessory record
See at least (0142): "In some embodiments, the system further comprises a database storing data for a plurality of applications associated with the first computing device, the data comprising a source identifier and a state designation for each of the applications..."
Rationale: Richardson discloses synchronizing with a corresponding vehicle or vehicle accessory record by describing a database that stores application data (IDs, sources, state designations) specifically "associated with the first computing device" (the vehicle).
Motivation to Combine Holden and Richardson
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Holden and Richardson before them, to incorporate the administrative device management and configuration tracking logic of Richardson into the host-computer synchronization framework of Holden. Holden teaches a distributed vehicular compute system that automatically synchronizes its local software and data with a remote "master database" upon connection. Richardson teaches that for a fleet of devices (including vehicles), a centralized database must maintain "configuration settings" and application-specific "state designations" to ensure system integrity. A person having ordinary skill in the art would have found it obvious to utilize Richardson's specific configuration records and per-device database structure within Holden's synchronization method. This combination ensures that whenever a vehicle is reconfigured (e.g., by identifying and provisioning interaction software as in Holden), the system synchronizes this state with a specific device record in an off-board management database (as in Richardson). This represents the predictable application of known fleet management and data alignment methods to achieve a secure, consistent configuration state across vehicular platforms.
Response to Arguments
Examiner’s Response to Applicant’s 103 Remarks
Applicant’s remarks traverse the non-final rejections that were based on Moinzadeh (and Trombley, and further Baza). The present Final Office Action, however, sets forth new grounds applying a different combination—Holden in view of Richardson—to the pending claims as amended. Accordingly, Applicant’s arguments directed to Moinzadeh/Trombley/Baza do not identify error in the currently applied teachings and therefore are not persuasive to overcome the rejections in the present Final Office Action.
Notwithstanding the non-responsiveness, the Office addresses Applicant’s principal themes (two-stage staging; trusted-source authentication; and “incompatibility” rationale) as they relate to the current grounds.
“Two-stage process” argument (wireless detect/download before attachment; later physical attach triggers load/execute)
Applicant asserts that incorporating former claim 5 into claim 1 introduces a “novel two-stage process” not taught or suggested by the cited art. That argument is not persuasive against the present grounds.
Holden expressly treats “connected” as including both wired/physical coupling and wireless coupling (e.g., Bluetooth/Wi-Fi), and describes workflows where the host device detects an accessory connection and then obtains accessory-provided information used to identify compatible applications/protocols.
Further, Holden teaches that the host device may search for and/or download a compatible application without prompting the user, and that applications may be launched automatically in response to accessory connection.
In view of these teachings as a whole, a PHOSITA would have found it an obvious and predictable design choice to perform the “detect/obtain identifier/download/configure” operations upon wireless coupling (i.e., prior to physical coupling), and then to perform “load/execute” upon subsequent physical coupling (e.g., docking/connector attachment), because Holden already contemplates both connection modalities and automatic application acquisition/launch behaviors in response to connection events.
Applicant’s characterization of the amended claim as requiring a “distinct departure” therefore does not show error in the present rejection; rather, the amended staging is a routine partitioning of known steps across known connection states (wireless vs. physical coupling) to achieve the predictable result of having the host configured and ready at the time of physical attachment.
“Trusted application source / authenticating the application identifier” argument
Applicant previously argued that Moinzadeh “does not teach” authenticating an application identifier to determine whether an application can be loaded from a trusted source, and that “whitelist” logic is not the same as the claimed trusted-source authentication.
Those arguments are not persuasive as applied to the present grounds because Richardson specifically teaches trust evaluation using identifiers and trust-state records, including whitelists/blacklists (or equivalent trusted/untrusted determinations), and teaches blocking/allowing installation/execution based on whether the application/source is trusted.
Richardson further teaches maintaining and evaluating package identifiers and signing identifiers (information determined from the application’s identifying information) as part of determining whether an application is trusted/allowed.
Holden, in turn, teaches obtaining compatible applications via an application store and/or server and automatically downloading compatible applications (including “without prompting the user”).
Thus, under the present rejection, the “trusted source/authentication” limitations are met by the combined teachings: Richardson provides the security/trust determination (i.e., authenticate/verify allowability using identifying information), and Holden provides the compatible-application acquisition from a store/server with automatic download behavior.
Applicant’s prior critique of “whitelist logic” therefore does not show error; it aligns with (and is encompassed by) Richardson’s trusted/untrusted determinations, which are expressly security-motivated.
“Configuration settings / reconfiguration is only I/O arbitration” argument
Applicant argued (against the prior grounds) that the art is “primarily I/O resource access” and does not determine/apply “vehicle configuration settings” in the claimed sense.
That argument is not persuasive against the present grounds because Holden teaches that the accessory can provide not merely an identifier but also capabilities and preferred operating states (e.g., protocol capabilities, preferred initial operating states, preferred formats), and the host uses such information in determining how to interact with the accessory.
Accordingly, the “configuration settings” are satisfied by the host applying the determined parameters/interfaces/protocol selections necessary to enable the host to load/execute the correct application and communicate with the accessory. The present rejection does not require that the configuration be limited to a specific subset (e.g., only kinematic trailer parameters); rather, the claim broadly recites internal settings and/or external interfaces enabling load/execute/communication (as reflected in dependent claims). Holden’s protocol/capability-driven configuration is consistent with that claim scope.
“Non-compatibility / no motivation to combine” argument
Applicant contended that the prior references were non-analogous and that combining them would be illogical/hindsight.
That argument is not persuasive for the present grounds because Holden and Richardson address complementary aspects of the same general technical problem: securely enabling functionality via software in response to detecting/connecting external devices/accessories—Holden teaches accessory-triggered application identification/acquisition/launch, while Richardson teaches trust evaluation of applications/sources to prevent loading/executing untrusted software.
A PHOSITA would have been motivated to incorporate Richardson’s trust controls into Holden’s accessory-driven application acquisition/launch pipeline to improve security and safety (e.g., to prevent unauthorized or malicious applications from being fetched/installed/executed when accessories are detected/connected), yielding the predictable result of performing Holden’s automatic acquisition/launch subject to a trusted/untrusted determination.
This is a classic, non-hindsight rationale: adding known security screening to a known auto-provisioning workflow to achieve an expected improvement (secure application enablement), without requiring either reference to abandon its core architecture.
Applicant’s anticipation case-law discussion
Applicant’s discussion of anticipation standards (e.g., that each limitation must be disclosed for 102) is not controlling of the present grounds to the extent the final rejection applies 103 obviousness over different references. In any event, Applicant’s 102 arguments addressed to Moinzadeh do not rebut the current mapping over Holden in view of Richardson.
Because Applicant’s remarks are directed to superseded rejections over Moinzadeh/Trombley/Baza, they do not address the present grounds of rejection and are therefore not persuasive. Moreover, to the extent Applicant’s remarks are read as general objections to “two-stage staging,” “trusted-source authentication,” “configuration/reconfiguration,” or “motivation to combine,” those objections are not persuasive in view of the combined teachings of Holden and Richardson as applied in the Final Office Action.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to OLUWABUSAYO ADEBANJO AWORUNSE whose telephone number is (571)272-4311. The examiner can normally be reached M - F (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, Jelani Smith can be reached at (571) 270-3969. 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.
/OLUWABUSAYO ADEBANJO AWORUNSE/Examiner, Art Unit 3662
/JELANI A SMITH/Supervisory Patent Examiner, Art Unit 3662