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 Office Action is in response to claims filed 07/31/2023.
Claims 1-20 are pending.
Claim Objections
Claims 1-10 are objected to because of the following informalities: Claim 1 recites preferred verbiage “wherein the selected IoT devices are selected based on being capable of performing a task including at least one of compute and[[/or]] storage for a vehicle system”. Appropriate correction is required.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, is directed to that judicial exception, an abstract idea, as it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below.
Step 1:
Claims 1-10 are directed to a system and falls within the statutory category of machines; Claims 11-20 are directed to methods and fall within the statutory category of processes. Therefore, “Are the claims to a process, machine, manufacture or composition of matter?” Yes.
In order to evaluate the Step 2A inquiry “Is the claim directed to a law of nature, a natural phenomenon or an abstract idea?” we must determine, at Step 2A Prong 1, whether the claim recites a law of nature, a natural phenomenon or an abstract idea and further whether the claim recites additional elements that integrate the judicial exception into a practical application.
Step 2A Prong 1:
Claims 1 and 11: The limitations of “determine/determining selected Internet of Things (IoT) devices from a plurality of IoT devices separate from the vehicle, wherein the selected IoT devices are selected based on being capable of performing a task including compute and/or storage for a vehicle subsystem”, “decompose/decomposing the task into a plurality of workloads to offboard for processing on respective selected IoT devices”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can mentally select a device among a plurality of devices based on qualities of the devices and their ability to complete a certain task. Further, a person decompose a task mentally into a plurality of subtasks and plan which devices should process them.
Therefore, yes, Claims 1 and 11 recite judicial exceptions.
The claims have been identified to recite judicial exceptions, Step 2A Prong 2 will evaluate whether the claims are directed to the judicial exception.
Step 2A Prong 2:
Claims 1 and 11: The judicial exceptions are not integrated into practical applications. In particular, the claims recite the following additional elements – “send/sending the workloads to the respective selected IoT devices” merely recite insignificant extra-solution data gathering and data storage which do not integrate the judicial exception into a practical application. See MPEP § 2106.05(g). Further, “the memory storing instructions executable by the processor such that the computer is programmed to” is a recitation of generic computing components and functions merely being used as a tool to apply the abstract idea (see MPEP § 2106.05(f)). Lastly, “A system comprising a vehicle computer of a vehicle including a processor and a memory” recites a field of use which generally links the use of a judicial exception to a particular technological environment (MPEP § 2106.05(h)).
Therefore, “Do the claims recite additional elements that integrate the judicial exception into a practical application? No, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
After having evaluating the inquires set forth in Steps 2A Prong 1 and 2, it has been concluded that the Claims 1 and 11 not only recite a judicial exception but that the claims are directed to a judicial exception as a judicial exception has not been integrated into a practical application.
Step 2B:
Claims 1 and 11: The claims do not include additional elements, alone or in combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to no more than generic computing components, field of use/technological environment, and insignificant extra-solution activity which do not amount to significantly more than the abstract idea. Further, the insignificant extra-solution activity is Well-Understood, Routine, and Conventional. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network”. See MPEP § 2106.05(d)(II).
Therefore, “Do the claims recite additional elements that amount to significantly more than the judicial exception? No, these additional elements, alone or in combination, do not amount to significantly more than the judicial exception.
Having concluded analysis within the provided framework, Claims 1 and 11 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Regarding Claim 2 and 12, they recite “determine/determining that the task is offboardable based on the task being permitted to use asynchronous processing”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can think about whether or not a task could be done at a different time than another. With regard to integration into practical application and whether additional elements amount to significantly more, Claims 2 and 12 fail both prongs of Step 2A, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claims 2 and 12 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Regarding Claims 3 and 13, they recite “determine/determining the selected IoT devices include instructions to/for evaluate/evaluating available shared resources of IoT devices within a threshold distance relative to the vehicle”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can think about the capabilities of a device around them. With regard to integration into practical application and whether additional elements amount to significantly more, Claims 3 and 13 fail both prongs of Step 2A, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claims 3 and 13 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Regarding Claims 4-7, and 14-17, they recite “determine/determining the selected IoT devices include instructions to/for evaluate/evaluating qualities of service (QoS) of the plurality of IoT devices”, “evaluate/evaluating the QoS of the plurality of IoT devices include instructions to filter/filtering the plurality of IoT devices based upon network connection parameters of the plurality of IoT devices”, “evaluate/evaluating the QoS of the plurality of IoT devices include instructions to filter the plurality of IoT devices based upon an encryption compatibility of the plurality of IoT devices”, “evaluate/evaluating the QoS of the plurality of IoT devices include instructions to order the plurality of IoT devices based upon a best fit of available shared resources for the task and select a top number of the plurality of IoT devices as the selected IoT devices for offboarding of the task”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can think about whether or not a device is capable of completing a required task to a certain standard of success. With regard to integration into practical application and whether additional elements amount to significantly more, Claims 4-7, and 14-17 fail both prongs of Step 2A, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claims 4-7, and 14-17 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Regarding Claims 8, and 18, they recite “encode/encoding the plurality of workloads into a plurality of respective containers, each container including code and dependencies for one of the workloads of the decomposed task”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can think about splitting a large task into smaller ones. With regard to integration into practical application and whether additional elements amount to significantly more, Claims 8 and 18 fail both prongs of Step 2A, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more, performing a well understood, routine, and conventional task of data gathering. Therefore, Claims 8 and 18 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Regarding Claims 9 and 19, they recite “sending the workloads to the respective selected IoT devices include instructions to transmit each of the plurality of containers to a respective one of the selected IoT devices”, reciting insignificant extra-solution data transmission activity, MPEP § 2106.05(g). With regard to integration into practical application and whether additional elements amount to significantly more, Claims 9 and 19 fail both prongs of Step 2A, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more, performing a well understood, routine, and conventional task of data gathering. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network … iv. Storing and retrieving information in memory”. See MPEP § 2106.05(d)(II). Therefore, Claims 9 and 19 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Regarding Claims 10 and 20, they recite “receive/receiving and aggregate/aggregating results data from the selected IoT devices for the workloads of the task to complete processing of the task”, reciting insignificant extra-solution data gathering activity, MPEP § 2106.05(g). With regard to integration into practical application and whether additional elements amount to significantly more, Claims 10 and 20 fail both prongs of Step 2A, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more, performing a well understood, routine, and conventional task of data gathering. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network”. See MPEP § 2106.05(d)(II). Therefore, Claims 10 and 20 do not recite patent eligible subject matter under 35 U.S.C. § 101.
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 1-20 are 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites the limitation "the computer". There is insufficient antecedent basis for this limitation in the claim. For the purposes of compact prosecution examiner will interpret “the computer” to mean “the vehicle computer”.
Claims 1, 8, 10, 11, 18-20 recite the limitation "the workloads". There is insufficient antecedent basis for this limitation in the claim. For the purposes of compact prosecution examiner will interpret “the workloads” to mean “the plurality of workloads”.
Claims 8 and 18 recite the limitation " the decomposed task". There is insufficient antecedent basis for this limitation in the claim. For the purposes of compact prosecution examiner will interpret “the decomposed task” to mean a subset of “the task” after having been decomposed in the “decompose/decomposing […]” limitation of claims 1 and 11.
Claims 2-10 and 12-20 are rejected based on their dependency to the aforementioned Claims 1 and 11 that lack antecedent basis and their failure to resolve the deficiencies thereof.
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-2, 4, 7-12, 14, 17-20 are rejected under 35 U.S.C. 103(a) as being unpatentable over Sabella et al. ( US 20180183855 A1 ) (hereinafter Sabella), in view of Smith1 et al. (US 11431561 B2) (hereinafter Smith1).
Regarding Claim 1, Sabella teaches:
A system comprising a vehicle computer of a vehicle including a processor and a memory,
““computer device” may describe any physical hardware device capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations, equipped to record/store data on a machine readable medium, and transmit and receive data from one or more other devices in a communications network”, (Sabella: ¶033), “The UE 101-1 is illustrated as a smartphone and UE 101-2 is illustrated as a table computer (e.g., handheld touchscreen mobile computing device connectable to one or more cellular networks), but may also comprise” … “vehicle-embedded system or a vehicle-to-everything (V2X) device”, (Sabella: ¶046, Fig 1 Part 101-1 and 101-2), “Examples of “computer devices”, “computer systems”, “UEs”, etc. may include”…“in-vehicle infotainment (IVI), in-car entertainment (ICE) devices, an Instrument Cluster (IC), head-up display (HUD) devices, onboard diagnostic (OBD) devices, dashtop mobile equipment (DME), mobile data terminals (MDTs), Electronic Engine Management System (EEMS), electronic/engine control units (ECUs), electronic/engine control modules (ECMs)”, (Sabella: ¶034), “a mass storage 708 may also couple to the processor 702”, (Sabella: ¶110), “a memory may be sized between 2 GB and 16 GB”, (Sabella: ¶109).
the memory storing instructions executable by the processor such that the computer is programmed to:
“A process may be implemented as program code, which may be stored by computer-readable storage media, and when the program code is executed by one or more processors of a computer device/system”, (Sabella: ¶029), “the computer platform 700 may be suitable for use as UEs 101”, (Sabella: ¶106, Fig 7), “storage 708 may be divided into one or more trusted memory regions for storing applications or software modules”, (Sabella: ¶112).
determine selected Internet of Things (IoT) devices from a plurality of IoT devices separate from the vehicle,
““An application might have a set of requirements (e.g., latency, processing resources, storage resources, network resources, location, network capability, security condition etc.) that need to be fulfilled by the MEH 200, and a MEC system may select the MEH 200 that fulfills all of the requirements”, (Sabella: ¶039), “The mass storage 708 may include a number of modules 731, 732 to implement the various MEH 200 selection functions described herein, as well as functionality of other embodiments discussed herein”, (Sabella: ¶134), “FIG. 1 illustrates an architecture of a system 100A” … “In system 100A, mobile edge hosts (MEHs) 200” … “In this way, consumers can use low complexity UEs 101 by off-loading computing capacity to the MEH 200”, (Sabella: ¶038), “The MEC hosts 200-1, 200-2, 200-3 (collectively referred to as “MEC hosts 200”, “MEC host 200”, “MEH 200”, or the like) may be virtual or physical devices”, (Sabella ¶059), “Similar to FIG. 15, in embodiments, one or more of IoT devices 1504, GW 1604, and so forth, may be incorporated with embodiments described herein”, (Sabella: ¶203), “any of the IoT groups discussed herein, may include the components, devices, systems discussed with regard to FIGS. 1-16”, (Sabella ¶211). Examiner notes: “MEH’s” are described as physical devices which are included in figure 1 where IoT groups may include devices found in figures 1-16.
wherein the selected IoT devices are selected based on being capable of performing a task including compute and/or storage for a vehicle subsystem;
“a task offloading opportunity may depend on a tradeoff between computation (e.g., time and energy, or computational resources) for task execution and energy spent to communicating data (e.g., the input/output of the offloaded task, or network resources)”, (Sabella: ¶042), “An application might have a set of requirements (e.g., latency, processing resources, storage resources, network resources, location, network capability, security condition etc.) that need to be fulfilled by the MEH 200, and a MEC system may select the MEH 200 that fulfills all of the requirements”, (Sabella: ¶039), “FIG. 1 illustrates an architecture of a system 100A” … “In system 100A, mobile edge hosts (MEHs) 200” … “In this way, consumers can use low complexity UEs 101 by off-loading computing capacity to the MEH 200”, (Sabella: ¶038), “The MEC hosts 200-1, 200-2, 200-3 (collectively referred to as “MEC hosts 200”, “MEC host 200”, “MEH 200”, or the like) may be virtual or physical devices”, (Sabella ¶059), “Similar to FIG. 15, in embodiments, one or more of IoT devices 1504, GW 1604, and so forth, may be incorporated with embodiments described herein”, (Sabella: ¶203), “any of the IoT groups discussed herein, may include the components, devices, systems discussed with regard to FIGS. 1-16”, (Sabella ¶211). Examiner notes: “MEH’s” are described as physical devices which are included in figure 1 where IoT groups may include devices found in figures 1-16.
decompose the task into a plurality of workloads to offboard for processing on respective selected IoT devices;
“The MEHs 200 may execute compute-intensive functionalities of applications (e.g., including App1, App2, and App3), namely application part(s) y (e.g., application part y1 of App1, application part y2 of App2, and application part y3 of App3) improving user experience”, (Sabella: ¶038), “By providing rich computation resources on the MEHs 200, application computation can be off-loaded to the mobile edge hosts”, (Sabella: ¶038), “In this embodiment, the S1 interface may split into two parts: an S1 user plane (S1-U) interface, which carries traffic data between the ANs 111 and 112 and the serving gateway (S-GW) 122, and an S1-mobility management entity (MME) interface”, (Sabella: ¶054). Examiner notes: Although Sabella discusses offboarding a decomposed task to a plurality of selected IoT devices, it does not discuss the act of decomposing.
send the workloads to the respective selected IoT devices.
“By providing rich computation resources on the MEHs 200, application computation can be off-loaded to the mobile edge hosts”, (Sabella: ¶038, Fig 8), “Data may be uploaded to the cloud 1702, and commands received from the cloud 1702, through GWs 1710 that are in communication with the IoT devices 1804”, (Sabella: ¶217), “consumers can use low complexity UEs 101 by off-loading computing capacity to the MEH 200 by transferring compute-intensive processes”, (Sabella: ¶038).
Further regarding Claim 1, Sabella fails to fully teach:
decompose the task into a plurality of workloads to offboard for processing on respective selected IoT devices;
However, Smith1 teaches: “This may be performed, for example, by splitting the payload into N byte sequences. Each byte sequence may be placed into a separate destination protocol frame and the packet sequences are numbered”, (Smith1: Col 61 lines 4-12), “route the egress frame towards a destination, for example, by sending the frame on to a subsequent device with an address indicating the final destination”, (Smith1: Col 62 lines 13-32), “is a networking protocol-agnostic method of splitting data into multiple independent parallel data subsets and conveying them over multiple network paths before recombination at the destination”, (Smith1: Col 63 lines 37-53), “FIG. 98 is a process flow diagram of an example method for targeting storage or sending nodes in accordance with some embodiments”, (Smith1: Col 7 lines 23-25), “This framework may use a peer-to-peer (P2P) policy storage and deployment mechanism to utilize available memory, for example, in the IoT mesh network”, (Smith1: Col 111 lines 27-34), “Examples of information that may be collected by the monitor 12208 include current device configuration, capabilities and functions supported by each node“, (Smith1: Col 112 lines 12-22), “The formats may include constraints, such as data field length, and the like, that can be used to determine how to format the frame, such as breaking the ingress frame into fragments for transmission in multiple egress frames”, (Smith1: Col 61 lines 51-57), “the originating node includes a payload fragmenter to break data to be stored into fragments”, (Smith1: Col 289 lines 31-44).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine decompose the task into a plurality of workloads to offboard for processing on respective selected IoT devices of Smith1 with the methods and systems of Sabella resulting in a vehicle computer that could break large tasks up into smaller fragments for IoT devices based on compute/storage capability. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of utilizing “available memory” … “in the IoT mesh network”, (Smith1: Col 111 lines 27-34) to dispatch "the frames in the direction of the target device over the different communication channels selected", (Smith1: Col 66-67 lines 60-6) and "improve the operation of an IoT system by allowing the distributed storage of data across a number of constrained devices", (Smith1: Col 189 lines 28-37).
Regarding Claim 2, Sabella teaches:
instructions to: determine that the task is offboardable based on the task being permitted to use asynchronous processing.
“The MEHs 200 may execute the tasks of application” … “Additionally, less computationally intensive functionalities” … “may be executed by the UE 101”, (Sabella: ¶038), “a task offloading opportunity may depend on a tradeoff between computation (e.g., time and energy, or computational resources) for task execution and energy spent to communicating data (e.g., the input/output of the offloaded task, or network resources). The affordability of this offloading tradeoff may depend on the specific application considered”, (Sabella: ¶042), “when determining whether to offload computational tasks, a UE 101 may evaluate various criteria” … “application parameters such as computational needs, input/output characteristics, and volume of exchanged data with the edge server; and pre-assessment of latency and energy consumption for the different offloading opportunities”, (Sabella: ¶058), “this procedure should be executed as fast as possible but does not have a real time constraint”, (Sabella: ¶164). Examiner notes: while Sabella teaches latency tolerance, Sabella does not explicitly teach asynchronous processing furthermore the system in Sabella determines whether a task is suitable for remote offloading and can tolerate non-immediate execution through the evaluation of latency and communication resources.
Further regarding Claim 2, Sabella fails to teach:
Asynchronous processing
However, Smith1 teaches: “universal asynchronous receiver/transmitter (UART), or integrated radio. The components of the IoT device in accordance with some embodiments are discussed further with respect to FIG. 204”, (Smith1: Col 199 lines 42-56, Fig. 203-204).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine Asynchronous processing of Smith1 with the methods and systems of Sabella resulting in a vehicle computer able to determine if a task can be offloaded and processed asynchronously. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of "determining if network connectivity is poor, and implementing connectivity policies to improve communication", (Smith1: Col 373 lines 42-46).
Regarding Claim 4, Sabella teaches:
the instructions to determine the selected IoT devices include instructions to evaluate qualities of service (QoS) of the plurality of IoT devices.
“The services may be provided in accordance with the Quality of Service (QoS) terms specified in service level and service delivery agreements”, (Sabella: ¶195), “The integration of sensory systems may allow systematic and autonomous communication and coordination of service delivery against contractual service objectives, orchestration and quality of service (QoS) based swarming and fusion of resources”, (Sabella: ¶206), “For the purpose of task offloading optimization, each UE 101 (e.g., in the first embodiments) or MEC entity (e.g., in the second embodiments) may collect the following information: (1) characteristics of the different Aps”… “(2) application parameters” … “(3) pre-assessment of energy consumption and latency”, (Sabella: ¶066), “with a near real-time indication on the throughput estimated to be available at the radio downlink interface in a next time instant”, (Sabella: ¶065), “example of radio link characteristics, including average data rate and latency”, (Sabella: ¶145).
Regarding Claim 7, Sabella teaches:
wherein the instructions to evaluate the QoS of the plurality of IoT devices include instructions to order the plurality of IoT devices based upon a best fit of available shared resources for the task and select a top number of the plurality of IoT devices as the selected IoT devices for offboarding of the task.
“a selection of targets may be compiled into a shortlist of target devices based on first conditions/criteria, and a target device may be selected from the shortlist based on second conditions/criteria. For example, a shortlist of candidate devices having a threshold energy consumption could be compiled, and a target device having a best latency performance among the candidates may be selected from the shortlist as the optimum offloading host”, (Sabella: ¶150), “identify application requirements of various application tasks of the one or more UE applications for computational offloading at one of the plurality of MEHs”, (Sabella: ¶234), “the MEH parameters comprise a computational capacity of the respective MEHs, currently available computational load of the respective MEHs, a security level of the respective MEHs, and a reuse degree of computational MEH resources of the respective MEHs”, (Sabella: ¶235), “select the MEH according to an offloading configuration, wherein the offloading configuration is to indicate that selection of the MEH is to be based on: a lowest latency budget among the plurality of MEC hosts”, (Sabella: ¶229).
Regarding Claim 8, Sabella fails to teach:
instructions to encode the plurality of workloads into a plurality of respective containers, each container including code and dependencies for one of the workloads of the decomposed task.
However, Smith1 teaches: “This may be performed, for example, by splitting the payload into N byte sequences.”, (Smith: Col 61 lines 4-12), “is a networking protocol-agnostic method of splitting data into multiple independent parallel data subsets”, (Smith: Col 63 lines 37-53), “In an example, the encapsulation modules may be containers such as docker containers and virtualization constructs including virtual machines”, (Smith: Col 165-166 lines 17-20), “if the service is a container, then existing methods for deploying the container may be employed once a suitable target home is found for it.”, (Smith: Col 166 lines 21-42), “FIG. 178 is a block diagram of a non-transitory, machine readable medium 17800 including code to define tasks and commission nodes in accordance with some embodiments,” (Smith1: Col 174 lines 24-28), “the floating service may compose a task” … “composed functions can be broken down into smaller fixed functions”, (Smith1: Col 162 lines 39-56) “A floating service owner may also specify software dependencies as features to be assessed.”, (Smith1: Col 165-166 lines 17-20),“may include code 17804 to direct the processor 902 to calculate”, (Smith1: Col 174 lines 47-61), “code 18210 to direct the processor 902 to send a packet from the device through the network”, (Smith1: Col 179 lines 56-67).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine encoding the plurality of workloads into a plurality of respective containers, each container including code and dependencies for one of the workloads of the decomposed task of Smith1 with the methods and systems of Sabella resulting in a vehicle computer that could process fragmented workloads in a container. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of dispatching "the frames in the direction of the target device over the different communication channels selected", (Smith1: Col 66-67 lines 60-6) and "improve the operation of an IoT system by allowing the distributed storage of data across a number of constrained devices", (Smith1: Col 189 lines 28-37) via “an encapsulation module capable of being executed on a wide range of hardware systems”, (Smith1: Col 165-166 lines 17-20).
Regarding Claim 9, Sabella fails to teach:
the instructions to send the workloads to the respective selected IoT devices include instructions to transmit each of the plurality of containers to a respective one of the selected IoT devices.
However, Smith1 teaches: “This may be performed, for example, by splitting the payload into N byte sequences. Each byte sequence may be placed into a separate destination protocol frame and the packet sequences are numbered”, (Smith1: Col 61 lines 4-12), “is a networking protocol-agnostic method of splitting data into multiple independent parallel data subsets and conveying them over multiple network paths before recombination at the destination”, (Smith1: Col 63 lines 37-53), "the frames in the direction of the target device over the different communication channels selected", (Smith1: Col 66-67 lines 60-6), “In an example, the encapsulation modules may be containers such as docker containers and virtualization constructs including virtual machines”, (Smith1: Col 165-166 lines 17-20), “if the service is a container, then existing methods for deploying the container may be employed once a suitable target home is found for it. In response to the floating service dispatch, hosts may be discovered”, (Smith1: Col 166 lines 21-42)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine sending the workloads to the respective selected IoT devices include instructions to transmit each of the plurality of containers to a respective one of the selected IoT devices of Smith1 with the methods and systems of Sabella resulting in a vehicle computer that could process fragmented workloads in a container. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of workloads not having “to be sequentially sent in an IoT network”, and “to decrease the transmission time and improve the transmission efficiency", (Smith1: Col 63 lines 37-53) via “an encapsulation module capable of being executed on a wide range of hardware systems”, (Smith1: Col 165-166 lines 17-20).
Regarding Claim 10, Sabella teaches:
instructions to receive and aggregate results data from the selected IoT devices for the workloads of the task to complete processing of the task.
“data volume to be transferred as input for offloading the task (e.g., data to be sent by UE 101 for offloading), and data volume to be transferred as an output for offloading the task (e.g., data to be sent back to the UE 101 after offloading)”, (Sabella: ¶146), “after performing the tradeoff evaluation, the offloader 732 of the UE 101 has selected the MEH 200-1, and at operation 822, the offloader 732 of the UE 101 may control transfer of application tasks to the MEH 200-1 for execution”, (Sabella: ¶151), “The Multi-Access (MX) Convergence layer may encapsulate and encapsulate user's data traffic, e.g. IP packet, with additional control information, e.g. sequence number, DRB ID, etc., and support multi-access convergence functions, e.g. aggregation, splitting/reordering, fragmentation, concatenation, etc. Notice encapsulation may not be required in some scenario, for example when sending packet over the anchor connection”, (Sabella: ¶175), “Analysis of the traffic flow and control schemes may be implemented by aggregators 1806 that are in communication with the IoT devices 1804 and each other through a mesh network”, (Sabella: ¶217), “Data may be uploaded to the cloud 1702, and commands received from the cloud 1702, through GWs 1710 that are in communication with the IoT devices 1804 and the aggregators 1806 through the mesh network”, (Sabella: ¶217).
Regarding Claim 11, Sabella teaches:
A method performed onboard a vehicle
““computer device” may describe any physical hardware device capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations, equipped to record/store data on a machine readable medium, and transmit and receive data from one or more other devices in a communications network”, (Sabella: ¶033), “The UE 101-1 is illustrated as a smartphone and UE 101-2 is illustrated as a table computer (e.g., handheld touchscreen mobile computing device connectable to one or more cellular networks), but may also comprise” … “vehicle-embedded system or a vehicle-to-everything (V2X) device”, (Sabella: ¶046, Fig 1 Part 101-1 and 101-2), “Examples of “computer devices”, “computer systems”, “UEs”, etc. may include”…“in-vehicle infotainment (IVI), in-car entertainment (ICE) devices, an Instrument Cluster (IC), head-up display (HUD) devices, onboard diagnostic (OBD) devices, dashtop mobile equipment (DME), mobile data terminals (MDTs), Electronic Engine Management System (EEMS), electronic/engine control units (ECUs), electronic/engine control modules (ECMs)”, (Sabella: ¶034), “a mass storage 708 may also couple to the processor 702”, (Sabella: ¶110), “a memory may be sized between 2 GB and 16 GB”, (Sabella: ¶109).
determining selected Internet of Things (IoT) devices from a plurality of IoT devices separate from the vehicle,
““An application might have a set of requirements (e.g., latency, processing resources, storage resources, network resources, location, network capability, security condition etc.) that need to be fulfilled by the MEH 200, and a MEC system may select the MEH 200 that fulfills all of the requirements”, (Sabella: ¶039), “The mass storage 708 may include a number of modules 731, 732 to implement the various MEH 200 selection functions described herein, as well as functionality of other embodiments discussed herein”, (Sabella: ¶134), “FIG. 1 illustrates an architecture of a system 100A” … “In system 100A, mobile edge hosts (MEHs) 200” … “In this way, consumers can use low complexity UEs 101 by off-loading computing capacity to the MEH 200”, (Sabella: ¶038), “The MEC hosts 200-1, 200-2, 200-3 (collectively referred to as “MEC hosts 200”, “MEC host 200”, “MEH 200”, or the like) may be virtual or physical devices”, (Sabella ¶059), “Similar to FIG. 15, in embodiments, one or more of IoT devices 1504, GW 1604, and so forth, may be incorporated with embodiments described herein”, (Sabella: ¶203), “any of the IoT groups discussed herein, may include the components, devices, systems discussed with regard to FIGS. 1-16”, (Sabella ¶211). Examiner notes: “MEH’s” are described as physical devices which are included in figure 1 where IoT groups may include devices found in figures 1-16.
wherein the selected IoT devices are selected based on being capable of performing a task including compute and/or storage for a vehicle subsystem;
“a task offloading opportunity may depend on a tradeoff between computation (e.g., time and energy, or computational resources) for task execution and energy spent to communicating data (e.g., the input/output of the offloaded task, or network resources)”, (Sabella: ¶042), “An application might have a set of requirements (e.g., latency, processing resources, storage resources, network resources, location, network capability, security condition etc.) that need to be fulfilled by the MEH 200, and a MEC system may select the MEH 200 that fulfills all of the requirements”, (Sabella: ¶039), “FIG. 1 illustrates an architecture of a system 100A” … “In system 100A, mobile edge hosts (MEHs) 200” … “In this way, consumers can use low complexity UEs 101 by off-loading computing capacity to the MEH 200”, (Sabella: ¶038), “The MEC hosts 200-1, 200-2, 200-3 (collectively referred to as “MEC hosts 200”, “MEC host 200”, “MEH 200”, or the like) may be virtual or physical devices”, (Sabella ¶059), “Similar to FIG. 15, in embodiments, one or more of IoT devices 1504, GW 1604, and so forth, may be incorporated with embodiments described herein”, (Sabella: ¶203), “any of the IoT groups discussed herein, may include the components, devices, systems discussed with regard to FIGS. 1-16”, (Sabella ¶211). Examiner notes: “MEH’s” are described as physical devices which are included in figure 1 where IoT groups may include devices found in figures 1-16.
decomposing the task into a plurality of workloads to offboard for processing on respective selected IoT devices; and
“The MEHs 200 may execute compute-intensive functionalities of applications (e.g., including App1, App2, and App3), namely application part(s) y (e.g., application part y1 of App1, application part y2 of App2, and application part y3 of App3) improving user experience”, (Sabella: ¶038), “By providing rich computation resources on the MEHs 200, application computation can be off-loaded to the mobile edge hosts”, (Sabella: ¶038), “In this embodiment, the S1 interface may split into two parts: an S1 user plane (S1-U) interface, which carries traffic data between the ANs 111 and 112 and the serving gateway (S-GW) 122, and an S1-mobility management entity (MME) interface”, (Sabella: ¶054). Examiner notes: Although Sabella discusses offboarding a decomposed task to a plurality of selected IoT devices, it does not discuss the act of decomposing.
sending the workloads to the respective selected IoT devices.
“By providing rich computation resources on the MEHs 200, application computation can be off-loaded to the mobile edge hosts”, (Sabella: ¶038, Fig 8), “Data may be uploaded to the cloud 1702, and commands received from the cloud 1702, through GWs 1710 that are in communication with the IoT devices 1804”, (Sabella: ¶217), “consumers can use low complexity UEs 101 by off-loading computing capacity to the MEH 200 by transferring compute-intensive processes”, (Sabella: ¶038).
Further regarding Claim 11, Sabella fails to fully teach:
decompose the task into a plurality of workloads to offboard for processing on respective selected IoT devices;
However, Smith1 teaches: “This may be performed, for example, by splitting the payload into N byte sequences. Each byte sequence may be placed into a separate destination protocol frame and the packet sequences are numbered”, (Smith1: Col 61 lines 4-12), “route the egress frame towards a destination, for example, by sending the frame on to a subsequent device with an address indicating the final destination”, (Smith1: Col 62 lines 13-32), “is a networking protocol-agnostic method of splitting data into multiple independent parallel data subsets and conveying them over multiple network paths before recombination at the destination”, (Smith1: Col 63 lines 37-53), “FIG. 98 is a process flow diagram of an example method for targeting storage or sending nodes in accordance with some embodiments”, (Smith1: Col 7 lines 23-25), “This framework may use a peer-to-peer (P2P) policy storage and deployment mechanism to utilize available memory, for example, in the IoT mesh network”, (Smith1: Col 111 lines 27-34), “Examples of information that may be collected by the monitor 12208 include current device configuration, capabilities and functions supported by each node“, (Smith1: Col 112 lines 12-22), “The formats may include constraints, such as data field length, and the like, that can be used to determine how to format the frame, such as breaking the ingress frame into fragments for transmission in multiple egress frames”, (Smith1: Col 61 lines 51-57), “the originating node includes a payload fragmenter to break data to be stored into fragments”, (Smith1: Col 289 lines 31-44).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine decompose the task into a plurality of workloads to offboard for processing on respective selected IoT devices of Smith1 with the methods and systems of Sabella resulting in a vehicle computer that could break large tasks up into smaller fragments for IoT devices based on compute/storage capability. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of utilizing “available memory” … “in the IoT mesh network”, (Smith1: Col 111 lines 27-34) to dispatch "the frames in the direction of the target device over the different communication channels selected", (Smith1: Col 66-67 lines 60-6) and "improve the operation of an IoT system by allowing the distributed storage of data across a number of constrained devices", (Smith1: Col 189 lines 28-37).
Regarding Claim 12, Sabella teaches:
determining that the task is offboardable based on the task being permitted to use asynchronous processing
“The MEHs 200 may execute the tasks of application” … “Additionally, less computationally intensive functionalities” … “may be executed by the UE 101”, (Sabella: ¶038), “a task offloading opportunity may depend on a tradeoff between computation (e.g., time and energy, or computational resources) for task execution and energy spent to communicating data (e.g., the input/output of the offloaded task, or network resources). The affordability of this offloading tradeoff may depend on the specific application considered”, (Sabella: ¶042), “when determining whether to offload computational tasks, a UE 101 may evaluate various criteria” … “application parameters such as computational needs, input/output characteristics, and volume of exchanged data with the edge server; and pre-assessment of latency and energy consumption for the different offloading opportunities”, (Sabella: ¶058), “this procedure should be executed as fast as possible but does not have a real time constraint”, (Sabella: ¶164). Examiner notes: while Sabella teaches latency tolerance, Sabella does not explicitly teach asynchronous processing furthermore the system in Sabella determines whether a task is suitable for remote offloading and can tolerate non-immediate execution through the evaluation of latency and communication resources.
Further regarding Claim 12, Sabella fails to teach:
Asynchronous processing
However, Smith1 teaches: “universal asynchronous receiver/transmitter (UART), or integrated radio. The components of the IoT device in accordance with some embodiments are discussed further with respect to FIG. 204”, (Smith1: Col 199 lines 42-56, Fig. 203-204).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine Asynchronous processing of Smith1 with the methods and systems of Sabella resulting in a vehicle computer able to determine if a task can be offloaded and processed asynchronously. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of "determining if network connectivity is poor, and implementing connectivity policies to improve communication", (Smith1: Col 373 lines 42-46).
Regarding Claim 14, Sabella teaches:
determining the selected IoT devices includes evaluating qualities of service (QoS) of the plurality of IoT devices.
“The services may be provided in accordance with the Quality of Service (QoS) terms specified in service level and service delivery agreements”, (Sabella: ¶195), “The integration of sensory systems may allow systematic and autonomous communication and coordination of service delivery against contractual service objectives, orchestration and quality of service (QoS) based swarming and fusion of resources”, (Sabella: ¶206), “For the purpose of task offloading optimization, each UE 101 (e.g., in the first embodiments) or MEC entity (e.g., in the second embodiments) may collect the following information: (1) characteristics of the different Aps”… “(2) application parameters” … “(3) pre-assessment of energy consumption and latency”, (Sabella: ¶066), “with a near real-time indication on the throughput estimated to be available at the radio downlink interface in a next time instant”, (Sabella: ¶065), “example of radio link characteristics, including average data rate and latency”, (Sabella: ¶145).
Regarding Claim 17, Sabella teaches:
evaluating the QoS of the plurality of IoT devices includes ordering the plurality of IoT devices based upon a best fit of available shared resources for the task and selecting a top number of the plurality of IoT devices as the selected IoT devices for offboarding of the task.
“a selection of targets may be compiled into a shortlist of target devices based on first conditions/criteria, and a target device may be selected from the shortlist based on second conditions/criteria. For example, a shortlist of candidate devices having a threshold energy consumption could be compiled, and a target device having a best latency performance among the candidates may be selected from the shortlist as the optimum offloading host”, (Sabella: ¶150), “identify application requirements of various application tasks of the one or more UE applications for computational offloading at one of the plurality of MEHs”, (Sabella: ¶234), “the MEH parameters comprise a computational capacity of the respective MEHs, currently available computational load of the respective MEHs, a security level of the respective MEHs, and a reuse degree of computational MEH resources of the respective MEHs”, (Sabella: ¶235), “select the MEH according to an offloading configuration, wherein the offloading configuration is to indicate that selection of the MEH is to be based on: a lowest latency budget among the plurality of MEC hosts”, (Sabella: ¶229).
Regarding Claim 18, Sabella fails to teach:
encoding the plurality of workloads into a plurality of respective containers, each container including code and dependencies for one of the workloads of the decomposed task.
However, Smith1 teaches: “This may be performed, for example, by splitting the payload into N byte sequences. Each byte sequence may be placed into a separate destination protocol frame and the packet sequences are numbered”, (Smith: Col 61 lines 4-12), “is a networking protocol-agnostic method of splitting data into multiple independent parallel data subsets and conveying them over multiple network paths before recombination at the destination”, (Smith: Col 63 lines 37-53), “In an example, the encapsulation modules may be containers such as docker containers and virtualization constructs including virtual machines”, (Smith: Col 165-166 lines 17-20), “if the service is a container, then existing methods for deploying the container may be employed once a suitable target home is found for it. In response to the floating service dispatch, hosts may be discovered”, (Smith: Col 166 lines 21-42), “FIG. 178 is a block diagram of a non-transitory, machine readable medium 17800 including code to define tasks and commission nodes in accordance with some embodiments,” (Smith1: Col 174 lines 24-28), “A floating service owner may also specify software dependencies as features to be assessed. Software features to be assessed may include, for example, an operating system type, an operating system version, a software version, patching levels, and the presence of layered applications for messaging and communication”, (Smith1: Col 165-166 lines 17-20),“may include code 17804 to direct the processor 902 to calculate a first parameter weight and a second parameter weight by comparing the first parameter value and the second parameter value”, (Smith1: Col 174 lines 47-61), “code 18210 to direct the processor 902 to send a packet from the device through the network”, (Smith1: Col 179 lines 56-67).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine encoding the plurality of workloads into a plurality of respective containers, each container including code and dependencies for one of the workloads of the decomposed task of Smith1 with the methods and systems of Sabella resulting in a vehicle computer that could process fragmented workloads in a container. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of dispatching "the frames in the direction of the target device over the different communication channels selected", (Smith1: Col 66-67 lines 60-6) and "improve the operation of an IoT system by allowing the distributed storage of data across a number of constrained devices", (Smith1: Col 189 lines 28-37) via “an encapsulation module capable of being executed on a wide range of hardware systems”, (Smith1: Col 165-166 lines 17-20).
Regarding Claim 19, Sabella fails to teach:
sending the workloads to the respective selected IoT devices includes transmitting each of the plurality of containers to a respective one of the selected IoT devices.
However, Smith1 teaches: “This may be performed, for example, by splitting the payload into N byte sequences. Each byte sequence may be placed into a separate destination protocol frame and the packet sequences are numbered”, (Smith1: Col 61 lines 4-12), “is a networking protocol-agnostic method of splitting data into multiple independent parallel data subsets and conveying them over multiple network paths before recombination at the destination”, (Smith1: Col 63 lines 37-53), "the frames in the direction of the target device over the different communication channels selected", (Smith1: Col 66-67 lines 60-6), “In an example, the encapsulation modules may be containers such as docker containers and virtualization constructs including virtual machines”, (Smith1: Col 165-166 lines 17-20), “if the service is a container, then existing methods for deploying the container may be employed once a suitable target home is found for it. In response to the floating service dispatch, hosts may be discovered”, (Smith1: Col 166 lines 21-42)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine sending the workloads to the respective selected IoT devices include instructions to transmit each of the plurality of containers to a respective one of the selected IoT devices of Smith1 with the methods and systems of Sabella resulting in a vehicle computer that could process fragmented workloads in a container. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of workloads not having “to be sequentially sent in an IoT network”, and “to decrease the transmission time and improve the transmission efficiency", (Smith1: Col 63 lines 37-53) via “an encapsulation module capable of being executed on a wide range of hardware systems”, (Smith1: Col 165-166 lines 17-20).
Regarding Claim 20, Sabella teaches:
receiving and aggregating results data from the selected IoT devices for the workloads of the task to complete processing of the task.
“data volume to be transferred as input for offloading the task (e.g., data to be sent by UE 101 for offloading), and data volume to be transferred as an output for offloading the task (e.g., data to be sent back to the UE 101 after offloading)”, (Sabella: ¶146), “after performing the tradeoff evaluation, the offloader 732 of the UE 101 has selected the MEH 200-1, and at operation 822, the offloader 732 of the UE 101 may control transfer of application tasks to the MEH 200-1 for execution”, (Sabella: ¶151), “The Multi-Access (MX) Convergence layer may encapsulate and encapsulate user's data traffic, e.g. IP packet, with additional control information, e.g. sequence number, DRB ID, etc., and support multi-access convergence functions, e.g. aggregation, splitting/reordering, fragmentation, concatenation, etc. Notice encapsulation may not be required in some scenario, for example when sending packet over the anchor connection”, (Sabella: ¶175), “Analysis of the traffic flow and control schemes may be implemented by aggregators 1806 that are in communication with the IoT devices 1804 and each other through a mesh network”, (Sabella: ¶217), “Data may be uploaded to the cloud 1702, and commands received from the cloud 1702, through GWs 1710 that are in communication with the IoT devices 1804 and the aggregators 1806 through the mesh network”, (Sabella: ¶217).
Claims 3 and 13 are rejected under 35 U.S.C. 103(a) as being unpatentable over Sabella in view of Smith1, further in view of Smith2 et al. (US 20180020329 A1) (hereinafter Smith2).
Regarding Claim 3, Sabella teaches:
the instructions to determine the selected IoT devices include instructions to evaluate available shared resources of IoT devices
“Additionally, the IoT devices in the IoT group 1706 may communicate among each other, and/or with other IoT devices of other IoT groups, to make decisions on their own and to perform their tasks as autonomously as possible”, (Sabella: ¶214), “IoT devices to reconfigure their operations and communications, such as to determine needed resources in response to conditions, queries, and device failures”, (Sabella: ¶221).
Further regarding claim 3, Sabella fails to teach:
evaluate available shared resources
However, Smith1 teaches: “A machine learning engine 9126 may be used to select which service components” … “used to satisfy the requirements of the service” … “provide information on connected devices and capabilities” … “The client 9128 may advertise the availability of the IoT device 9500 to fulfill a network service element”, (Smith1: Col 88 lines 13-36), “This is termed time-to-live (TTL), and may be determined by calculating the current resource availability at the node, such as power, network node count”, (Smith1: Col 71 lines 58-63), “Other information that can be collected by the monitor 12208 includes” … “resource availability estimation”, (Smith1: Col 112 lines 12-22), “This framework may use a peer-to-peer (P2P) policy storage and deployment mechanism to utilize available memory, for example, in the IoT mesh network”, (Smith1: Col 111 lines 27-34).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine evaluate available shared resources of Smith1 with the methods and systems of Sabella resulting in a vehicle computer that could break large tasks up into smaller fragments for IoT devices based on available shared resources. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of utilizing “available memory” … “in the IoT mesh network”, (Smith1: Col 111 lines 27-34) to dispatch "the frames in the direction of the target device over the different communication channels selected", (Smith1: Col 66-67 lines 60-6) and "improve the transmission efficiency", (Smith1: Col 63 lines 37-54).
Further regarding claim 3, Sabella in view of Smith1 fails to teach:
within a threshold distance relative to the vehicle.
However, Smith2 teaches: “detecting that the other mobile devices are within a predefined proximity to the mobile device (i.e., within a threshold distance). In block 562, the mobile device may share its current location information, as well as information collected from sensors, with the grouped mobile devices. In block 564, the mobile device may receive location and/or sensor information from the grouped mobile devices”, (Smith2: ¶100), “enhanced antenna scheme 1500 may be implemented on a vehicle”, (Smith2: ¶211), “information that could be used by vehicles (e.g., road conditions, traffic or other road hazards may be detected and routed to iOT devices”, (Smith2: ¶321).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine "within a threshold distance relative to the vehicle" of Smith2 with the methods and systems of Sabella in view of Smith1 resulting in a vehicle that could offboard tasks to available IoT devices based on proximity to the vehicle. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of "making better or more informed decisions regarding routes, speeds" and "enhanced asset tracking including container transport", (Smith2: ¶321).
Regarding Claim 13, Sabella teaches:
determining the selected IoT devices includes evaluating available shared resources of IoT devices
“Additionally, the IoT devices in the IoT group 1706 may communicate among each other, and/or with other IoT devices of other IoT groups, to make decisions on their own and to perform their tasks as autonomously as possible”, (Sabella: ¶214), “IoT devices to reconfigure their operations and communications, such as to determine needed resources in response to conditions, queries, and device failures”, (Sabella: ¶221).
Further regarding Claim 13, Sabella fails to teach:
evaluate available shared resources
However, Smith1 teaches: “A machine learning engine 9126 may be used to select which service components” … “used to satisfy the requirements of the service” … “provide information on connected devices and capabilities” … “The client 9128 may advertise the availability of the IoT device 9500 to fulfill a network service element”, (Smith1: Col 88 lines 13-36), “This is termed time-to-live (TTL), and may be determined by calculating the current resource availability at the node, such as power, network node count”, (Smith1: Col 71 lines 58-63), “Other information that can be collected by the monitor 12208 includes” … “resource availability estimation”, (Smith1: Col 112 lines 12-22), “This framework may use a peer-to-peer (P2P) policy storage and deployment mechanism to utilize available memory, for example, in the IoT mesh network”, (Smith1: Col 111 lines 27-34).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine evaluate available shared resources of Smith1 with the methods and systems of Sabella resulting in a vehicle computer that could break large tasks up into smaller fragments for IoT devices based on available shared resources. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of utilizing “available memory” … “in the IoT mesh network”, (Smith1: Col 111 lines 27-34) to dispatch "the frames in the direction of the target device over the different communication channels selected", (Smith1: Col 66-67 lines 60-6) and "improve the transmission efficiency", (Smith1: Col 63 lines 37-54).
Further regarding Claim 13, Sabella in view of Smith1 fails to teach:
within a threshold distance relative to the vehicle
However, Smith2 teaches: “detecting that the other mobile devices are within a predefined proximity to the mobile device (i.e., within a threshold distance). In block 562, the mobile device may share its current location information, as well as information collected from sensors, with the grouped mobile devices. In block 564, the mobile device may receive location and/or sensor information from the grouped mobile devices”, (Smith2: ¶100), “enhanced antenna scheme 1500 may be implemented on a vehicle”, (Smith2: ¶211), “information that could be used by vehicles (e.g., road conditions, traffic or other road hazards may be detected and routed to iOT devices”, (Smith2: ¶321).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine "within a threshold distance relative to the vehicle" of Smith2 with the methods and systems of Sabella in view of Smith1 resulting in a vehicle that could offboard tasks to available IoT devices based on proximity to the vehicle. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of "making better or more informed decisions regarding routes, speeds" and "enhanced asset tracking including container transport", (Smith2: ¶321).
Claim 5 and 15 are rejected under 35 U.S.C. 103(a) as being unpatentable over Sabella in view of Smith1, further in view of Mohalik et al. (US 11381644 B2) (hereinafter Mohalik).
Regarding Claim 5, Sabella in view of Smith1 teaches:
the instructions to evaluate the QoS of the plurality of IoT devices
“The services may be provided in accordance with the Quality of Service (QoS) terms specified in service level and service delivery agreements”, (Sabella: ¶195), “The integration of sensory systems may allow systematic and autonomous communication and coordination of service delivery against contractual service objectives, orchestration and quality of service (QoS) based swarming and fusion of resources”, (Sabella: ¶206), “For the purpose of task offloading optimization, each UE 101 (e.g., in the first embodiments) or MEC entity (e.g., in the second embodiments) may collect the following information: (1) characteristics of the different Aps”… “(2) application parameters” … “(3) pre-assessment of energy consumption and latency”, (Sabella: ¶066), “with a near real-time indication on the throughput estimated to be available at the radio downlink interface in a next time instant”, (Sabella: ¶065), “example of radio link characteristics, including average data rate and latency”, (Sabella: ¶145).
Further regarding Claim 5, Sabella in view of Smith1 fails to teach:
include instructions to filter the plurality of IoT devices based upon network connection parameters of the plurality of IoT devices.
However Mohalik teaches: “determine that the overall QoS for the first group of IoT devices is less than a threshold”… “after determining that the overall QoS for the first group of IoT devices is less than the threshold, determine whether an overall QoS for a second group of IoT devices is greater than the threshold;”… “as a result of determining that the overall QoS for a first group of IoT devices is less than the threshold, refrain from directing the IoT application to the first group of IoT devices”, (Mohalik: Claim 16), “The network profile stipulates which QoS of an IoT device will be granted in terms of e.g. allowed services to be accessed”, (Mohalik: Col 5 lines 31-38), “the PCC function 16 stores QoS information associated with the received network profile of the concerned IoT device”, (Mohalik: Col 6 lines 25-32), “the IoT micro-service device 10a now has access to the requested QoS measure of the IoT device 11a, which is based on parameters such as for instance bandwidth, latency and location of the IoT device”, (Mohalik: Col 6 lines 33-37)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the inclusion of instructions to filter the plurality of IoT devices based upon network connection parameters of the plurality of IoT devices of Mohalik with the methods and systems of Sabella in view of Smith1 resulting in a vehicle computer system that can optimize access to surrounding IoT devices. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of "advantageously give the IoT service managing device a “bird's eye view” as regards the capabilities of the IoT devices", (Mohalik: Col 3 lines 48-54) and determine the “superior” “QoS provided by the” … “subset of IoT devices”, (Mohalik: Col 7-8 lines 65-2).
Regarding Claim 15, Sabella in view of Smith1 teaches:
evaluating the QoS of the plurality of IoT devices
“The services may be provided in accordance with the Quality of Service (QoS) terms specified in service level and service delivery agreements”, (Sabella: ¶195), “The integration of sensory systems may allow systematic and autonomous communication and coordination of service delivery against contractual service objectives, orchestration and quality of service (QoS) based swarming and fusion of resources”, (Sabella: ¶206), “For the purpose of task offloading optimization, each UE 101 (e.g., in the first embodiments) or MEC entity (e.g., in the second embodiments) may collect the following information: (1) characteristics of the different Aps”… “(2) application parameters” … “(3) pre-assessment of energy consumption and latency”, (Sabella: ¶066), “with a near real-time indication on the throughput estimated to be available at the radio downlink interface in a next time instant”, (Sabella: ¶065), “example of radio link characteristics, including average data rate and latency”, (Sabella: ¶145).
Further regarding Claim 15, Sabella in view of Smith1 fails to teach:
includes filtering the plurality of IoT devices based upon network connection parameters of the plurality of IoT devices.
However Mohalik teaches: “determine that the overall QoS for the first group of IoT devices is less than a threshold”… “after determining that the overall QoS for the first group of IoT devices is less than the threshold, determine whether an overall QoS for a second group of IoT devices is greater than the threshold;”… “as a result of determining that the overall QoS for a first group of IoT devices is less than the threshold, refrain from directing the IoT application to the first group of IoT devices”, (Mohalik: Claim 16), “The network profile stipulates which QoS of an IoT device will be granted in terms of e.g. allowed services to be accessed”, (Mohalik: Col 5 lines 31-38), “the PCC function 16 stores QoS information associated with the received network profile of the concerned IoT device”, (Mohalik: Col 6 lines 25-32), “the IoT micro-service device 10a now has access to the requested QoS measure of the IoT device 11a, which is based on parameters such as for instance bandwidth, latency and location of the IoT device”, (Mohalik: Col 6 lines 33-37)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the inclusion of instructions to filter the plurality of IoT devices based upon network connection parameters of the plurality of IoT devices of Mohalik with the methods and systems of Sabella in view of Smith1 resulting in a vehicle computer system that can optimize access to surrounding IoT devices. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of "advantageously give the IoT service managing device a “bird's eye view” as regards the capabilities of the IoT devices", (Mohalik: Col 3 lines 48-54) and determine the “superior” “QoS provided by the” … “subset of IoT devices”, (Mohalik: Col 7-8 lines 65-2).
Claim 6 and 16 are rejected under 35 U.S.C. 103(a) as being unpatentable over Sabella in view of Smith1, further in view of Doshi et al. (US 20220014466 A1) (hereinafter Doshi).
Regarding Claim 6, Sabella in view of Smith1 teaches:
the instructions to evaluate the QoS of the plurality of IoT devices
“The services may be provided in accordance with the Quality of Service (QoS) terms specified in service level and service delivery agreements”, (Sabella: ¶195), “The integration of sensory systems may allow systematic and autonomous communication and coordination of service delivery against contractual service objectives, orchestration and quality of service (QoS) based swarming and fusion of resources”, (Sabella: ¶206), “For the purpose of task offloading optimization, each UE 101 (e.g., in the first embodiments) or MEC entity (e.g., in the second embodiments) may collect the following information: (1) characteristics of the different Aps”… “(2) application parameters” … “(3) pre-assessment of energy consumption and latency”, (Sabella: ¶066), “with a near real-time indication on the throughput estimated to be available at the radio downlink interface in a next time instant”, (Sabella: ¶065), “example of radio link characteristics, including average data rate and latency”, (Sabella: ¶145).
Further regarding Claim 6, Sabella in view of Smith1 fails to teach:
include instructions to filter the plurality of IoT devices based upon an encryption compatibility of the plurality of IoT devices.
However, Doshi teaches: “ICN node at an interface of the ICN router is tested for compatibility with the security metadata”, (Doshi: ¶192), “Here the interest packet indicates compatibility with the security metadata and an encryption protocol to use”, (Doshi: ¶195), “FIG. 16 illustrates an overview of an edge cloud configuration for edge computing”, (Doshi: ¶020), “SENSORS/IOT DEVICES”, (Doshi: Fig 16), “FIG. 24 illustrates a flow diagram of an example of a method for ICN tunneling, according to an embodiment”, (Doshi: ¶029), “TEST ENDPOINT FOR COMPATIBILITY WITH THE SECURITY METADATA”, (Doshi: Fig. 24).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the inclusion of instructions to filter the plurality of IoT devices based upon an encryption compatibility of the plurality of IoT devices of Doshi with the methods and systems of Sabella in view of Smith1 resulting in a vehicle computer that can determine which IoT devices it can share a secure connection with. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “improved security of hardware and root of trust trusted functions are also required, because edge locations may be unmanned and may even need permissioned access”, (Doshi: ¶127).
Regarding Claim 16, Sabella in view of Smith 1 teaches:
evaluating the QoS of the plurality of IoT devices
“The services may be provided in accordance with the Quality of Service (QoS) terms specified in service level and service delivery agreements”, (Sabella: ¶195), “The integration of sensory systems may allow systematic and autonomous communication and coordination of service delivery against contractual service objectives, orchestration and quality of service (QoS) based swarming and fusion of resources”, (Sabella: ¶206), “For the purpose of task offloading optimization, each UE 101 (e.g., in the first embodiments) or MEC entity (e.g., in the second embodiments) may collect the following information: (1) characteristics of the different Aps”… “(2) application parameters” … “(3) pre-assessment of energy consumption and latency”, (Sabella: ¶066), “with a near real-time indication on the throughput estimated to be available at the radio downlink interface in a next time instant”, (Sabella: ¶065), “example of radio link characteristics, including average data rate and latency”, (Sabella: ¶145).
Further regarding Claim 16, Sabella in view Smith1 fails to teach:
includes filtering the plurality of IoT devices based upon an encryption compatibility of the plurality of IoT devices.
However, Doshi teaches: “ICN node at an interface of the ICN router is tested for compatibility with the security metadata”, (Doshi: ¶192), “Here the interest packet indicates compatibility with the security metadata and an encryption protocol to use”, (Doshi: ¶195), “FIG. 16 illustrates an overview of an edge cloud configuration for edge computing”, (Doshi: ¶020), “SENSORS/IOT DEVICES”, (Doshi: Fig 16), “FIG. 24 illustrates a flow diagram of an example of a method for ICN tunneling, according to an embodiment”, (Doshi: ¶029), “TEST ENDPOINT FOR COMPATIBILITY WITH THE SECURITY METADATA”, (Doshi: Fig. 24).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the inclusion of instructions to filter the plurality of IoT devices based upon an encryption compatibility of the plurality of IoT devices of Doshi with the methods and systems of Sabella in view of Smith1 resulting in a vehicle computer that can determine which IoT devices it can share a secure connection with. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “improved security of hardware and root of trust trusted functions are also required, because edge locations may be unmanned and may even need permissioned access”, (Doshi: ¶127).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHIHAB ALAM whose telephone number is (571)272-8705. The examiner can normally be reached Mon - Fri 7:30am-5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bradley Teets can be reached at (571) 272-3338. 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.
/S.A./Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197