DETAILED ACTION
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 .
This Office Action is in response to the filing date of 4/24/2024.
Claims 1-23 are pending and have been considered below.
Title of Invention is Not Descriptive
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-2 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-2 of copending Application No. 18675823 and 18750007 respectively. Although the claims at issue are not identical, they are not patentably distinct from each other. The tables below show mappings between the claims of the instant application and the two copending applications.
Application No. 18645001
Copending Application No. 18675823
1. 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,
1. 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,
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, and
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, and
an application program implementing at least one of the functions, other than the at least one of the functions implemented by the application program that adopts the server architecture, 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.
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, and in which the resource allocated to the application program is released when the execution of the code is terminated,
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; a campaign generation section that is configured to generate campaign notification information for the vehicle when there is the campaign information;
a status management section that is configured to manage a generation state of the campaign notification information; and a campaign transmission section that is configured to distribute the campaign notification information to the vehicle according to the generation state, 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.
2. 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,
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.
2. 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,
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,
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; a campaign generation section that is configured to generate campaign notification information for the vehicle when there is the campaign information; a status management section that is configured to manage a generation state of the campaign notification information; and a campaign transmission section that is configured to distribute the campaign notification information to a vehicle according to the generation state, 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.
Application No. 18645001
Copending application No. 18750007
1. 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,
1. A vehicle communication system configured to implement, by application programs, a plurality of functions for managing data to be written into an electronic control unit mounted on a vehicle and transmitting update data to the vehicle by wireless communication,
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, and
wherein an application program of the application programs implementing at least one of the functions employs a server architecture in which a resource is always allocated and that is executed as a resident-type process,
an application program implementing at least one of the functions, other than the at least one of the functions implemented by the application program that adopts the server architecture, 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.
an application program of the application programs implementing at least another one of the functions employs 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
the vehicle communication system comprising: a campaign determination section that is configured to receive vehicle configuration information from a vehicle and determine whether there is campaign information for the vehicle; a campaign generation section that is configured to generate campaign notification information for the vehicle when there is the campaign information; a status management section that is configured to manage a generation state of the campaign information; and a campaign transmission section that is configured to deliver the campaign notification information to a vehicle according to the generation state, wherein the vehicle communication system includes a center apparatus in which an application program that implements functions of the campaign determination section, the status management section, and the campaign generation section employs the serverless architecture, and an in-vehicle system that includes the electronic control unit and performs wireless communication with the center apparatus, when the in-vehicle system transmits a first request including vehicle information to the center apparatus, the campaign transmission section transmits an intermediate response including a job ID corresponding to the request to the in-vehicle system, and when receiving the intermediate response, the in-vehicle system transmits a response request of a final response corresponding to the first request to the center apparatus as a second request to which the job ID is assigned.
2. 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,
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.
2. A vehicle communication system configured to implement, by application programs, a plurality of functions for managing data to be written into an electronic control unit mounted on a vehicle and transmitting update data to the vehicle by wireless communication, wherein an application program of the application programs implementing at least one of the functions employs 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,
the vehicle communication system comprising: a campaign determination section that is configured to receive vehicle configuration information from a vehicle and determine whether there is campaign information for the vehicle; a campaign generation section that is configured to generate campaign notification information for the vehicle when there is the campaign information; a status management section that is configured to manage a generation state of the campaign information; and a campaign transmission section that is configured to deliver the campaign notification information to a vehicle according to the generation state, wherein the vehicle communication system includes a center apparatus in which an application program that implements functions of the campaign determination section, the status management section, and the campaign generation section employs the serverless architecture, and an in-vehicle system that includes the electronic control unit and performs wireless communication with the center apparatus, when the in-vehicle system transmits a first request including vehicle information to the center apparatus, the campaign transmission section transmits an intermediate response including a job ID corresponding to the request to the in-vehicle system, and when receiving the intermediate response, the in-vehicle system transmits a response request of a final response corresponding to the first request to the center apparatus as a second request to which the job ID is assigned.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-2 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claims do not fall within at least one of the four categories of patent eligible subject matter because the claimed center device appears reasonable to interpret by one of an ordinary skilled in the art as a software component. Applicant’s specification provides no explicit and deliberate definition of the center device other than it could be interpreted as a software component. Since software is not directed to one of the four patent eligible subject matter categories, the claims are not eligible subject matter under 35 U.S.C. 101.
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-23 are rejected under 35 U.S.C. 103 as being unpatentable over Lee “Automotive ECU Software Reprogramming Method Based on Ethernet Backbone Network to Save Time” and Aslanpour ("Serverless Edge Computing: Vision and Challenges”).
Per claim 1, Lee 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 (see at least page 5, col.1 “The proposed reprogramming method of an ECU provides a processing of reprogramming data transmission based on Ethernet-based communication between the PCU and the DCU, and CAN/FlexRay-based communication between the DCU and the target ECUs…”),
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 (see at least page 5, col.2 “…when multiple buffers are allocated for data transmission…”).
Lee does not explicitly teach
an application program implementing at least one of the functions, other than the at least one of the functions implemented by the application program that adopts the server architecture, 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.
Aslanpour teaches serverless edge computing, comprising:
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 (see at least page 4, col.1 “Serverless platform…The handler edge node will pass the event and its associated data such as authentication, API identifier, etc. to the controller component, bringing Serverless into gear…Execution: Once the message is handed to the execution engine, the engine acts on provisioning run-time environment for the corresponding function, either by reusing an already instantiated, but idle, function or by creating a new instance of the function…Computation: To create a new instance, the requested computing resources are allocated by the computing component. The data, the function’s state and the required libraries for executing a task in the functions are pulled from the storage component…”) and in which the resource allocated to the application program is released when the execution of the code is terminated (see at least page 2, col.1 “…The main questions of this research include: “Is Serverless adaptable to edge computing? and how?” In principle, its scale-to-zero property (i.e., unused containers are deallocated from the platform) suits very well energy-aware IoT use cases with intermittent applications, while fine-grained scaling (i.e., at a function level) may easily accommodate the vastly heterogeneous requirements and execution environments at the edge…”).
It would have been obvious for a person of an ordinary skilled in the art as of the effective filing date of the claimed invention to modify the teaching of Lee to incorporate the teaching of Aslanpour to adopt a serverless platform for managing resource usage. One would have been motivated to adopt a serverless platform in order to eliminate always-on-services causing high resource usage.
Per claim 2, Lee 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 (see at least page 5, col.1 “The proposed reprogramming method of an ECU provides a processing of reprogramming data transmission based on Ethernet-based communication between the PCU and the DCU, and CAN/FlexRay-based communication between the DCU and the target ECUs…”).
Lee does not explicitly teach
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.
Aslanpour teaches serverless edge computing, comprising:
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 (see at least page 4, col.1 “Serverless platform…The handler edge node will pass the event and its associated data such as authentication, API identifier, etc. to the controller component, bringing Serverless into gear…Execution: Once the message is handed to the execution engine, the engine acts on provisioning run-time environment for the corresponding function, either by reusing an already instantiated, but idle, function or by creating a new instance of the function…Computation: To create a new instance, the requested computing resources are allocated by the computing component. The data, the function’s state and the required libraries for executing a task in the functions are pulled from the storage component…”) and in which the resource allocated to the application program is released when the execution of the code is terminated (see at least page 2, col.1 “…The main questions of this research include: “Is Serverless adaptable to edge computing? and how?” In principle, its scale-to-zero property (i.e., unused containers are deallocated from the platform) suits very well energy-aware IoT use cases with intermittent applications, while fine-grained scaling (i.e., at a function level) may easily accommodate the vastly heterogeneous requirements and execution environments at the edge…”).
It would have been obvious for a person of an ordinary skilled in the art as of the effective filing date of the claimed invention to modify the teaching of Lee to incorporate the teaching of Aslanpour to adopt a serverless platform for managing resource usage. One would have been motivated to adopt a serverless platform in order to eliminate always-on-services causing high resource usage.
Per claim 3, Lee incorporated Aslanpour further teach:
a campaign determination section that receives vehicle configuration information from a vehicle and determines whether campaign information for the vehicle is present (in Lee, see at least page 4, col.2 “…when DCU receives the reprogramming response message (CAN or FlexRay frame) from the target ECU, the DCU extracts a received PDU ID (Rx PDU ID), and it searches for the corresponding socket ID (to send the reprogramming response data to the socket connection that receives the reprogramming request data) from the diagnostic routing table…”);
a campaign generation section that generates campaign notification information for the vehicle when the campaign information is present (in Lee, see at least page 4, col.2 “…If the DCU successfully finds the corresponding socket ID, the response data is packed in the DoIP frame…”); and
a campaign transmission section that delivers the campaign notification information to the vehicle (in Lee, see at least page 4, col.2 “…the DoIP frame storing the response data is sent to an Ethernet-based source network using the socket connection (having the corresponding socket ID)…”), wherein an application program that implements functions of the campaign determination section and the campaign generation section adopts the serverless architecture (in Aslanpour, see at least page 4, col.1 “Serverless Platform…“).
Per claim 4, Lee incorporated Aslanpour further teach:
wherein the application program includes:
a first compute service section that transfers the vehicle configuration information received from the vehicle via a gateway section to the campaign determination section (in Lee, see at least page 4, col.2 “A conventional in-vehicle gateway system provides three types of routing methods, including frame based-routing, PDU based-routing, signal based-routing [8]. The DCU applied the proposed reprogramming method is use to PDU-based-routing for routing of the reprogramming data. Figure 5 shows an example of reprogramming data routing between the PCU and the target ECU”); and
a second compute service section that determines, as the campaign determination section and the campaign generation section, based on the vehicle configuration information, whether the campaign information for the vehicle is present and that generates the campaign notification information for the vehicle when the campaign information is present (in Lee, see at least page 4, col.2 “…When DCU receives the reprogramming request message based on the diagnostics over internet protocol (DoIP) frame from PCU, the DCU extracts and confirms a data type field from the header of the received DoIP frame. If the value of the data type field is the reprogramming type, then the DCU extracts an address value of the target ECU from the target address field of the DoIP frame. Moreover, the DCU searches for the corresponding information of the target network that is included in the target ECU, from the diagnostic routing table described in Table I. If the DCU successfully finds the corresponding routing information, it updates the socket ID in the diagnostic routing table, which can be used with a socket adapter stack as an identifier to distinguish between socket connections and is dynamically assigned when each socket connection is established by the socket adapter…”).
Lee does not explicitly teaches:
the first compute service section selects and activates an application program included in the second compute service section, in accordance with a content of the vehicle configuration information.
Aslanpour teaches an analogous art relates to serverless architecture, comprising:
selects and activates an application program in accordance with a content of information (see at least page 4, col.1 “The Serverless platform consists of three main layers: coordination, execution and computation. Coordination: The handler edge node will pass the event and its associated data such as authentication, API identifier, etc. to the controller component, bringing Serverless into gear. The controller acts as a load balancer. If the admitted event message is valid and the incoming load is not heavy, it is passed to the scheduler component, which based on the triggers and rules sends the message to corresponding execution engine (or so-called worker [23]) associated to a function…Execution: Once the message is handed to the execution engine, the engine acts on provisioning run-time environment for the corresponding function…Computation: To create a new instance, the requested computing resources are allocated by the computing component”).
It would have been obvious for a person of an ordinary skilled in the art as of the effective filing date of the claimed invention to modify the teaching of Lee to incorporate the teaching of Aslanpour to active program applications based on events/contents. One would have been motivated to adopt a serverless platform in order to eliminate always-on-services causing high resource usage.
Per claim 5, Lee incorporated Aslanpour further teach:
wherein the first compute service section is activated upon reception of the vehicle configuration information as an event, and the second compute service section is activated upon an instruction of activation by the first compute service section as an event (in Aslanpour, see at least page 5, col.1 “Event-driven Applications…”)
Per claim 6, Lee incorporated Aslanpour further teach:
a package distribution section that delivers to the vehicle a package including the update data to be delivered to the vehicle, wherein the package distribution section performs delivery by transferring an update package associated with the campaign information to a network distribution section (in Lee, see at least page 4, col.2, Figure 5), and
an application program that implements a function of the package distribution section adopts the serverless architecture (in Aslanpour, see page 4, col.1 “Serverless Platform”).
Per claim 7, Lee incorporated Aslanpour further teach:
wherein the application program that implements the function of the package distribution section includes a third compute service section that transfers to the network distribution section the update package received (in Lee, see at least page 4, col.2, Figure 5).
Per claim 8, Lee incorporated Aslanpour further teach:
a campaign registration section that registers vehicle configuration information, campaign information of update data for the vehicle, and update data to be distributed together with the campaign information (in Lee, see at least page 4, col.2 Figure 5), wherein an application program that implements a function of the campaign registration section adopts the serverless architecture (in Aslanpour, see page 4, col.1 “Serverless Platform”).
Per claim 9, Lee incorporated Aslanpour further teach:
wherein the application program that implements the function of the campaign registration section includes:
a gateway section that, when a registration request of the campaign information is input, transfers the campaign information to a fifth compute service section (in Lee, see at least page 4, col.2 “Figure 5”);
the fifth compute service section that transfers to a sixth compute service section the campaign information received; the sixth compute service section that selects and activates an application program included in a fourth compute service section in accordance with a content of the campaign information (in Aslanpour, see at least page 4, col.1 “The Serverless platform consists of three main layers: coordination, execution and computation. Coordination: The handler edge node will pass the event and its associated data such as authentication, API identifier, etc. to the controller component, bringing Serverless into gear. The controller acts as a load balancer. If the admitted event message is valid and the incoming load is not heavy, it is passed to the scheduler component, which based on the triggers and rules sends the message to corresponding execution engine (or so-called worker [23]) associated to a function…Execution: Once the message is handed to the execution engine, the engine acts on provisioning run-time environment for the corresponding function…Computation: To create a new instance, the requested computing resources are allocated by the computing component”); and
the fourth compute service section that registers the campaign information in a database and registers the update data in a file storage section (in Lee, see at least page 4, col.2 “Figure 5 – After the search for the routing table is complete, the DCU copies the reprogramming data (that is stored in the data field of the DoIP frame) in the reprogramming dedicated buffer, and forwards the stored data in the buffer to the target network via a segmentation using TP…”)
Per claim 10, Lee incorporate Aslanpour further teach:
wherein the fifth compute service section is activated upon reception of the campaign information as an event, the sixth compute service section is activated upon an instruction of activation as an event and receives the campaign information, and the fourth compute service section is activated upon an instruction of activation by the sixth compute service section as an event (in Aslanpour, see at least page 4, col.1 “The Serverless platform consists of three main layers: coordination, execution and computation. Coordination: The handler edge node will pass the event and its associated data such as authentication, API identifier, etc. to the controller component, bringing Serverless into gear. The controller acts as a load balancer. If the admitted event message is valid and the incoming load is not heavy, it is passed to the scheduler component, which based on the triggers and rules sends the message to corresponding execution engine (or so-called worker [23]) associated to a function…Execution: Once the message is handed to the execution engine, the engine acts on provisioning run-time environment for the corresponding function…Computation: To create a new instance, the requested computing resources are allocated by the computing component”).
Per claim 11, Lee incorporated Aslanpour further teach:
a package generation section that generates a package including the update data to be delivered to the vehicle, wherein the package generation section processes the package including the update data into an update package in a format interpretable by a master device that is mounted on the vehicle and transfers the update data received to an electronic control device to be updated (in Lee, see at least page 4, col.2 “Figure 5”), and an application program that implements a function of the package generation section adopts the serverless architecture (in Aslanpour, see at least page 4, col.1 “Serverless Platform”).
Per claim 12, Lee incorporated Aslanpour further teach:
a data management section that transfers, in response to a request from the package generation section, the vehicle configuration information and corresponding update data that are registered in the file storage section, to the package generation section (in Lee, see at least page 4, col.2 “Figure 5”), wherein an application program that implements a function of the data management section adopts the serverless architecture (in Aslanpour, see at least page 4, col.1 “Serverless Platform”).
Per claim 13, Lee incorporated Aslanpour further teach:
an access buffer control section that buffers and stores, before transferring vehicle configuration information received from a vehicle to a campaign registration section, the configuration information for a certain period of time, and then collectively transfers the vehicle configuration information received within the certain period of time to the campaign registration section (in Lee, see at least page 5, col.2 “Figure 6”).
Per claim 14, Lee incorporated Aslanpour further teach:
wherein the access buffer control section includes: a plurality of queuing buffers to which priority is assigned in a processing order for each vehicle model (in Lee, see at least page 2, col.1 “The traditional IVNs consist to meet the requirements of different network domains (body, chassis, powertrain and multimedia) such as Local Interconnect Network (LIN), CAN, FlexRay and Media Oriented Systems Transport (MOST) [1]. LIN is a low cost serial communication that provides an efficient communication for applications that do not require high-performance with low-bandwidth, master-slave communication such as a power window, and a seat control system. CAN is a dominant protocol for the current IVNs because it has several advantages, including low cost, noise immunity, ease of installation, and widespread use. However, CAN cannot provide real-time performance because it is used for the CSMA/BA scheme, whereby the transmission of a low priority message can be delayed when exchanged massages are increased in the CAN bus due to increased ECUs and exchange messages by ECUs…”); and a queuing buffer control section that interprets the vehicle model based on the vehicle configuration information and stores the vehicle configuration information in a corresponding queuing buffer (in Lee, see at least page 5, col.2 “Figure 6”), an application program that implements a function of the queuing buffer control section adopts the serverless architecture (in Aslanpour, see at least page 4, col.1 “Serverless Platform”).
Per claim 15, Lee incorporated Aslanpour further teach:
wherein the access buffer control section includes: a plurality of queuing buffers to which priority is assigned in correspondence to a length of a time-out period that is set for each vehicle model and is an index of a time period from when data is input to when the data is output from the access buffer control section (in Aslanpour, see at least page 4, col.1 “…which based on the triggers and rules sends the message to corresponding execution engine (or so-called worker) associated to a function; otherwise, it is kept in the queue component for certain reasons such as failure handling and mitigating message loss and in another iteration it is passed to the scheduler. The concept of queue here is deemed to keep messages for no more than a brief of milliseconds…”); and a queuing buffer control section that interprets the length of the time-out period based on the vehicle configuration information and stores the vehicle configuration information in a corresponding queuing buffer, and an application program that implements a function of the queuing buffer control section adopts the serverless architecture (in Aslanpour, see at least page 4, col.1 “Serverless Platform”).
Per claim 16, Lee incorporated Aslanpour further teach:
wherein the access buffer control section includes:
a plurality of queuing buffers to which priority is assigned in a processing order in accordance with an attribute of the campaign information (in Lee, see at least page 2, col.1 “The traditional IVNs consist to meet the requirements of different network domains (body, chassis, powertrain and multimedia) such as Local Interconnect Network (LIN), CAN, FlexRay and Media Oriented Systems Transport (MOST) [1]. LIN is a low cost serial communication that provides an efficient communication for applications that do not require high-performance with low-bandwidth, master-slave communication such as a power window, and a seat control system. CAN is a dominant protocol for the current IVNs because it has several advantages, including low cost, noise immunity, ease of installation, and widespread use. However, CAN cannot provide real-time performance because it is used for the CSMA/BA scheme, whereby the transmission of a low priority message can be delayed when exchanged massages are increased in the CAN bus due to increased ECUs and exchange messages by ECUs…”); and
a queuing buffer control section that interprets the attribute of the campaign information based on the vehicle configuration information and stores the vehicle configuration information in a corresponding queuing buffer (in Lee, see at least page 5, col.2 “Figure 6”), an application program that implements a function of the queuing buffer control section adopts the serverless architecture (in Aslanpour, see at least page 4, col.1 “Serverless Platform”).
Per claim 17, Lee incorporated Aslanpour further teach:
a transmission source determination section that determines, when the vehicle configuration information is transmitted also from an information communication terminal other than the vehicle, a transmission source of the vehicle configuration information (in Lee, see at least page 4, col.2 “When DCU receives the reprogramming request message based on the diagnostics over internet protocol (DoIP) frame from PCU, the DCU extracts and confirms a data type field from the header of the received DoIP frame. If the value of the data type field is the reprogramming type, then the DCU extracts an address value of the target ECU from the target address field of the DoIP frame…”), wherein the access buffer control section includes: a plurality of queuing buffers to which priority is assigned in a processing order in accordance with the transmission source; and a queuing buffer control section that determines the transmission source based on the vehicle configuration information and stores the vehicle configuration information in a corresponding queuing buffer (in Lee, see at least page 4, col.2 “…the DCU searches for the corresponding information of the target network that is included in the target ECU, from the diagnostic routing table described in Table I. If the DCU successfully finds the corresponding routing information, it updates the socket ID in the diagnostic routing table, which can be used with a socket adapter stack as an identifier to distinguish between socket connections and is dynamically assigned when each socket connection is established by the socket adapter. After the search for the routing table is complete, the DCU copies the reprogramming data (that is stored in the data field of the DoIP frame) in the reprogramming dedicated buffer, and forwards the stored data in the buffer to the target network via a segmentation using TP…”), and an application program that implements a function of the queuing buffer control section adopts the serverless architecture (in Aslanpour, see at least page 4, col.1 “Serverless Platform”).
Per claim 18, Lee incorporated Aslanpour further teach:
wherein an information communication terminal is a smartphone or a personal computer (in Lee, see at least Figure 5 “PCU (programming control unit)”)
Per claim 19, Lee incorporated Aslanpour further teach:
a reserve state setting section that sets a resource that is to be used, to a reserve state before activating at least one or more of application programs adopting the serverless architecture (in Aslanpour, see at least page 4, col.1 “…Execution: Once the message is handed to the execution engine, the engine acts on provisioning run-time environment for the corresponding function, either by reusing an already instantiated, but idle, function or by creating a new instance of the function. The core auto-scaler is also embedded in this component. Note that Serverless platforms would keep the function instance alive and avoid instant termination for a short period to serve upcoming events…”).
Per claim 20, Lee incorporated Aslanpour further teach:
wherein the reserve state setting section periodically transmits to a target application program a command for checking whether communication is possible (in Aslanpour, see at least page 4, col.1 “The handler edge node will pass the event and its associated data such as authentication, API identifier, etc. to the controller component, bringing Serverless into gear. The controller acts as a load balancer. If the admitted event message is valid and the incoming load is not heavy, it is passed to the scheduler component, which based on the triggers and rules sends the message to corresponding execution engine (or so-called worker) associated to a function [5]; otherwise, it is kept in the queue component for certain reasons such as failure handling and mitigating message loss and in another iteration, it is passed to the scheduler. The concept of queue here is deemed to keep messages for no more than a brief of milliseconds…”).
Per claim 21, Lee incorporated Aslanpour further teach:
wherein the command is a Ping command (in Aslanpour, see at least page 7, col.2 “…Estimations show that only 2% of Serverless use cases are intended for real-time applications. The research community, however, has not been silent and proposed many promising solutions such as warm starts [1], function pinging, pre-loading critical packages for the container, utilizing further agile unikernels (or Web Assembly-based resources) instead of containers, and overhead reduction in development phase, to name a few….”).
Per claim 22, Lee incorporated Aslanpour further teach:
a transmission source determination section that determines, when vehicle configuration information is transmitted also from an information communication terminal other than the vehicle, a transmission source of the vehicle configuration information (in Lee, see at least page 4, col.2 “…When DCU receives the reprogramming request message based on the diagnostics over internet protocol (DoIP) frame from PCU, the DCU extracts and confirms a data type field from the header of the received DoIP frame…”);
an information processing server that adopts a server architecture that a resource is always allocated to and is executed as a resident-type process, the information processing server configured to perform processing of the vehicle configuration information (in Lee, see at least page 5, col.2 “…when multiple buffers are allocated for data transmission…”); and
an information processing control section that causes, when the transmission source is the information communication terminal, the information processing server to process the vehicle configuration information received (see at least page 4, col.2 “…the DCU extracts and confirms a data type field from the header of the received DoIP frame. If the value of the data type field is the reprogramming type, then the DCU extracts an address value of the target ECU from the target address field of the DoIP frame…”).
Per claim 23, Lee incorporated Aslanpour further teach:
wherein the information communication terminal is a smartphone or a personal computer (in Lee, see at least Figure 5 “PCU (programming control unit)”).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PHILLIP H NGUYEN whose telephone number is (571)270-1070. The examiner can normally be reached Monday-Friday 9:00AM-5:00PM.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20220250636 relates to serverless.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Wei Zhen can be reached at (571) 272-3708. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/PHILLIP H NGUYEN/Primary Examiner, Art Unit 2191
Prosecution Insights