DETAILED ACTION
Claims 1-15 and 18-20 are presented for examination.
Claims 1-5, 7-8 and 15-19 have been amended.
Claims 16 and 17 have been cancelled.
Claims 20 is/are new.
This office action is in response to the amendment submitted on 23-JUL-2026.
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 .
Examiner’s Note (EN)
The prior art rejections below cite particular paragraphs, columns, and/or line numbers in the references for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art.
Response to Arguments – Objections
Applicant’s arguments with respect to the drawing objections have been considered and are persuasive. The objections for the specified items are withdrawn. The applicant’s cooperation is requested in checking the remaining drawings and specification numberings and terminology.
Response to Arguments – 35 USC 103
Applicant’s arguments with respect to the 103 rejections have been considered, but are moot in view of the new ground(s) of rejection provided below.
With regards to claim 2, the applicant, on pg. 22, argues that the current art of record does not teach signed URLs. However, Claim 2 does not recite signed URLs. The applicant is reading the specification into the claim language. Claim 20 does recite signed URLs and upon further search and consideration new rejection ground are presented below. Similarly new rejection grounds are presented below for the additional queuing limitation of Claim 1.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Searle et al. (US20160196132A1) in view of Bogineni et al. (US20190324813A1) and further in view of AWS Lambda (AWS Lambda now supports batch windows)
Regarding Claim 1, Searle teaches a center device that manages data to be written in an electronic control device mounted on a vehicle and performs, by an application program, a plurality of functions for transmitting update data to the vehicle by wireless communication ([0046-0047] "The Remote Embedded Device Update Platform Apparatuses, Methods and Systems (hereinafter “REDUP”) transforms telemetry inputs, via REDUP components (e.g., DSD, UDA, PDA, UTA, PSC, UPC, ELA, AC, etc. components), into remote embedded updates outputs…REDUP helps manage and update embedded devices that traditionally have been inaccessible and impracticable to update. Via its update and communication mechanisms, REDUP may also obtain data, both real-time and deferred, and perform analysis as feedback to determine existing problems, but also to diagnose potential and future problems." EN: REDUP is the center device [0108] “FIG. 21 shows an exemplary model for the REDUP. In FIG. 21, an example illustrating how a device (e.g., a vehicle) may be updated using the REDUP is shown. In this example, the vehicle is associated with segment A and starts in a specified state. As shown, the vehicle starts with an initial versions of components (e.g., a set software applications) 1, 2, 3, 4, and 5. For example, these components may have been delivered to the vehicle in package 1 version 1.0. An update for segment A may be provided using package 1 version 2.0 with components 1′, 2, 3′, 4, 5, and 6. The ′ character denotes an updated version of the previous version of software (e.g., 2′ is an update version of component 2, while 6 is an initial version of a new component). Based on the initial state reported by the vehicle to an update server, the server may determine that the vehicle should download components 1′, 3′, and 6. Components 2, 4, and 5 are not downloaded because they are already installed. After the update the vehicles includes components 1′, 2, 3′, 4, 5, and 6.”)
Wherein an application program implementing at least one of the functions adopts a server architecture in which a resource is always allocated and that executes as a resident-type process ([0048] "FIG. 1 shows an exemplary architecture for the REDUP. In FIG. 1, a suite of client/server components supporting remote cloud software management server, client reporting and analytics is shown. A hosted cloud platform is utilized to facilitate remote management of connected devices via network. In one implementation, a J2EE application that operates in a clustered configuration for resilience, performance and scalability, utilizing a relational database that may also be clustered may be utilized. For example, the live system may sit in the cloud and may be hosted in a variety of environments (e.g., Amazon EC2)." EN: the J2EE architecture is an always allocated server architecture)
the center device comprising: a campaign determination section that is configured to receive vehicle configuration information from the vehicle and determine whether there is campaign information for the vehicle ([0052] "The architecture described above in FIG. 1 may be utilized to facilitate delivery of an update to the device to address the issue. A campaign may be initiated to determine why customers are choosing to turn off adaptive steering for the vehicle model. For example, it may be determined that adaptive steering is too sensitive making it difficult to operate the vehicle model. Accordingly, an update to the adaptive steering component (e.g., ECU) may be prepared. The update may be tested on a segment that includes manufacturer owned test vehicles used to test changes to the vehicle model. Once the update has been tested and finalized (e.g., adaptive steering operates better, installation package is configured properly) devices (e.g., vehicles) in a segment that includes vehicles of the vehicle model that include the adaptive steering option (e.g., including the device) may be notified to install the update." and [0063] "Segments for the device may be determined at 405. A segment may be configured to link a group of devices that are a set (e.g., a set of vehicles with specified VINs), and/or that have specified components (e.g., vehicles that utilize a specified ECU) and/or component attributes (e.g., the ECU utilizes a specified firmware version). A device may be associated with one or more segments. In one embodiment, information regarding the device (e.g., the device's bill of materials, versions of components) may be analyzed (e.g., when the device is added to the REDUP) to determine segments associated with the device. Updates installed on the device may be tracked and segments associated with the device may be updated accordingly (e.g., if the ECU is updated with a new firmware version, the device may be placed in the segment associated with the new firmware version and removed from the segment associated with the old firmware version).")
a campaign generation section that is configured to generate campaign notification information for the vehicle when there is the campaign information ([0052])
a status management section that is configured to manage a generation state of the campaign notification information ([0106-0107] " The compute service processing section 15 accesses the database section 19 and determines whether there is campaign information which is software update information corresponding to the passed vehicle configuration information (S8). When the campaign information exists, the compute service processing section 15 generates the campaign notification information to be distributed to the vehicle 31 with reference to the database section 19 (S9). The compute service processing section 15 is an example of a campaign determination section and a campaign generation section. In addition, the compute service function section 14 corresponds to a first compute service section, and the compute service processing section 15 corresponds to a second compute service section. In step S9, in a case where there is the campaign information and information necessary for distribution to the vehicle 31 is prepared, the process proceeds to step S10. Packages may be linked to update campaigns. A campaign for a software update may facilitate publishing packages from the cloud to a product (e.g., a vehicle) and results of the campaign may be subsequently reported back to the cloud. Publishing a package may involve sending out notifications to products (e.g., vehicles) that are members of the segment. When notified, the products may request installers to update the attributes in the tree and then request the server to download any SUMs. SUMs are routed to the correct installers (e.g., different components may utilize different installers) and executed. An installation report may be delivered back to the cloud indicating success of failure of the update session. This also facilitates measuring the effectiveness of the campaign.")
a campaign transmission section that is configured to distribute the campaign notification information to the vehicle according to the generation state ([0055] "The update server may send an update notification 329 to the device. For example, the update server may send the update notification to notify the device regarding any applicable updates. In one implementation, the update notification may include the device's identifier (e.g., a device token used to identify the device anonymously), a list of updates available for the device, description of each update, an update package identifier associated with each update, priority associated with each update, and/or the like. ")
wherein the application program includes: a first compute service section configured to receive the vehicle configuration information from the vehicle via a gateway section ([1847] "In some alternative embodiments, REDUP M2M Cloud is a product designed to provide the capability to remotely manage and update connected devices in scenarios where an M2M gateway is used. The M2M gateway acts as a proxy to connected devices, providing local services. REDUP Cloud provides Enterprise services for multiple M2M gateways. The main services are remote software management and event data collection and analysis. There are two objectives. The first is to remove the need to handle devices on-site, which obfuscates the expense incurred through returning devices to service centers for maintenance and upgrade. The second is to provide an aggregation point for streams of data into a Big Data processing environment as a platform for predictive analytics." and [0063])
a second compute service section configured to determine, as the campaign determination section and the campaign generation section, whether there is the campaign information for the vehicle based on the vehicle configuration information, and generate the campaign notification information for the vehicle when there is the campaign information ([0052] and [0055] "The update server may send an update notification 329 to the device. For example, the update server may send the update notification to notify the device regarding any applicable updates. In one implementation, the update notification may include the device's identifier (e.g., a device token used to identify the device anonymously), a list of updates available for the device, description of each update, an update package identifier associated with each update, priority associated with each update, and/or the like.")
a database section configured to manage the generation state of the campaign notification information, ([0048-0049] "A connected device (e.g., a vehicle, a smartphone, an appliance, a smart lock, and/or the like device that is capable of network connectivity) is configured to log specified events. For example, logged events may include software and configuration updates events, system fault and performance events, system service usage notifications, telematic data, and/or the like. These events may be logged by the device's software system or by individual device components (e.g., peripheral units or electronic control units (ECUs)) and may be securely delivered in a structured data format to the cloud platform for storage in a big data storage repository and/or databases of individual analytics applications. In one implementation, events data may be structured based on a graph format that facilitates flexible and configurable logging without having to tightly couple the data model to the back end system." and [0300] shows the various properties associated with the states of the campaigns)
wherein the first compute service section registers the generation state of the campaign notification information in a database according to content of the vehicle configuration information ([0300])
selects and activates the application program included in the second compute service section ([2171] EN: Also see Bogineni [0075] "Event trigger detector 512 may monitor request queue DB 520 for requests that may correspond to a trigger condition associated with an on-demand process in event trigger DB 514 and/or may monitor state DB 530 for states that correspond to a trigger condition associated with an on-demand process in event trigger DB 514. For example, trigger detector 512 may monitor for a particular request from UE device 110, a particular request from another 5G function node, a particular request from an on-demand process associated with VNF MO 422 or another 5G function node, a particular network state associated with the on-demand process, a particular time period associated the on-demand process, and/or another type of trigger condition. Exemplary information that may be stored in event trigger DB 514 is described below with reference to FIG. 6B.")
However, Searle isn’t relied on for:
an application program implementing at least one of the other functions adopts a serverless architecture in which the application program is activated upon occurrence of an event and is dynamically allocated with a resource in an on-demand manner for execution of a code of the application program in which the resource allocated to the application program is released when the execution of the code is terminated
wherein the application program that implements functions of the campaign determination section, the status management section, and the campaign generation section adopts the serverless architecture
to pass the vehicle configuration information to a queuing buffer section, the queuing buffer section being configured to accumulate the vehicle configuration information for a predetermined period and, after the predetermined period elapses, to pass the vehicle configuration information to a second compute service section;
Bogineni teaches an application program implementing at least one of the other functions adopts a serverless architecture in which the application program is activated upon occurrence of an event and is dynamically allocated with a resource in an on-demand manner for execution of a code of the application program in which the resource allocated to the application program is released when the execution of the code is terminated ([0019] "Implementations described herein relate to a serverless computing 5G architecture. “Serverless computing,” as the phrase is used herein, refers to cloud computing with dynamic allocation of computing resources. Thus, rather than allocating predetermined units of capacity (e.g., amount of memory or persistent storage, processor time, number of processor cores, network bandwidth, etc.), serverless computing allocates resources as needed when a particular process is executed. A serverless computing process may be activated by a trigger event. In response to the trigger event, code associated with the process may be loaded and executed. After the process is executed, computing resources required to load and execute the process may be released. Since serverless computing does not require computing infrastructure to manage, processes to be executed using serverless computing may be self-scaling.")
wherein the application program that implements functions of the campaign determination section, the status management section, and the campaign generation section adopts the serverless architecture ( [0019])
Searle and Bogineni are analogous art because they are from the same field of endeavor in update and deployment architecture. While Searle focuses on deployment of update campaigns for vehicles, Bogineni provides the serverless architecture option. Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to combine Searle, and Bogineni to apply Bogineni’s serverless architecture for vehicle update deployment with expected results. “Since serverless computing does not require computing infrastructure to manage, processes to be executed using serverless computing may be self-scaling.” (Bogineni, [0019])
AWS lambda teaches to pass the vehicle configuration information to a queuing buffer section, the queuing buffer section being configured to accumulate the vehicle configuration information for a predetermined period and, after the predetermined period elapses, to pass the vehicle configuration information to a second compute service section (Pg. 1, AWS Lambda now allows customers using Amazon Simple Queue Service (Amazon SQS) as an event source to define a wait period, called MaximumBatchingWindowInSeconds, to allow messages to accumulate in their SQS queue before invoking a Lambda function. In addition to Batch Size, this is a second option to send records in batches, to reduce the number of Lambda invokes. This option is ideal for workloads that are not time-sensitive, and can choose to wait to optimize cost. Previously, Lambda functions polling from an SQS queue would send messages in batches of up to 10 before invoking the function. Now, customers can also define a time window that Lambda should wait to poll messages from their SQS queue before invoking their function. Lambda will wait for up to 300 seconds to poll messages from the SQS queue. When a batch window is defined, Lambda will also allow customers to define a batch size of up to 10,000 messages.”)
Searle, Bogineni and AWS Lambda are analogous art because they are from the same field of endeavor in update and deployment architecture. While Searle focuses on deployment of update campaigns for vehicles, AWS Lambda provides both the serverless architecture as well as the timed queuing service when passing messages between different service components. Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to combine Searle, Bogineni and AWS Lambda to apply AWS Lambda’s queuing for vehicle update deployment with expected results. A POSITA would be motivated to do so to improve performance and scalability in a distributed environment.
Claims 18 are method claims reciting limitations similar to claims 1 and are rejected under the same rationale.
Claims 2-15 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Searle et al. (US20160196132A1) in view of Bogineni et al. (US20190324813A1)
Regarding Claim 2, Searle teaches a center device that manages data to be written in an electronic control device mounted on a vehicle and performs, by an application program, a plurality of functions to transmit update data to the vehicle by wireless communication ([0046-0047] and [0108])
the center device comprising:
a campaign determination section that is configured to receive vehicle configuration information from the vehicle and determine whether there is campaign information for the vehicle ([0052,0063])
a campaign generation section that is configured to generate campaign notification information for the vehicle when there is the campaign information ([0052])
a status management section that is configured to manage a generation state of the campaign notification information ([0106-0107])
a campaign transmission section that is configured to distribute the campaign notification information to a vehicle according to the generation state ([0055])
wherein the center device further comprises a package distribution section configured to distribute to the vehicle a package including the update data to be distributed to the vehicle, ([0058-0059] "The update server may facilitate sending the requested update package to the device using a package download administering (PDA) component 341. See FIG. 6 for additional details regarding the PDA component. The update server may send an update download response 345 to the device. For example, the update server may send the requested update package to the device. In one implementation, the package file may be sent to the device. For example, the package file may include package parameters (e.g., package name, package version, package priority, package segment identifier, package rules, package checksum), software update modules (SUMs) and associated rules, and/or the like." and [0072] "FIG. 6 shows a logic flow diagram illustrating embodiments of a package download administering (PDA) component for the REDUP. In FIG. 6, an update download request may be received at 601. For example, the update download request may be received by an update server from a device. In one implementation, the update server may be dedicated to a particular OEM product provider (e.g., vehicle manufacturer). For example, data collected (e.g., logs) and/or provided (e.g., updates) by such update server may not be shared with other OEMs. In another implementation, the update server may be shared among multiple OEM product providers. For example, data collected and/or provided by such update server may be shared among the OEMs.")
wherein the application program includes: an information control section that includes access control information in information for acquiring an update package associated with the campaign notification information; ([0203] shows the use of the access token to share information about updates to authorized vehicles)
a network distribution section configured to perform access control by confirming that access from the vehicle includes the access control information, ([0203] shows the access token ensuring access only by the authorized vehicle during distribution)
wherein the information control section checks an expiration state of an expiration date of the access control information ([1394] The HTTP content includes the token and the expiration variable)
generates updated access control information having a new expiration date when the access control information has expired, ([1318] function 6.5.3.2 covers the renewal of the access token)
However, Searle is not relied on for:
Wherein an application program implementing at least one of the functions adopts a serverless architecture in which the application program is activated upon occurrence of an event and is dynamically allocated with a resource in an on-demand manner for execution of a code of the application program, and in which the resource allocated to the application program is released when the execution of the code is terminated,
wherein an application program that implements functions of the campaign determination section, the status management section, and the campaign generation section adopts the serverless architecture.
wherein the information control section and the network distribution section adopt the serverless architecture.
Bogineni teaches wherein an application program implementing at least one of the functions adopts a serverless architecture in which the application program is activated upon occurrence of an event and is dynamically allocated with a resource in an on-demand manner for execution of a code of the application program, and in which the resource allocated to the application program is released when the execution of the code is terminated ([0019])
wherein an application program that implements functions of the campaign determination section, the status management section, and the campaign generation section adopts the serverless architecture ([0019])
wherein the information control section and the network distribution section adopt the serverless architecture ([0019])
Searle and Bogineni are analogous art because they are from the same field of endeavor in update and deployment architecture. While Searle focuses on deployment of update campaigns for vehicles, Bogineni provides the serverless architecture option. Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to combine Searle, and Bogineni to apply Bogineni’s serverless architecture for vehicle update deployment with expected results. “Since serverless computing does not require computing infrastructure to manage, processes to be executed using serverless computing may be self-scaling.” (Bogineni, [0019])
Regarding Claim 3, Searle in view of Bogineni teaches the center device according to claim 2. Searle teaches wherein the application program includes: a compute service function section configured to transfer the vehicle configuration information received from the vehicle via a gateway section to the campaign determination section ([1847] "In some alternative embodiments, REDUP M2M Cloud is a product designed to provide the capability to remotely manage and update connected devices in scenarios where an M2M gateway is used. The M2M gateway acts as a proxy to connected devices, providing local services. REDUP Cloud provides Enterprise services for multiple M2M gateways. The main services are remote software management and event data collection and analysis. There are two objectives. The first is to remove the need to handle devices on-site, which obfuscates the expense incurred through returning devices to service centers for maintenance and upgrade. The second is to provide an aggregation point for streams of data into a Big Data processing environment as a platform for predictive analytics." and [0063])
a compute service processing section configured to determine, as the campaign determination section and the campaign generation section, whether there is the campaign information for the vehicle based on the vehicle configuration information, and generate the campaign notification information for the vehicle when there is the campaign information ([0052] and [0055] "The update server may send an update notification 329 to the device. For example, the update server may send the update notification to notify the device regarding any applicable updates. In one implementation, the update notification may include the device's identifier (e.g., a device token used to identify the device anonymously), a list of updates available for the device, description of each update, an update package identifier associated with each update, priority associated with each update, and/or the like.")
a database section configured to manage the generation state of the campaign notification information, ([0048-0049] "A connected device (e.g., a vehicle, a smartphone, an appliance, a smart lock, and/or the like device that is capable of network connectivity) is configured to log specified events. For example, logged events may include software and configuration updates events, system fault and performance events, system service usage notifications, telematic data, and/or the like. These events may be logged by the device's software system or by individual device components (e.g., peripheral units or electronic control units (ECUs)) and may be securely delivered in a structured data format to the cloud platform for storage in a big data storage repository and/or databases of individual analytics applications. In one implementation, events data may be structured based on a graph format that facilitates flexible and configurable logging without having to tightly couple the data model to the back end system." and [0300] shows the various properties associated with the states of the campaigns)
the compute service function section registers the generation state of the campaign notification information in a database according to content of the vehicle configuration information ([0300])
selects and activates the application program included in the compute service processing section ([2171] EN: Also see Bogineni [0075] "Event trigger detector 512 may monitor request queue DB 520 for requests that may correspond to a trigger condition associated with an on-demand process in event trigger DB 514 and/or may monitor state DB 530 for states that correspond to a trigger condition associated with an on-demand process in event trigger DB 514. For example, trigger detector 512 may monitor for a particular request from UE device 110, a particular request from another 5G function node, a particular request from an on-demand process associated with VNF MO 422 or another 5G function node, a particular network state associated with the on-demand process, a particular time period associated the on-demand process, and/or another type of trigger condition. Exemplary information that may be stored in event trigger DB 514 is described below with reference to FIG. 6B.")
Regarding Claim 4, Searle in view of Bogineni teaches The center device according to claim 3. Searle teaches wherein: a package distribution section configured to distribute to the vehicle, a package including the update data to be distributed to the vehicle ([0058-0059] "The update server may facilitate sending the requested update package to the device using a package download administering (PDA) component 341. See FIG. 6 for additional details regarding the PDA component. The update server may send an update download response 345 to the device. For example, the update server may send the requested update package to the device. In one implementation, the package file may be sent to the device. For example, the package file may include package parameters (e.g., package name, package version, package priority, package segment identifier, package rules, package checksum), software update modules (SUMs) and associated rules, and/or the like." and [0072] "FIG. 6 shows a logic flow diagram illustrating embodiments of a package download administering (PDA) component for the REDUP. In FIG. 6, an update download request may be received at 601. For example, the update download request may be received by an update server from a device. In one implementation, the update server may be dedicated to a particular OEM product provider (e.g., vehicle manufacturer). For example, data collected (e.g., logs) and/or provided (e.g., updates) by such update server may not be shared with other OEMs. In another implementation, the update server may be shared among multiple OEM product providers. For example, data collected and/or provided by such update server may be shared among the OEMs.")
Wherein the package distribution section performs distribution by transferring the update package associated with the campaign notification information to the network distribution section, ([0058,0072] also see [0082])
Bogineni teaches an application program that implements a function of the package distribution section adopts the serverless architecture ([0019])
Regarding Claim 5, Searle in view of Bogineni teaches The center device according to claim 4. Searle teaches wherein the application program that implements the function of the package distribution section includes the compute service function section configured to transfer the received update package to the network distribution section ([2248-2255] "FOTA Module Preparation. See FIG. 115. Sequence file: coordinates the CAN install of the component. SUM can contain multiple modules for the ECU. Gap Analysis: identifies changes to the existing sequence file for the ECU. Create Sequence script. Create EScript. Process file used for orchestrating multiple SUMs. Download files. From external SW vendor. Uploading FOTA SUM Modules. See FIG. 116. User uploads all files to the server: SW update, EXE, SBL, Sequence, Escript Workflow can plugin delta creation and other file processing tasks. System read sequence files and requests user to upload/associate Modules." EN: The FOTA module prepares and transfer the package to the server that distributes the packages)
Regarding Claim 6, Searle in view of Bogineni teaches The center device according to claim 2. Searle teaches further comprising:
a campaign registration section configured to register vehicle configuration information, campaign information of update data for a vehicle, and update data to be distributed together with the campaign information ([3092] "System supports multiple campaigns of software updates:
Multiple campaigns means it is more difficult to visualize inter-campaign dependencies, thus the following tool was created
A slider widget that shows vehicle history
Slider has a ‘Next Update point’ which defines the ‘Should Be’ state of the vehicle
Enables the Campaign manager to test what state each vehicles will be in after the publication of the update.
Takes into account parallel campaigns
As part of remote software management
Ability to manage multiple campaigns with dependent software
Ability for each vehicle to identify which software will be downloaded.
A slider widget that shows vehicle history
Slider has a ‘Next Update point’
Vehicles are getting complex
Multiple Campaigns of updates across multiple ECUs
Campaigns need to manage dependencies—complex
Need to test what-if scenarios
Slider widget allows you to test what if for specific vehicles" [3217] "Packages are collections of update files that are targeted to vehicles via segments. Package are targeted indirectly to vehicles through the product description. The packages are created using an administrator console function." Also see [2255] for the various update data included in the package)
Bogineni teaches wherein an application program that implements a function of the campaign registration section adopts the serverless architecture ([0019])
Regarding Claim 7, Searle in view of Bogineni teaches The center device according to claim 6. Searle teaches wherein
an application program that implements a function of the campaign registration section includes:
a compute service processing section configured to register the campaign information in a database and register the update data in a file storage section ([0048] and [1909] "The product facilitates the remote management and update of software and other assets. A console allows the upload and configuration of packages of files targeted for OTA download into connected devices. Packages are managed via a flexible work-flow process appropriate to the type of update. Processes includes: Application Store (Appshop), Software Component Updates (SOTA) and Firmware over the air (FOTA)." also see [3455-3456] for the various databases used as well as file storage options)
a compute service function section configured to transfer received campaign information to the compute service processing section ([1930] "A workflow enabled cloud platform provides the flexibility to be able to customize the processes for software management and delivery. For example, the server can be integrated with an existing quality assurance (QA) process or be used to define a process specific to the solution. The workflow enables pluggable components such as delta algorithms or content handlers." EN: The examiner chooses the QA process to be fifth compute service. It transfers quality related campaign info to the fourth service. See [3226-3231] for the QA workflow including response messages.)
a gateway section configured to transfer campaign information to the compute service processing section when a request for registration of the campaign information is input by either an operator or a manufacturing information system management system ([1909] "The product facilitates the remote management and update of software and other assets. A console allows the upload and configuration of packages of files targeted for OTA download into connected devices. Packages are managed via a flexible work-flow process appropriate to the type of update. Processes includes: Application Store (Appshop), Software Component Updates (SOTA) and Firmware over the air (FOTA)." [3217] "Packages are collections of update files that are targeted to vehicles via segments. Package are targeted indirectly to vehicles through the product description. The packages are created using an administrator console function." [3444] defines the gateway being a web server among other possibilities that allows the users through a web UI to create/modify packages/campaigns. )
the compute service processing section selects and activates an application program included in the compute service function section according to content of the campaign information ([1930] The fourth compute activates the QA service)
Regarding Claim 8, Searle in view of Bogineni teaches The center device according to claim 7. Searle teaches further comprising a package generation section configured to generate the package including the update data to be distributed to the vehicle ([0099-0100] "FIG. 19 shows a logic flow diagram illustrating embodiments of an update package configuring (UPC) component for the REDUP. In FIG. 19, a package configuring request may be obtained at 1901. For example, the package configuring request may be obtained when a REDUP administrator initiates configuration of an update package.")
Wherein the package generation section processes the received update data into the update package in a format interpretable by a master device that is mounted on a vehicle and transfers to an electronic control device to be updated ([2248] "
FOTA Module Preparation. See FIG. 115.
Sequence file: coordinates the CAN install of the component
SUM can contain multiple modules for the ECU
Gap Analysis: identifies changes to the existing sequence file for the ECU
Create Sequence script
Create EScript. Process file used for orchestrating multiple SUMs.
Download files. From external SW vendor" and [2093] "
Solution:
Provides leadership in this area
Partner with Movimento to provide a cloud managed ECU update service
Centralized approach puts connected services proxy in the vehicle to manage and install updates
Customized Delta algorithm (Redbend strength)
OMA-DM compliant solution")
Bogineni teaches an application program that implements a function of the package generation section adopts the serverless architecture ([0019])
Regarding Claim 9, Searle in view of Bogineni teaches The center device according to claim 8. Searle teaches further comprising: a data management section that is configured to transfer the vehicle configuration information and a corresponding update data that are registered in the file storage section to the package generation section in response to a request from the package generation section ([0100-0101] "FIG. 19 shows a logic flow diagram illustrating embodiments of an update package configuring (UPC) component for the REDUP. In FIG. 19, a package configuring request may be obtained at 1901. For example, the package configuring request may be obtained when a REDUP administrator initiates configuration of an update package. Parameters for the package may be determined at 1905. In one embodiment, parameters for the package may be specified by a REDUP administrator. For example, the REDUP administrator may specify a priority associated with the package. In another embodiment, parameters for the package may be calculated. For example, a checksum may be calculated for the package. The determined parameters may be associated with the package at 1909. For example, the parameters may be saved as part of the package file." [0113-0115] "FIG. 26 shows an exemplary architecture for the REDUP. In FIG. 26, sensors of a connected device may provide a variety of event data. Events maybe logged in accordance with a data model. In one embodiment, the data model may be specified by ontologies. See FIGS. 30 and 31 for examples of ontologies. Logged events may be delivered by a log event notification (LEN) client to a cloud server for storage in a big data storage repository and/or databases of individual analytics applications. Adapters may be utilized to filter and/or format logged events data in accordance with each database's specifications. Logged events data may be utilized in a variety of analytics applications including fault analysis, predictive analytics, service (e.g., warranty repair predictions), surveillance, planning (e.g., future products), inference-based analytics, and/or the like. In one implementation, the cloud server may be dedicated to a particular OEM product provider (e.g., vehicle manufacturer). For example, data collected by such cloud server may not be shared (e.g., isolates data for vehicle makes and models not to be shared with other OEMs) with other OEMs. In another implementation, the cloud server may be shared among multiple OEM product providers…FIG. 27 shows a datagraph diagram illustrating embodiments of a data flow for the REDUP. In FIG. 27, dashed arrows indicate data flow elements that may be more likely to be optional. In FIG. 27, a connected device 2702 may log events and upload logged events data using an even logging administering (ELA) component 2721. See FIG. 28 for additional details regarding the ELA component.")
Bogineni wherein an application program that implements a function of the data management section adopts the serverless architecture ([0019])
Regarding Claim 10, Searle in view of Bogineni teaches The center device according to claim 2. Searle teaches wherein the status management section assigns a job number for a request received from an outside, and assigns status information indicating whether the request is being processed or the process is completed ([0399] "5 For updates, the DM Client will collect all nodes that have an EXEC operation. These will be the ./DownloadAndUpdate child node of the FUMO object. All FUMO nodes with REMOVE operation identify applications that should be removed from the device. The DM client then generates an update identifier, that ensures that all of the updates received in this sync are applied at the same time, and that the installation events are issued in the correct order." Please see [0399] for the various updates statues. [0073-0074] "A device identifier associated with the update download request may be determined at 605. In one embodiment, the update download request may be parsed (e.g., using PHP commands) to determine the device identifier. An update identifier and/or an update package identifier associated with the update download request may be determined at 609. In one embodiment, the update download request may be parsed (e.g., using PHP commands) to determine the update identifier and/or the update package identifier. A determination may be made at 613 whether the device associated with the device identifier is authorized to get the update associated with the update identifier and/or the update package identifier. In one embodiment, a segment associated with the update may be determined (e.g., based on the update identifier, based on the update package identifier), and a determination may be made whether the device is associated with the segment. A device associated with the segment may be authorized to get the update, while a device not associated with the segment may not be authorized to get the update.")
Regarding Claim 11, Searle in view of Bogineni teaches The center device according to claim 10. Searle teaches wherein the campaign transmission section assigns the job number when transmitting a response that is a response to the request to the outside ([0557] "
6 An update identifier is generated for the OMA-DM sync
7 The OMA-DM sync returns two FUMO nodes that have an EXEC command associated to them. Each is assigned the update identifier #1.
11 Once the OMA-DM sync has completed, the EVENT_TYPE_HTML5_APP_AVAILABLE event is issued.
12 The system indicates that the update should be installed by issuing the EVENT_TYPE_START_DOWNLOAD event with the previously generated update id.
13 As the Installer starts the downloads, the FUMO ./State node is set to DOWNLOAD_IN_PROGRESS.
15 On the server a new file is uploaded and made available to clients")
Regarding Claim 12, Searle in view of Bogineni teaches The center device according to claim 11. Searle teaches the application program includes a distribution destination management section configured to manage to which outside the campaign notification information is to be distributed ([3194-3195] "Another requirement of software management is the ability to notify vehicles in a timely manner and as appropriate when updates are published. This targeted notification is a means of requesting vehicles to contact the server to ascertain whether there are updates available. It is a means of avoiding having every vehicle contact the server each day to check for updates. It is also a means of controlling from the server the priority, ordering and load spreading for updates. Ideally, notifications would only go out to specific vehicles that require the update. However, with variations in vehicle product (model, trim levels, customizations), production and, subsequently, with changes to vehicles over their lifetime identifying exactly which vehicles to notify is a matter of smart vehicle group management.")
Bogineni teaches an application program that implements a function of the distribution destination management section adopts the serverless architecture ([0019])
Regarding Claim 13, Searle in view of Bogineni teaches The center device according to claim 12. Searle teaches wherein:
when receiving a request to which the job number is assigned from the outside, the distribution destination management section assigns and registers a connection number associated with the job number ([0203] "
Step Description
1 By default the device identity is stored in the configuration file. This can be overridden by the set_device_identity API.
3 The Presence Client is notified when the network is connected. This will also happen when the device first starts.
4 If the Installer is currently installing (not downloading) an update then the PresenceClient should wait until it has completed.
5 The Presence Client registers the device with the Update Server based on the previously acquired identity, device_identity, and a secret password device_password. A timestamp is also generated and sent to the server to prevent replay attacks.
6 A unique remote token is generated for the device. The remote device token is used to identify the device anonymously. This prevents the device being sent notifications based on knowledge of the device identity.")
when there is a request for which processing is completed by referring to a database section, the status management section identifies an outside which is a transmission destination of a response based on the connection number corresponding to the job number of the request; and
the campaign transmission section transmits a response to an identified outside ([0203] "
7 The Update Server creates a notification topic based on the generated device token that will be used to send messages to the device.
8 The remote device token is sent back to the client
9 If the server responds with an error, or with invalid JSON (i.e. no token) then report the error and wait for a pre-configured time period…
14 The client subscribes to the previously created topic, based on the received remote device token
16 The Update Server sends a message to the device using the remote device token
17 The client receives the message and interprets the payload. The payload can be used to determine the type of message. For example an application update is available, or that a user profile update is available." EN: once a connection is established, the server responds to the connected device based on its specific information)
Regarding Claim 14, Searle in view of Bogineni teaches The center device according to claim 10. Searle teaches wherein the outside corresponds to an in-vehicle device or an operation person ([1947] "The REDUP Client is a client resident on the vehicle. It provides the capability for the vehicle software to be updated remotely and for the vehicle to report installation and software faults. The update client can be configured to run as part of the vehicle head unit or as a dedicated update ECU. See FIG. 93." [0083] "the connected device may be associated with one or more segments (e.g., based on the vehicle's model and trim). A REDUP administrator (e.g., a product manager) may define which apps are available for which segments. Accordingly, the user may install apps, which are approved for segments associated with the connected device, on the connected device. In one embodiment, the user may utilize the connected device (e.g., the user interface of the vehicle's infotainment system) to select a desired app available from a storefront server (e.g., a separate cloud hosted storefront, a part of the hosted cloud platform).")
Regarding Claim 15, Searle in view of Bogineni teaches The center device according to claim 3. Searle teaches wherein the application program includes a processing capability adjustment section configured to, when checking a processing load of the compute service processing section configured to generate the campaign notification information for the vehicle and a total number of pieces of the vehicle configuration information received from the vehicle, determine whether it is necessary to increase or decrease a processing capability of the compute service processing section, and increase or decrease the processing capability of the compute service processing section as necessary ([1905] "REDUP Server is typically implemented on industry standard Web Server class servers—dual processor, 4 Gbytes RAM, local disk for OS and application installation and shared network storage or SAN for shared data access. The REDUP Server application scales horizontally according to the number of devices supported." Also see [3476-3478] showing distributed components, dynamic instantiation and load balancing across nodes to cale on demand)
Bogineni teaches the processing capability adjustment section adopts the serverless architecture ([0019])
Claims 19 are method claims reciting limitations similar to claims 2 and are rejected under the same rationale.
Claims 20 are rejected under 35 U.S.C. 103 as being unpatentable over Searle et al. (US20160196132A1) in view of Bogineni et al. (US20190324813A1) further in view of AWS Lambda (AWS Lambda now supports batch windows) and further in view of Brand et al. (US-20200311034-A1)
Regarding Claim 20, Searle in view of Bogineni and further in view of AWS Lambda teaches the center device according to claim 1.
Brand teaches wherein: the campaign notification information includes download URL information, a start date and time at which access to content is permitted, an expiration date or period during which access to the content is permitted, and a signed URL ([0012] “Certain embodiments disclosed herein also include a non-transitory computer readable medium having stored thereon instructions for causing a processing circuitry to execute a process, the process comprising: sending, from a client device to a global file system storing a file, a request to access at least a portion of the file, wherein the global file system includes at least one object storage system and at least one server, wherein the data of the file is stored in a plurality of objects stored in the at least one object storage system; receiving, at the client device, a cloud file descriptor from the at least one server, wherein the cloud file descriptor includes a plurality of download tokens utilized to retrieve at least one object of the plurality of objects from the at least one object storage system, wherein the at least one object includes the requested at least a portion of the file; and accessing, by the client device, the at least a portion of the file using the cloud file descriptor.” [0028] “The client device is configured to access the at least a portion of the first file in the object storage systems using the cloud file descriptor. Because the client device is provided with metadata needed to access the objects, the client device may access those objects directly, thereby reducing load on servers operating within the execution context of the global file system. Such metadata typically includes temporary authorization credentials or tokens in a form such as a pre-signed uniform resource locator (URL).” [0091] “The download tokens may also be encoded as signed URLs. The upload and download tokens may be time limited and have an expiration date and time. After the expiration date and time, the token is considered invalid by the object storage system. Upon recognizing that a token is invalid, the client device may request a new cloud file descriptor containing new tokens having an extended expiration date. Additionally, the cloud file descriptor 600 may include one or more encryption keys. A single cloud file descriptor may contain tokens for multiple object storage systems. A cloud file descriptor may represent a full file or a portion of a file.” [0058] “The client device may use the cloud file descriptor in order to fetch the needed data from the one or more object storage systems, typically over the hypertext transfer protocol secure (HTTPS), and then use the decryption keys in order to decipher the data. The client device may fetch all the objects in order to reconstruct the entire file, or fetch only some objects, or specific byte ranges of some objects, in order to allow a partial file read.” EN: The start date is when the token is provided. Searle [0286] Also teaches download URL: “x/Download/PkgURL—This node specifies the URL where the update module can be downloaded from“ [0203] teaches the start time: “5 The Presence Client registers the device with the Update Server based on the previously acquired identity, device_identity, and a secret password device_password. A timestamp is also generated and sent to the server to prevent replay attacks.”)
a network distribution section verifies a signature of the signed URL using a public key and verifies that the expiration date has not passed before distributing the update data to the vehicle ([0058], [0087-0088] and [0091])
Searle teaches an information control section periodically checks an expiration state of the signed URL and, when the signed URL has expired, generates updated access control information having a new expiration date and updates a database section ([1394] The HTTP content includes the token and the expiration variable [1318] function 6.5.3.2 covers the renewal of the access token)
Searle, Bogineni, AWS Lambda and Brand are analogous art because they are from the same field of endeavor in update and deployment architecture. While Searle focuses on deployment of update campaigns for vehicles, AWS Lambda provides both the serverless architecture as well as the timed queuing service when passing messages between different service components. Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to combine Searle, Bogineni, AWS Lambda and Brand to apply Brand’s protected signed URLs for vehicle update deployment with expected results. A POSITA would be motivated to do so to improve security in the distribution of vehicle updates.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Sakurai et al. (US20200050378A1): discloses vehicle information communication system.
Sakurai_2 et al. (WO2021187071A1): discloses a center device generating and distributing update packages.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIR DARWISH whose telephone number is (571)272-4779. The examiner can normally be reached 7:30-5:30 M-Thurs.
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, Lewis Bullock can be reached on 571-272-3759. 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.
/A.E.D./Examiner, Art Unit 2199
/DUY KHUONG T NGUYEN/Primary Examiner, Art Unit 2199
Prosecution Insights