DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This action is in response to the communication filed on 06/17/2026. Claims 1, 3-5, 7-12 and 15-16 are pending in this application.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 06/17/2026 has been entered.
Response to Amendment
The claim rejections under 35 U.S.C. 112(b) to claims 1, 3-5, 7-12 and 15 are now withdrawn in view of the claim amendments.
Applicant’s arguments with respect to claims 1, 3-5, 7-12 and 15-16 have been considered but are moot based on the new grounds of rejection necessitated by Applicant’s amendments. Specifically, the arguments present that Ayers-Heilpern fails to provide for the amended language, where the rejection below now relies on Ayers-Sharma-McDowall-Heilpern to teach this subject matter.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 4-5, 7-11 and 15 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim 4 recites the limitation “the server communication unit” in line 4. There is insufficient antecedent basis for this limitation in the claim.
Claim 5 recites the limitation “the application execution unit” in line 15. There is insufficient antecedent basis for this limitation in the claim.
The dependent claims of the above rejected claims are rejected due to their dependencies.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim 1, 5 and 11-12 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20200329460 A1 (hereinafter Ayers), in view of US 20210099394 A1 (hereinafter Sharma), in view of US 11477165 B1 (hereinafter McDowall) and in further view of US 20180054493 A1 (hereinafter Heilpern).
For Claim 1, Ayers teaches a management server (Ayers exemplifies a remote computing system 108 in FIG. 1) comprising: at least one of (i) a circuit and (ii) a processor with a memory storing computer program code executable by the processor, the at least one of the circuit and the processor configured to cause the management server (Ayers, FIG. 2; para. [0056] “… computing system 70 can include one or more processor(s) 210, one or more communication interfaces 212, and memory 214 (e.g., one or more hardware components for storing executable instructions, data, and/or the like) …”) to:
wirelessly communicate with a plurality of in-vehicle devices that are respectively mounted on a plurality of different vehicles (Ayers exemplifies the remote computing system communicating with a plurality of computing devices onboarding a plurality of vehicles in FIG. 1, FIG. 2 and para. [0040], para. [0041], para. [0042], para. [0051]), wherein each of the plurality of in-vehicle devices is configured to execute a plurality of application programs (Ayers, para. [0041]) …, and each of the plurality of application programs has application identification data for identifying each of the plurality of application programs (Ayers teaches the identifiers associated with the applications, FIG. 1, FIG. 2, FIG. 3; para. [0040] “… Autonomous vehicle 10 can include one or more sensors 124, computing system 102, and one or more vehicle controls 126 …”; para. [0041] “… Computing system 102 can include one or more computing devices 104. Computing device(s) 104 can include circuitry configured to perform one or more operations, functions, and/or the like described herein …”; para. [0042] “… Computing system 102 can be physically located onboard autonomous vehicle 10, and computing system(s) 108 can be distinct and/or remotely located from autonomous vehicle 10. Network(s) 106 (e.g., wired networks, wireless networks, and/or the like) can interface autonomous vehicle 10 (e.g., computing system 102, computing device (s) 104, and/or the like) with computing system(s) 108 …”; para. [0051] “… Referring to FIG. 2, as previously indicated, environment 100 can include autonomous vehicle 10, network(s) 106, and computing system(s) 108. Environment 100 can also include autonomous vehicle(s) 20 and/or 30, and/or computing device(s) 40, 50, and/or 60 …”; para. [0056] “… computing system 70 can include one or more processor(s) 210, one or more communication interfaces 212, and memory 214 (e.g., one or more hardware components for storing executable instructions, data, and/or the like). Communication interface(s) 212 can enable computing system 70 to communicate with autonomous vehicle 10 (e.g., computing system 102, computing device(s) 104, and/or the like), autonomous vehicle(s) 20 and/or 30, computing device(s) 40, 50, and/or 60, computing system(s) 80 and/or 90, and/or the like …”; para. [0062] “… At (304), for each application of the applications, computing system 102 can determine, from amongst multiple different and distinct interface identifiers (e.g., addresses, ports, links, and/or the like), an identifier associated with the application and can communicate (e.g., via the communication at (302), and/or the like), based at least in part on such identifier, data associated with the application and destined for computing system 80 towards computing system 80 …”);
Ayers does not explicitly teach, but Sharma teaches execute a plurality of application programs as containers (Sharm teaches executing application programs as containers and also teaches each application metadata may include an application ID and an content ID; para. [0015] “… A network system (e.g., a cloud based system) may include one or more pods within a network orchestration system. The one or more pods may include one or more containers, and one or more applications may run within these one or more containers …”; para. [0038] “… the application metadata may include application IDs, process IDs, host IDs, container IDs, service IDs, users, etc. …”); and
acquire communication information according to execution of each of the plurality of application programs from each of the plurality of … devices, wherein the communication information includes a communication traffic measured for each container identification which is a … identification attached to each of the plurality of … devices (Sharma teaches application traffic amount associated with a container ID, and a container associated with a host/device; FIG. 1, FIG. 5; para. [0035] “… A traffic analyzer ( e.g., 105) may inspect application data and network data to correlate application data with network data. In some cases, application data may be captured at a host and may be associated with corresponding applications ( e.g., users, services, processes, etc.). In some cases, network data may be captured at a virtual or physical device (e.g., a terminal access point (TAP)) …”; para. [0052] “… At 535, the traffic analyzer 505 may receive application traffic. In some cases, the application traffic may be originating from or ending at a container. The traffic analyzer 505 may receive application traffic and/or application metadata from a kernel library or module (e.g., libeBPFflow). In some cases, a kernel library or module may transmit the application traffic and/or application metadata to traffic analyzer 505. In some cases, the application traffic may contain source IP addresses, destination IP addresses, time stamp information, network protocol information, an amount of data, or any combination thereof. In some cases, the application traffic may contain application metadata (e.g., host ID, container ID, process ID, user, binary name, etc.) …”),
before generation of the communication information, the communication traffic is associated with the application identification data and managed in each of the plurality of … devices (Sharma teaches capturing the communication traffic associated with the application ID in the host/device before supplying the communication information to the traffic analyzer; FIG. 1; para. [0035] “… A traffic analyzer ( e.g., 105) may inspect application data and network data to correlate application data with network data. In some cases, application data may be captured at a host and may be associated with corresponding applications ( e.g., users, services, processes, etc.). In some cases, network data may be captured at a virtual or physical device (e.g., a terminal access point (TAP)) …”; para. [0038] “… a library or module may collect network traffic and extract application metadata while running in Linux Kernel mode. In some examples, the application metadata may include application IDs, process IDs, host IDs, container IDs, service IDs, users, etc. In some cases, the library or module may capture a limited amount of network bytes (e.g., flows) transferred between a source IP and destination IP at a given time … one or more Linux processes may be local processes …”), and
after the generation of the communication information by at least one of the plurality of in-vehicle devices, the communication information is acquired by being transmitted to the management server (Sharma teaches generating application traffic data on a host/device and transmitting the application traffic data to the traffic analyzer on a server; FIG. 1, FIG. 2, FIG. 5; para. [0035] “… A traffic analyzer ( e.g., 105) may inspect application data and network data to correlate application data with network data. In some cases, application data may be captured at a host and may be associated with corresponding applications ( e.g., users, services, processes, etc.). In some cases, network data may be captured at a virtual or physical device (e.g., a terminal access point (TAP)) …”; para. [0040] “… The traffic analyzer 205 may represent aspects of an application server, communication server, data processing server, database server, cloud-based server, server cluster, virtual machine, container, pod, host, or some similar data processing device or system …”; para. [0052] “… At 535, the traffic analyzer 505 may receive application traffic. In some cases, the application traffic may be originating from or ending at a container. The traffic analyzer 505 may receive application traffic and/or application metadata from a kernel library or module (e.g., libeBPFflow). In some cases, a kernel library or module may transmit the application traffic and/or application metadata to traffic analyzer 505 …”) …, …;
Sharma and Ayers are analogous art because they are both related to managing applications running on network devices.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use analyzing containerized application communication traffic techniques of Sharma with the system of Ayers to identify the originating application or container from the captured network traffic (Sharma, para.[0005]).
Ayers-Sharma does not explicitly teach, but McDowall teaches each container identification which is a temporary local identification (McDowall teaches the data plane (DP) container being able to be created and registered with a container ID to a management entity (e.g. management plane (MP) container), the DP container also being able to be destroyed, so that the container ID acting as a temporary local identification through the lifecycle of the container; FIG. 3A, FIG. 6; col. 12, l. 50 – col. 13, l. 11 “… FIG. 3A is a sequence diagram for creating a Data Plane (DP) container in an application pod in accordance … At stage 5, the DP Daemonset connects to its MP Container 310 and registers with the MP Container ( e.g., passes, cores allocated, containerID, pod name, and possibly other labels/ metadata to the MP Container) …”; col. 16, ll. 30-35 “… At 610, the security entity sends traffic log data from the security entity to a security management entity. For example, the security entity can periodically send the traffic log data to a security management entity or send such traffic log data to the security management entity prior to the application container/pod being destroyed …”), and
transmitting traffic log information to the management server/entity before the at least one of the plurality of … devices stops, in response to a determination that the at least one of the plurality of … devices is about to stop (McDowall teaches transmitting the traffic log data to the management entity before the application container is destroyed; Applying McDowall’s pre-destruction reporting technique to the vehicle device/container environment as taught by Ayers-Sharma produces a predictable timing adaptation – transmitting the generated traffic information while communication remains available to preserve data for server side processing; FIG. 6; col. 16, ll. 4-35 “… the security entity can be transparently deployed in the application container to seamlessly inspect all traffic including L7 application traffic for the application container (e.g., application pod) … At 610, the security entity sends traffic log data from the security entity to a security management entity. For example, the security entity can periodically send the traffic log data to a security management entity or send such traffic log data to the security management entity prior to the application container/pod being destroyed …”).
McDowall and Ayers-Sharma are analogous art because they are both related to managing applications running on network devices.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use reporting the monitored traffic before container destruction techniques of McDowall with the system of Ayers-Sharma to preserve the application communication data for server side data processing.
Ayers-Sharma-McDowall does not explicitly teach, but Heilpern teaches total the communication traffic associated with the application identification data for each application identification data (Heilpern teaches identifying network consumption records by application and totaling their received/transmitted byte traffic; FIG. 1, FIG. 2, FIG. 3, FIG. 6A; para. [0023] “… The application detector 124 generates usage data for applications executing on the mobile device 104 by aggregating network consumption data associated with applications over time …”; para. [0038] “… The application detector 124 associates 310 an application with a process by analyzing the network consumption data. For example, the AM application detector 124 associates an application from an application list of applications executing on the mobile device 104 with the process ID of the network consumption data. The application detector 124 determines 315 usage data for the application based on aggregating the network consumption data associated with the application over time …”; para. [0050] “… Meta_data is a group of such network pulses grouped by host-post-user agent combination and aggregating in/out bytes, duration, activity, timestamp during a period of 1 to n seconds …”); and
calculate an application communication traffic (Heilpern teaches calculating an aggregate quantity from communication consumption attributed to a particular application; FIG. 1, FIG. 4, FIG. 6A; para. [0050] “… Meta_data is a group of such network pulses grouped by host-post-user agent combination and aggregating in/out bytes, duration, activity, timestamp during a period of 1 to n seconds …”; para. [0085] “… The application detector 124 generates 430 usage data for the application by aggregating network consumption data associated with the application …”).
Heilpern and Ayers-Sharma-McDowall are analogous art because they are both related to managing applications running on network devices.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use calculating the application usage from the network traffic techniques of Heilpern with the system of Ayers-Sharma-McDowall to determine the amount of data being generated by various application and system activities on network devices (Heilpern para. [0019]).
For Claim 5, Ayers teaches a vehicle network system (Ayers, FIG. 1; para. [0039] “… Referring to FIG. 1, environment 100 can include autonomous vehicle 10, one or more networks 106, and one or more remotely located computing systems 108 …”) comprising:
a plurality of in-vehicle devices respectively mounted on a plurality of different vehicles (Ayers exemplifies a plurality of computing devices onboarding a plurality of vehicles in FIG. 1, FIG. 2 and para. [0040], para. [0041], para. [0042], para. [0051]; para. [0040] “… Autonomous vehicle 10 can include one or more sensors 124, computing system 102, and one or more vehicle controls 126 …”; para. [0041] “… Computing system 102 can include one or more computing devices 104. Computing device(s) 104 can include circuitry configured to perform one or more operations, functions, and/or the like described herein …”; para. [0042] “… Computing system 102 can be physically located onboard autonomous vehicle 10, and computing system(s) 108 can be distinct and/or remotely located from autonomous vehicle 10. Network(s) 106 (e.g., wired networks, wireless networks, and/or the like) can interface autonomous vehicle 10 (e.g., computing system 102, computing device (s) 104, and/or the like) with computing system(s) 108 …”; para. [0051] “… Referring to FIG. 2, as previously indicated, environment 100 can include autonomous vehicle 10, network(s) 106, and computing system(s) 108. Environment 100 can also include autonomous vehicle(s) 20 and/or 30, and/or computing device(s) 40, 50, and/or 60 …”); and
a management server (Ayers exemplifies a remote computing system in FIG. 1),
wherein each of the plurality of in-vehicle devices includes at least one of (i) a first circuit and (ii) a first processor with a first memory storing first computer program code executable by the first processor, the at least one of the first circuit and the first processor configured to cause each of the plurality of in-vehicle devices (Ayers, FIG. 2; para. [0053] “… Computing device 40 can include circuitry configured to perform one or more operations, functions, and/or the like described herein. For example, computing device 40 can include one or more processor(s) 202, one or more communication interfaces 204, and memory 206 (e.g., one or more hardware components for storing executable instructions, data, and/or the like) …”) to:
wirelessly communicate with the management server (Ayers exemplifies the remote computing system communicating with a plurality of computing devices onboarding a plurality of vehicles in FIG. 1, FIG. 2 and para. [0040], para. [0041], para. [0042], para. [0051]; also para. [0053] “… computing device 40 can include one or more processor(s) 202, one or more communication interfaces 204, and memory 206 (e.g., one or more hardware components for storing executable instructions, data, and/or the like). Communication interface (s) 204 can enable computing device 40 to communicate with autonomous vehicle 10 (e.g., computing system 102, computing device(s) 104, and/or the like), autonomous vehicle(s) 20 and/or 30, computing device(s) 50, and/or 60, computing system(s) 108 …”);
install and execute a plurality of application programs …, wherein each of the plurality of application programs has application identification data identifying each of the plurality of application programs (Ayers, para. [0019] “… For each application of the applications, the onboard computing device(s) can determine, from amongst multiple different and distinct interface identifiers (e.g., addresses, ports, links, and/or the like), an identifier associated with the application and can communicate, based at least in part on such identifier, data associated with the application and destined for a remotely located computing system (e.g., a server, vehicle-management platform, and/or the like) towards the remotely located computing system …”; para. [0053] “… Memory 206 can include (e.g., store, and/or the like) instructions 208, which, when executed by processor(s) 202, can cause computing device 40 to perform one or more operations, functions, and/or the like described herein …”); … and
the management server includes at least one of (i) a second circuit and (ii) a second processor with a second memory storing second computer program code executable by the second processor, the at least one of the second circuit and the second processor configured to cause the management server (Ayers, FIG. 2; para. [0056] “… computing system 70 can include one or more processor(s) 210, one or more communication interfaces 212, and memory 214 (e.g., one or more hardware components for storing executable instructions, data, and/or the like) …”) to:
wirelessly communicate with the plurality of in-vehicle devices (Ayers exemplifies communication interface(s) 212 in the remote computing system in FIG. 2; para. [0056] “… computing system 70 can include one or more processor(s) 210, one or more communication interfaces 212, and memory 214 (e.g., one or more hardware components for storing executable instructions, data, and/or the like). Communication interface(s) 212 can enable computing system 70 to communicate with autonomous vehicle 10 (e.g., computing system 102, computing device(s) 104, and/or the like), autonomous vehicle(s) 20 and/or 30, computing device(s) 40, 50, and/or 60, computing system(s) 80 and/or 90, and/or the like …”); …
Ayers does not explicitly teach, but Sharma teaches execute a plurality of application programs as containers (Sharm teaches executing application programs as containers and also teaches each application metadata may include an application ID and an content ID; para. [0015] “… A network system (e.g., a cloud based system) may include one or more pods within a network orchestration system. The one or more pods may include one or more containers, and one or more applications may run within these one or more containers …”; para. [0038] “… the application metadata may include application IDs, process IDs, host IDs, container IDs, service IDs, users, etc. …”); and
measure a communication traffic according to execution of each of the plurality of application programs by the application execution unit for each container identification which is a … identification attached to each of the plurality of … devices (Sharma teaches application traffic amount associated with a container ID, and a container associated with a host/device; FIG. 1, FIG. 5; para. [0035] “… A traffic analyzer ( e.g., 105) may inspect application data and network data to correlate application data with network data. In some cases, application data may be captured at a host and may be associated with corresponding applications ( e.g., users, services, processes, etc.). In some cases, network data may be captured at a virtual or physical device (e.g., a terminal access point (TAP)) …”; para. [0052] “… At 535, the traffic analyzer 505 may receive application traffic. In some cases, the application traffic may be originating from or ending at a container. The traffic analyzer 505 may receive application traffic and/or application metadata from a kernel library or module (e.g., libeBPFflow). In some cases, a kernel library or module may transmit the application traffic and/or application metadata to traffic analyzer 505. In some cases, the application traffic may contain source IP addresses, destination IP addresses, time stamp information, network protocol information, an amount of data, or any combination thereof. In some cases, the application traffic may contain application metadata (e.g., host ID, container ID, process ID, user, binary name, etc.) …”);
before generation of communication information, associate the communication traffic with the application identification data and manage the communication traffic (Sharma teaches capturing the communication traffic associated with the application ID in the host/device before supplying the communication information to the traffic analyzer; FIG. 1; para. [0035] “… A traffic analyzer ( e.g., 105) may inspect application data and network data to correlate application data with network data. In some cases, application data may be captured at a host and may be associated with corresponding applications ( e.g., users, services, processes, etc.). In some cases, network data may be captured at a virtual or physical device (e.g., a terminal access point (TAP)) …”; para. [0038] “… a library or module may collect network traffic and extract application metadata while running in Linux Kernel mode. In some examples, the application metadata may include application IDs, process IDs, host IDs, container IDs, service IDs, users, etc. In some cases, the library or module may capture a limited amount of network bytes (e.g., flows) transferred between a source IP and destination IP at a given time … one or more Linux processes may be local processes …”); and
transmit, to the management server, the communication information in which each measured communication traffic is associated with the application identification data, after the generation of the communication information (Sharma teaches generating application traffic data on a host/device and transmitting the application traffic data to the traffic analyzer on a server; FIG. 1, FIG. 2, FIG. 5; para. [0035] “… A traffic analyzer ( e.g., 105) may inspect application data and network data to correlate application data with network data. In some cases, application data may be captured at a host and may be associated with corresponding applications ( e.g., users, services, processes, etc.). In some cases, network data may be captured at a virtual or physical device (e.g., a terminal access point (TAP)) …”; para. [0040] “… The traffic analyzer 205 may represent aspects of an application server, communication server, data processing server, database server, cloud-based server, server cluster, virtual machine, container, pod, host, or some similar data processing device or system …”; para. [0052] “… At 535, the traffic analyzer 505 may receive application traffic. In some cases, the application traffic may be originating from or ending at a container. The traffic analyzer 505 may receive application traffic and/or application metadata from a kernel library or module (e.g., libeBPFflow). In some cases, a kernel library or module may transmit the application traffic and/or application metadata to traffic analyzer 505 …”), …, …,
wherein the communication information includes the communication traffic measured for each container identification which is a … identification attached to each of the plurality of … devices (Sharma teaches application traffic amount associated with a container ID, and a container associated with a host/device; FIG. 1, FIG. 5; para. [0035] “… A traffic analyzer ( e.g., 105) may inspect application data and network data to correlate application data with network data. In some cases, application data may be captured at a host and may be associated with corresponding applications ( e.g., users, services, processes, etc.). In some cases, network data may be captured at a virtual or physical device (e.g., a terminal access point (TAP)) …”; para. [0052] “… At 535, the traffic analyzer 505 may receive application traffic. In some cases, the application traffic may be originating from or ending at a container. The traffic analyzer 505 may receive application traffic and/or application metadata from a kernel library or module (e.g., libeBPFflow). In some cases, a kernel library or module may transmit the application traffic and/or application metadata to traffic analyzer 505. In some cases, the application traffic may contain source IP addresses, destination IP addresses, time stamp information, network protocol information, an amount of data, or any combination thereof. In some cases, the application traffic may contain application metadata (e.g., host ID, container ID, process ID, user, binary name, etc.) …”), and …
Sharma and Ayers are analogous art because they are both related to managing applications running on network devices.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use analyzing containerized application communication traffic techniques of Sharma with the system of Ayers to identify the originating application or container from the captured network traffic (Sharma, para.[0005]).
Ayers-Sharma does not explicitly teach, but McDowall teaches each container identification which is a temporary local identification (McDowall teaches the data plane (DP) container being able to be created and registered with a container ID to a management entity (e.g. management plane (MP) container), the DP container also being able to be destroyed, so that the container ID acting as a temporary local identification through the lifecycle of the container; FIG. 3A, FIG. 6; col. 12, l. 50 – col. 13, l. 11 “… FIG. 3A is a sequence diagram for creating a Data Plane (DP) container in an application pod in accordance … At stage 5, the DP Daemonset connects to its MP Container 310 and registers with the MP Container ( e.g., passes, cores allocated, containerID, pod name, and possibly other labels/ metadata to the MP Container) …”; col. 16, ll. 30-35 “… At 610, the security entity sends traffic log data from the security entity to a security management entity. For example, the security entity can periodically send the traffic log data to a security management entity or send such traffic log data to the security management entity prior to the application container/pod being destroyed …”), and
transmitting traffic log information to the management server/entity before at least one of the plurality of … devices stops, in response to a determination that the at least one of the plurality of … devices is about to stop (McDowall teaches transmitting the traffic log data to the management entity before the application container is destroyed; Applying McDowall’s pre-destruction reporting technique to the vehicle device/container environment as taught by Ayers-Sharma produces a predictable timing adaptation – transmitting the generated traffic information while communication remains available to preserve data for server side processing; FIG. 6; col. 16, ll. 4-35 “… the security entity can be transparently deployed in the application container to seamlessly inspect all traffic including L7 application traffic for the application container (e.g., application pod) … At 610, the security entity sends traffic log data from the security entity to a security management entity. For example, the security entity can periodically send the traffic log data to a security management entity or send such traffic log data to the security management entity prior to the application container/pod being destroyed …”).
McDowall and Ayers-Sharma are analogous art because they are both related to managing applications running on network devices.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use reporting the monitored traffic before container destruction techniques of McDowall with the system of Ayers-Sharma to preserve the application communication data for server side data processing.
Ayers-Sharma-McDowall does not explicitly teach, but Heilpern teaches the management server to acquire the communication information from the plurality of in-vehicle devices (Heilpern, Heilpern, FIGS 1-4; para. [0023] “… The application detector 124 receives network consumption data for processes executing on the mobile device 104, and identifies applications for the processes by analyzing the network consumption data … the application detector 124 provides reports, usage data, or aggregated network consumption data to the AM server 120 which provides this information to a mobile device 104. The data repository 122 stores data associated with application monitoring including network consumption data received from the mobile device 104, and usage data generated from aggregating the network consumption data for applications over time. In some embodiments, the application detector 124 is integrated with the AM server 120 …”; para. [0043] “… The application detector 124 determines 410 application strings associated with the applications. The application may be associated with application strings that can be used to identify particular applications. The application strings may include an application name string for each application, a package name string for the packages of each application, and a category string for each application. In some embodiments, the application strings may further include key word strings that application providers associate with the application, such as in the application's description in an application store …”);
total the communication traffic associated with the application identification data for each application identification data (Heilpern teaches identifying network consumption records by application and totaling their received/transmitted byte traffic; FIG. 1, FIG. 2, FIG. 3, FIG. 6A; para. [0023] “… The application detector 124 generates usage data for applications executing on the mobile device 104 by aggregating network consumption data associated with applications over time …”; para. [0038] “… The application detector 124 associates 310 an application with a process by analyzing the network consumption data. For example, the AM application detector 124 associates an application from an application list of applications executing on the mobile device 104 with the process ID of the network consumption data. The application detector 124 determines 315 usage data for the application based on aggregating the network consumption data associated with the application over time …”; para. [0050] “… Meta_data is a group of such network pulses grouped by host-post-user agent combination and aggregating in/out bytes, duration, activity, timestamp during a period of 1 to n seconds …”); and
calculate an application communication (Heilpern teaches calculating an aggregate quantity from communication consumption attributed to a particular application; FIG. 1, FIG. 4, FIG. 6A; para. [0050] “… Meta_data is a group of such network pulses grouped by host-post-user agent combination and aggregating in/out bytes, duration, activity, timestamp during a period of 1 to n seconds …”; para. [0085] “… The application detector 124 generates 430 usage data for the application by aggregating network consumption data associated with the application …”).
Heilpern and Ayers-Sharma-McDowall are analogous art because they are both related to managing applications running on network devices.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use calculating the application usage from the network traffic techniques of Heilpern with the system of Ayers-Sharma-McDowall to determine the amount of data being generated by various application and system activities on network devices (Heilpern para. [0019]).
For Claim 11, Ayers- Sharma-McDowall-Heilpern teaches the vehicle network system according to claim 5, wherein the at least one of the first circuit and the first processor is configured to measure the communication traffic (Heilpern, FIGS 1-4; para. [0024] “… the mobile device 104 executes applications that communicate with application systems 108 via the network 106, and communicates with the AM system 102 to report network consumption data via the network 106 …”; para. [0025] “… Although a single mobile device 104 is shown in FIG. 1, the environment may include any number of mobile devices 104a-n (n being nth device), i.e., one or more mobile devices (generally 104) …”; para. [0028] “… The mobile operating system 202 may provide a Virtual Private Network (vpn) layer that allows network traffic of the device 104 to be monitored by the traffic monitor 206. The traffic monitor 206 generates network consumption data for processes, which may be associated with Process IDs. For each instance of network consumption data, the operating system may provide the Process ID, or the traffic monitor 206 may generate a Process ID …”),
acquire a communication transmission destination, a communication type, and a vehicle state, and add the communication transmission destination, the communication type, and the vehicle state to the communication information (Heilpern exemplifies in FIG. 6 that the network consumption data comprises a communication transmission destination such as a “host” string and a communication type such as “HTTP”; FIGS 1-4, FIG. 6; para. [0028] “… The traffic monitor 206 provides the network consumption data to the AM application 208, or to the application detector 124 …”; para. [0050] “… The metadata includes detailed information of multiple network/socket connections made by a particular process or application. At any point, there can be multiple such network requests coming from the same process to the same or different hosts. Meta_data is a group of such network pulses grouped by host-post-user agent combination and aggregating in/out bytes, duration, activity, timestamp during a period of 1 to n seconds. …”; para. [0051] “… The ua parameter defines the user-agent string and the host parameter defines the host string, which may be used as the consumption data strings determined from the network consumption data 600. The host string may be a domain name service (DNS) or an Internet protocol (IP) address …”; Ayers teaches determining a vehicle state, and the vehicle state could supplement the network consumption data; FIGS 1-3; para. [0074] “… At (312), computing system 102 can determine, detect, identify, and/or the like one or more changes in a mode, state, context, and/or the like of autonomous vehicle 10. For example, over time the mode, state, context, and/or the like of autonomous vehicle 10 can change (e.g., specified travel can be completed, new travel can commence, one or more diagnostic routines can be initiated, and/or the like) …”).
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use calculating the application usage from the network traffic techniques of Heilpern with the system of Ayers-Sharma-McDowall to determine the amount of data being generated by various application and system activities on network devices (Heilpern para. [0019]).
For Claim 12, the claim is substantially similar to claim 1 and therefore is rejected for the same reasoning set forth above.
Claim Rejections - 35 USC § 103
Claims 3-4 and 7-9 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20200329460 A1 (hereinafter Ayers), in view of US 20210099394 A1 (hereinafter Sharma), in view of US 11477165 B1 (hereinafter McDowall), in view of US 20180054493 A1 (hereinafter Heilpern), in further view of US 20220295136 A1 (hereinafter Oishi), in further view of US 20220360461 A1 (hereinafter Raleigh), and in further view of US 20230052248 A 1 (hereinafter Mizuno).
For Claim 3, Ayers-Sharma-McDowall-Heilpern teaches the management server according to claim 1. Ayers-Sharma-McDowall-Heilpern does not explicitly teach, but Oishi teaches wherein the at least one of the circuit and the processor (Oishi exemplifies a management server 3 and a carrier system 6 communicating with service providers 8 in FIG. 1) is configured to
wirelessly communicate with a service server related to each of a plurality of service providers (Oishi, FIG. 1, FIG. 2; para. [0035] “… As shown in FIG. 1, a communication management system 1 includes: on-vehicle communication devices 2 mounted on respective vehicles 5; and a management server 3 away from the vehicles 5 and configured to manage the on-vehicle communication devices 2. The communication management system 1 provides various services with different contents from different providers via the on-vehicle communication devices 2 to the vehicles 5, and manages the communications between the vehicles 5 and service providers 8 that provide occupant services …”),
the plurality of application programs are divided into a plurality of groups, each of the plurality of groups is provided by a … service provider among the plurality of service providers (Oishi teaches that the management server manages various services/applications provided by different service providers and each service application provided by a service provider is assigned a dedicated port for data communications; FIGS. 1-4; para. [0072] “… FIG. 3A shows the operation of port registration in which the management server 3 receives requests for port registration from the service providers 8. Here, the following will be described as an example of port registration by the service providers 8. A service provider 8A registers a dedicated port Ps1 for a voice search service, and a dedicated port Ps2 for a streaming service. A service provider 8B registers a dedicated port Ps3 for an Internet radio, and a dedicated port Ps4 for providing surrounding information …”; para. [0078] “… The identification flag information 361 is associated with service identification information and assignment information. For example, the service identification information includes: a company name and/or a brand name identifying one of the service providers 8, and/or a service name identifying the service itself provided by the service provider 8. The assignment information indicates a transmission source port (i.e., a dedicated port Ps) assigned for each of the service identification information …”; para. [0079] “… Referring back to FIG. 3A, in the next step S33, the management server 3 notifies the carrier system 6 of the fact that the data communications for the voice search service by the service provider 8A are made via the dedicated port Ps1 and the data communications for the streaming service are made via the dedicated port Ps2 …”), and
the at least one of the circuit and the processor is configured to total a corresponding application communication traffic for each of the plurality of groups to calculate a total communication traffic for each of the plurality of groups (Oishi teaches accumulating the data traffic incurred for a service application provided by each service provider, FIGS 1-4; para. [0098] “… A computing unit 63 of the carrier system 6 accumulates the data traffic for the request from the on-vehicle communication device 2 to the service provider 8A and the data traffic for the response from the service provider 8A to the on-vehicle communication device 2. The storage unit 68 stores the accumulated data as the traffic used by the dedicated port Ps1, that is, data traffic B1 used for the voice search service (step S25) …”), …
Oishi and Ayers-Sharma-McDowall-Heilpern are analogous art because they are both related to managing applications running on network devices.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the accumulating the data traffic between a network device and a service provider techniques of Oishi with the system of Ayers-Sharma-McDowall-Heilpern to divide the data traffic based on the respective services/applications provided by different service providers (Oishi para. [0008).
Ayers-Sharma-McDowall-Heilpern-Oishi teaches the situation when each service application is provided by a different service provider, but does not explicitly teach the situation when more than one service applications are provided by a service provider and are divided into the same group, i.e. each of the plurality of groups which may comprise more than one application programs is provided by a different service provider.
However, Raleigh teaches calculating total amount of communications data for a given destination (e.g. a service provider), therefore Raleigh teaches calculating a total communication traffic for each of the plurality of groups which may comprise more than one application programs is provided by a different service provider (Raleigh, para. [0241] “… correlation techniques are applied by the service controller to compare two different service usage measures as described above based on one or more of the following: total amount of data (e.g., bytes for file transfers, sessions, and/or other measures), amount of data per unit time, total number of accesses, number of accesses per unit time or frequency of accesses, accesses during a time interval (e.g., peak time), accesses during a network busy state, access requests, and individual versus group transmissions at a point in time ( e.g., each for a given set of destinations or destinations and traffic types) …”).
Raleigh and Ayers-Sharma-McDowall-Heilpern-Oishi are analogous art because they are both related to computing network communications.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the computing service usage measures techniques of Raleigh with the system of Ayers-Sharma-McDowall-Heilpern-Oishi to monitor the bandwidth and network capacity usage of the consumers (Raleigh para. [0002]).
Ayers-Sharma-McDowall-Heilpern-Oishi-Raleigh does not explicitly teach, but Mizuno teaches determine whether the calculated total communication traffic exceeds a set upper limit value for each of the plurality of groups, and notify a service server related to a corresponding service provider among the plurality of service providers that the total communication traffic exceeds the set upper limit value when determining that the total communication traffic of any of the plurality of groups exceeds the set upper limit value (Mizuno teaches calculating the accumulated communication traffic between communication terminal apparatuses and a center apparatus, and saving related calculation information into a database in the center apparatus; FIG. 1, FIG. 3; para. [0036] “… The first communication traffic threshold is a threshold for communication traffic between each of the plurality of communication terminal apparatuses 2 and the center apparatus 10. For example, the first communication traffic threshold is an upper limit value of total communication traffic for one month for communication between each of the plurality of communication terminal apparatuses 2 and the center apparatus 10 …”; para. [0071] “… At step S003, the remaining communication capacity calculation unit 15 sets a value equal to a first communication traffic threshold as a second communication traffic threshold. The remaining communication capacity calculation unit 15 sets a difference between the second communication traffic threshold and the value of past communication traffic as a remaining communication capacity. The remaining communication capacity calculation unit 15 causes the remaining communication capacity to be stored into the database 11 …”; para. [0084] “… The center apparatus 10 is provided with the past communication traffic calculation unit 13, the remaining communication capacity calculation unit 15 and the communication traffic monitoring unit 16. The past communication traffic calculation unit 13 calculates past communication traffic which is an accumulative value of traffic of communication received from a communication terminal apparatus 2. The past communication traffic calculation unit 13 calculates a remaining communication capacity by using information about a first communication traffic threshold set by an operator and information about the past communication traffic. If communication traffic required for transmission of first transmitted information is larger than the remaining communication capacity, the communication traffic monitoring unit 16 creates second transmitted information by dividing the first transmitted information. Communication traffic to transmit the second transmitted information does not exceed the remaining communication capacity. After that, the communication traffic monitoring unit 16 transmits the second transmitted information to the corresponding communication terminal apparatus 2 …”).
Mizuno and Ayers-Sharma-McDowall-Heilpern-Oishi-Raleigh are analogous art because they are both related to managing network communication traffic.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the adjusting communication traffic techniques of Mizuno with the system of Ayers-Sharma-McDowall-Heilpern-Oishi-Raleigh to “prevent total communication traffic between a center apparatus and the communication terminal apparatus from exceeding a set threshold” (Mizuno para. [0007]).
For Claim 4, Ayers-Sharma-McDowall-Heilpern-Oishi-Raleigh-Mizuno teaches the management server according to claim 3, wherein the at least one of the circuit and the processor is configured to request a selected in-vehicle device among the plurality of in-vehicle devices to restrict communication via the server communication unit, and the selected in-vehicle device has installed a group determined to have the total communication traffic exceeding the set upper limit value among the plurality of groups (Mizuno teaches calculating the accumulated communication traffic between communication terminal apparatuses and a center apparatus, and adjusting the amount of communicating information based on the calculation; FIG. 1; para. [0036] “… The first communication traffic threshold is a threshold for communication traffic between each of the plurality of communication terminal apparatuses 2 and the center apparatus 10. For example, the first communication traffic threshold is an upper limit value of total communication traffic for one month for communication between each of the plurality of communication terminal apparatuses 2 and the center apparatus 10 …”; para. [0084] “… The center apparatus 10 is provided with the past communication traffic calculation unit 13, the remaining communication capacity calculation unit 15 and the communication traffic monitoring unit 16. The past communication traffic calculation unit 13 calculates past communication traffic which is an accumulative value of traffic of communication received from a communication terminal apparatus 2. The past communication traffic calculation unit 13 calculates a remaining communication capacity by using information about a first communication traffic threshold set by an operator and information about the past communication traffic. If communication traffic required for transmission of first transmitted information is larger than the remaining communication capacity, the communication traffic monitoring unit 16 creates second transmitted information by dividing the first transmitted information. Communication traffic to transmit the second transmitted information does not exceed the remaining communication capacity. After that, the communication traffic monitoring unit 16 transmits the second transmitted information to the corresponding communication terminal apparatus 2 …”).
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the adjusting communication traffic techniques of Mizuno with the system of Ayers-Sharma-McDowall-Heilpern-Oishi-Raleigh to “prevent total communication traffic between a center apparatus and the communication terminal apparatus from exceeding a set threshold” (Mizuno para. [0007).
For Claim 7, the claim is substantially similar to claim 3 and therefore is rejected for the same reasoning set forth above.
For Claim 8, the claim is substantially similar to claim 4 and therefore is rejected for the same reasoning set forth above.
For Claim 9, Ayers-Sharma-McDowall-Heilpern-Oishi-Raleigh-Mizuno teaches the vehicle network system according to claim 8, wherein the at least one of the first circuit and the first processor is configured to provide notification upon receiving a communication restriction request (Ayers teaches that the communication interfaces enables communicating data/request and the processors enable performing the operations; FIGS 1-4; para. [0053] “… Computing device 40 can include circuitry configured to perform one or more operations, functions, and/or the like described herein. For example, computing device 40 can include one or more processor(s) 202, one or more communication interfaces 204, and memory 206 (e.g., one or more hardware components for storing executable instructions, data, and/or the like). Communication interface(s) 204 can enable computing device 40 to communicate with autonomous vehicle 10 (e.g., computing system 102, computing device(s) 104, and/or the like), autonomous vehicle(s) 20 and/or 30, computing device(s) 50, and/or 60, computing system(s) 108, and/or the like. Memory 206 can include (e.g., store, and/or the like) instructions 208, which, when executed by processor(s) 202, can cause computing device 40 to perform one or more operations, functions, and/or the like described herein …”; Mizuno teaches saving the calculated communication information into a database in the center apparatus therefore notifying the center apparatus about the communication information update).
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the adjusting communication traffic techniques of Mizuno with the system of Ayers-Sharma-McDowall-Heilpern-Oishi-Raleigh to “prevent total communication traffic between a center apparatus and the communication terminal apparatus from exceeding a set threshold” (Mizuno para. [0007]).
Claim Rejections - 35 USC § 103
Claims 10 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20200329460 A1 (hereinafter Ayers), in view of US 20210099394 A1 (hereinafter Sharma), in view of US 11477165 B1 (hereinafter McDowall), in view of US 20180054493 A1 (hereinafter Heilpern), in view of US 20220295136 A1 (hereinafter Oishi), in view of US 20220360461 A1 (hereinafter Raleigh), in view of US 20230052248 A 1 (hereinafter Mizuno), and in further view of US 20130167219 A1 (hereinafter Jung).
For Claim 10, Ayers-Sharma-McDowall-Heilpern-Oishi-Raleigh-Mizuno teaches the vehicle network system according to claim 8. Ayers-Sharma-McDowall-Heilpern-Oishi-Raleigh-Mizuno does not explicitly teach, but Jung teaches wherein upon receiving a communication restriction request, the at least one of the first circuit and the first processor is configured to restrict communication even when receiving a communication request (Jung teaches preventing excessive traffic from a terminal apparatus to enter the network and exemplifies various function units to perform the preventing operations; FIG. 1, FIG. 5; para. [0085] “… If the anomalous traffic detection signal is generated, the terminal apparatus 100 generates a traffic block request signal for requesting blockage of the transmission packet (540). According to the traffic block request signal, the terminal apparatus 100 may prevent the transmission packet that generated the excessive traffic from being output from the terminal apparatus 100 to a network (550) …”).
Jung and Ayers-Sharma-McDowall-Heilpern-Oishi-Raleigh-Mizuno are analogous art because they are both related to managing network communication traffic.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the excessive traffic prevention techniques of Jung with the system of Ayers-Sharma-McDowall-Heilpern-Oishi-Raleigh-Mizuno to prevent excessive traffic from entering a network (Jung para. [0007]).
For Claim 15, Ayers-Sharma-McDowall-Heilpern-Oishi-Raleigh-Mizuno teaches the management server according to claim 4, wherein the request to restrict the communication includes limiting the communication traffic to a predetermined value or less (Mizuno teaches calculating the accumulated communication traffic between communication terminal apparatuses and a center apparatus, and adjusting the amount of communication information based on the calculation; FIG. 1; para. [0036] “… The first communication traffic threshold is a threshold for communication traffic between each of the plurality of communication terminal apparatuses 2 and the center apparatus 10. For example, the first communication traffic threshold is an upper limit value of total communication traffic for one month for communication between each of the plurality of communication terminal apparatuses 2 and the center apparatus 10 …”; para. [0084] “… The center apparatus 10 is provided with the past communication traffic calculation unit 13, the remaining communication capacity calculation unit 15 and the communication traffic monitoring unit 16. The past communication traffic calculation unit 13 calculates past communication traffic which is an accumulative value of traffic of communication received from a communication terminal apparatus 2. The past communication traffic calculation unit 13 calculates a remaining communication capacity by using information about a first communication traffic threshold set by an operator and information about the past communication traffic. If communication traffic required for transmission of first transmitted information is larger than the remaining communication capacity, the communication traffic monitoring unit 16 creates second transmitted information by dividing the first transmitted information. Communication traffic to transmit the second transmitted information does not exceed the remaining communication capacity. After that, the communication traffic monitoring unit 16 transmits the second transmitted information to the corresponding communication terminal apparatus 2 …”) and …
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the adjusting communication traffic techniques of Mizuno with the system of Ayers-Sharma-McDowall-Heilpern-Oishi-Raleigh to “prevent total communication traffic between a center apparatus and the communication terminal apparatus from exceeding a set threshold” (Mizuno para. [0007]).
Ayers-Sharma-McDowall-Heilpern-Oishi-Raleigh-Mizuno does not explicitly teach, but Jung teaches stopping the communication of a corresponding application program among the plurality of application programs (Jung teaches preventing excessive traffic from a terminal apparatus to enter the network and exemplifies various function units to perform the preventing operations; FIG. 1, FIG. 5; para. [0085] “… If the anomalous traffic detection signal is generated, the terminal apparatus 100 generates a traffic block request signal for requesting blockage of the transmission packet (540). According to the traffic block request signal, the terminal apparatus 100 may prevent the transmission packet that generated the excessive traffic from being output from the terminal apparatus 100 to a network (550) …”).
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the excessive traffic prevention techniques of Jung with the system of Ayers-Sharma-McDowall-Heilpern-Oishi-Raleigh-Mizuno to prevent excessive traffic from entering a network (Jung para. [0007]).
Claim Rejections - 35 USC § 103
Claim 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20200329460 A1 (hereinafter Ayers), in view of US 20210099394 A1 (hereinafter Sharma), in view of US 11477165 B1 (hereinafter McDowall), in view of US 20180054493 A1 (hereinafter Heilpern), and in further view of US 20170164184 A1 (hereinafter Borse).
For Claim 16, Ayers-Sharma-McDowall-Heilpern teaches the management server according to claim 1, and the vehicle network system including the management server and the plurality of in-vehicle devices (Ayers exemplifies the remote computing system communicating with a plurality of computing devices onboarding a plurality of vehicles in FIG. 1, FIG. 2 and para. [0040], para. [0041], para. [0042], para. [0051]).
Ayers-Sharma-McDowall-Heilpern does not explicitly teach, but Borse teaches wherein the application identification data is a common identification in the … network system …, and the container identification is not the common identification in the … network system (Borse teaches the application instances for the same application having the same application identifier, and the container instances not having the same container identification; FIG. 1; para. [0025] “… Each profile container 12a-c contains a file system with a toolkit for issuing and processing commands and memory for executing applications. Each application has an identifier that is used when communicating between the application and one or more of the device or the carrier network. However, when two active profiles execute the same application, the application identifiers for the two applications will be the same …”; para. [0026] – [0029] “… Application manager 30 manages the same or similar applications executing in the respective memory spaces of the different active profiles and prevents ‘collisions’ as described above when calling processes attempt to issue commands to or otherwise communicate with these applications. Application manager 30, or some other profile management process or scheme, assigns each profile container a unique identifier. For example, a first profile container has the following unique identifier: … AO 00 00 05 59 10 10 FF FF FF FF 89 00 00 01 00 … A second profile container has, for example, the following unique identifier … AO 00 00 05 59 10 10 FF FF FF FF 89 00 00 11 00 …”).
Borse and Ayers-Sharma-McDowall-Heilpern are analogous art because they are both related to computing network systems.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the separating application identity from execution-container identity techniques of Borse with the system of Ayers-Sharma-McDowall-Heilpern to identify the appropriate processes running the same application (Sharma, para.[0026]).
Citation of Pertinent Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is listed below, thank you:
i. US 20180131768 A1 (hereinafter Moon) teaches that a vehicle may include a telematics terminal configured to be turned off when a power level of a battery reaches a predetermined reference value; and a low-power communication module configuring a node of an Ad-hoc network, and configured to receive a remote control signal for the vehicle through the Ad-hoc network, wherein when the low-power communication module receives the remote control single for the vehicle through the Ad-hoc network in the state in which the telematics terminal is turned off, the telematics terminal is turned on (Abstract).
ii. US 20100313196 A1 (hereinafter Atley) teaches managing securely installed applications. After installation, an installation framework performs a bind process to correlate the randomly assigned identifier with the unique identifier of the application. The installation framework also manages the execution of the application. When an application is launched, the application framework performs a search for that application's randomly assigned identifier and locates the application's container. The application is then allowed to execute within its container. During execution, the software application may also be restricted in various ways by the installation framework to its dynamic containers. The installer may also work with a trusted operating system component, such as the kernel, to help enforce the container restrictions. In addition, if desired, the use of random identifiers for containers may be used in conjunction with other security mechanisms, such as the use of code signing (Abstract).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZONGHUA DU whose telephone number is (408)918-7596. The examiner can normally be reached Monday - Friday 8 AM - 5 PM PST.
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, John Follansbee can be reached on (571) 272-3964. 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.
/Z.D./Examiner, Art Unit 2444
/SCOTT B CHRISTENSEN/Primary Examiner, Art Unit 2444
Prosecution Insights