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 06/16/2026.
Claims 2 and 12 are canceled
Claims 1, 8, 10-11, 17-18, and 20 are amended.
Claims 21 and 22 are new.
Claims 1, 3-11, 13-22 are pending.
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, 3-11 and 13-22 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, 3-10 and 21-22 are directed to a system and falls within the statutory category of machines; Claims 11 and 13-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, 11 and 21: 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 at least one of compute storage for a vehicle subsystem”, “decompose/decomposing the task into a plurality of workloads to offboard for processing on respective selected IoT devices”, “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, but for the recitation of generic computing components being used as a tool to perform the functionality, 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. Lastly, a person can think about whether or not a task could be done at a different time than another
Therefore, yes, Claims 1, 11 and 21 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, 11 and 21: 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, 11 and 21 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, 11 and 21: 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, 11 and 21 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, 18 and 21, they recite “encode/encoding the workloads into a plurality of respective containers, each container including code and dependencies for one of the workloads”, 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, 18 and 21 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, 18 and 21 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 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 § 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 at least on of compute and 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 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.
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.
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).
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 decompose the task into a plurality of workloads to offboard for processing on respective selected IoT devices and Asynchronous processing 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 and 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 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) "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.
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 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 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 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 at least one of compute and 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.
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.
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).
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 decompose the task into a plurality of workloads to offboard for processing on respective selected IoT devices; and Asynchronous processing 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 and 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 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) "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 workloads into a plurality of respective containers, each container including code and dependencies for one of the workloads.
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 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, 13 and 21-22 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).
Regarding Claim 21, Sabella teaches:
A system comprising a 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 at least one of compute and 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.
and 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 21, Sabella doesn’t fully teach:
and based on evaluating available shared resources of IoT devices within a threshold distance relative to the vehicle;
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).
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 based on evaluating available shared resources of IoT devices within a threshold distance relative to the vehicle; 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 and can be offloaded. 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) "determining if network connectivity is poor, and implementing connectivity policies to improve communication", (Smith1: Col 373 lines 42-46), "improve the transmission efficiency", (Smith1: Col 63 lines 37-54).
Further regarding Claim 21, Sabella in view of Smith1 fails to teach:
and based on evaluating available shared resources of IoT devices 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 22, Sabella fails to teach:
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. 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 encode a 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).
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).
Response to Arguments
In light of applicants amendments, all Claim objections and rejections under 35 U.S.C. 112(b) have been with withdrawn.
Regarding rejections made under 35 U.S.C. 101:
Applicant argues: “The Office Action rejected the claims under § 101, alleging that "under [their] broadest reasonable interpretation," the claims could be practiced in the human mind. According to the office action, "a person can mentally select a device among a plurality of devices based on quality of the devices and their ability to complete a certain task," and could "decompose a task mentally into a plurality of subtasks and plan which places should process them." Applicant respectfully submits that there is provided no factual basis or evidence for these allegations. Further, on its face, independent claim 1 recites elements that could not be performed in the human mind, including to "determine 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 at least one of compute and storage for a vehicle subsystem, and to "decompose the task into a plurality of workloads to offboard for processing on respective selected IoT devices." That is, the examiner has not explained how the human mind could determine selected IoT devices or evaluate whether the IoT devices are capable of performing a task including at least one of compute and storage for a vehicle subsystem. Moreover, the examiner has not explained how a human mind would decompose a task, which after all includes program or computing instructions executed by computer processors, into a plurality of workloads for offboarding. In fact, applicant respectfully submits that the human mind could not and would not perform these features. Accordingly, the independent claims are not directed to patent ineligible abstract subject matter”
Examiner respectfully disagrees, the limitation “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”, recites the mental process of selecting from a plurality based on attributes of the selection, which, but for the recitation of generic computing components being used as a tool to perform the functionality, is a mental process and can be performed by the human mind. The limitation “decompose/decomposing the task into a plurality of workloads to offboard for processing on respective selected IoT devices”, recited the mental process of breaking down a larger task into smaller ones, which, but for the recitation of generic computing components being used as a tool to perform the functionality, is a mental process and can be performed by the human mind. Examiner notes that Claims recite generic computer components that do not integrate into practical application of the abstract ideas as they are merely being used as a tool to apply the abstract idea, thus the Claims do not recite patent eligible subject matter and the 35 U.S.C. 101 rejection is upheld.
Applicant argues: “Further, the claims recite features implemented in a software and hardware architecture that include significantly more than an abstract idea. Specifically, the claims present a technical solution to a technical problem. The specification (¶ 0009) explains:
[a] vehicle may include computing and/or storage devices for performing various computational or computing tasks ("compute tasks") and/or storage tasks for the vehicle, but may need to prioritize these computing and/or storage resources as additional tasks are desired based upon the limited compute and storage resources of the vehicle.
Accordingly, the present application provides a solution whereby "various offboardable compute and/or storage tasks of a vehicle, such as those that may be performed asynchronously, may be offboarded from the vehicle to be performed using the shared resources of nearby IoT devices." By offloading tasks from a vehicle to IoT devices, the present application solves a problem of providing application functionality given limited onboard computing resources. Thus, the present application includes a patent-eligible technical improvement to tangible computing architectures. It could not be practiced in the human mind, and even if any portions of the claims could be, the claims recite significantly more than an abstract idea because they recite a technical solution.”
Examiner respectfully disagrees, practical integration/realized improvement is not disclosed in the Claims themselves, and even then the highlighted portions of the specification fails to amount to significantly more. The highlighted portion of the specification does not disclose how the execution of the plurality of workloads are improved via the determination of where to offload said workloads. Moreover, the workloads are merely transmitted to IoT devices, but neither execution on the IoT devices, nor continued execution of the vehicle system, are required and thus any potential improvement of offloading the workloads has not been realized. Therefore, Applicant has failed to disclose any realized improvement and thus does not amount to significantly more than the judicial exception, thus the Claims do not recite patent eligible subject matter and the 35 U.S.C. 101 rejection is upheld.
Regarding rejections made under 35 U.S.C. 103:
Applicant argues: “Claim 1 as amended recites in part to "determine that the task is offboardable based on the task being permitted to use asynchronous processing." The Office Action (page 18), in addressing now-canceled claim 2, acknowledged that Sabella does not provide any disclosure concerning asynchronous processing. Smith1, relied on in the Office Action, does not compensate for Sabella's deficiencies. At most, Smithl, col. 199:53-54, discloses that an IoT device can include a "universal asynchronous receiver/transmitter (UART)." A UART is merely a communication devices and may include the word "asynchronous" in its name, but otherwise has nothing to do with asynchronous processing of a task, much less a determination that a task is "permitted to use asynchronous processing." The rejection of claim 1 and also the rejection of claim 11 should be withdrawn for at least this reason.”
Examiner respectfully disagrees, Sabella teaches: "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 of floading 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). The citations indicate that the system is able to evaluate whether or not a task is to be offboarded to other devices, and in particular that it can tolerate latency associated therewith. Synchronous processing would not tolerate offboarding and associated latency as it must maintain synchronicity, thus Sabella suggests that processing may be asynchronous without explicitly reciting as such. In combination with that of Smith1’s "universal asynchronous receiver/transmitter (UART)" the tasks may be sent and received to and from the selected IoT devices and fully teaches the disclosed Claim. Therefore, the combination of determining offboardable tasks of Sabella combined which asynchronous transmission component of Smith1 fully teaches the Broadest Reasonable Interpretation of Claims 2 and 12, thus the Claims do not recite patent eligible subject matter and the 35 U.S.C. 103 rejection is upheld.
Applicant argues: “New claim 21 recites in part that "the selected IoT devices are selected ... based on evaluating available shared resources of IoT devices within a threshold distance relative to the vehicle." The Office Action (page 18), in addressing claim 3, acknowledged that Sabella does not provide any disclosure concerning evaluating available shared resources of IoT devices within a threshold distance relative to the vehicle. The Office Action relied on Smithl and Smith2 as allegedly compensating for Sabella' s deficiencies. Without conceding allegations concerning Smith 1, or that the references could or would have been combined by one of ordinary skill, claim 21 is patentable over the references at least because Smith2 does not teach or suggest any evaluation of any resources within a threshold distance of the vehicle. Instead, Smith2, as can be clearly seen even from the excerpts cited at page 40 of the Office Action, merely discloses determining locations of IoT devices to determine a location of a wireless device. As stated in Smith's Abstract, Smith is about
determining a location of a wireless device [by] the wireless device determining its approximate location, and forming a communication group with other devices in proximity to the wireless device, the other devices including at least one internet of things (iOT) device. The wireless device may receive location information from the devices in the communication group, such as information identifying a location of the iOT device relative to a location of the iOT hub. The wireless device may use the determined approximate location in conjunction with information received from the devices in the communication group to generate a more precise location value.
That is, Smith2 merely uses locations of IoT devices to locate a wireless device. Smith2 does not compensate for deficiencies of the other references concerning selecting IoT devices "based on evaluating available shared resources of IoT devices within a threshold distance relative to the vehicle."”
Examiner respectfully disagrees, 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). The citation indicates that other mobile devices (which is an IoT device) being detected within a predefined proximity to a mobile device, which demonstrates a threshold being used to detect IoT devices within a certain range. Furthermore, Smith2 was not used for teaching evaluating available shared resources (Smith1 was relied on for this aspect) and was instead used for the act of detecting IoT devices within a threshold distance. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Therefore, the combination of Sabella in view of Smith1 and Smith2 fully teaches the limitation of “determine the selected IoT devices include instructions to evaluate available shared resources of IoT devices within a threshold distance relative to the vehicle”, thus the Claims 3 and 13 do not recite patent eligible subject matter and the 35 U.S.C. 103 rejection is upheld.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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
Prosecution Insights