DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
1. Claims 1, 9, 16, and 18-19 are currently amended.
2. Claims 1-20 are pending.
3. Claims 1-20 are rejected.
Response to Arguments
4. The arguments regarding the rejections under 35 U.S.C. § 102 and 35 U.S.C. § 103 challenge certain limitations. These limitations are newly added and were therefore not addressed in the previous rejection; therefore, the arguments are moot. The amendments are newly addressed by the new grounds of rejection under 35 U.S.C. § 103.
5. Applicant’s arguments with respect to claim(s) 1, 9, and 16 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
6. Claims 1, 3-9, and 11-20 are rejected under 35 U.S.C. 103 as being unpatentable over Sarwar et al. US 20190149361 A1 in view of Jalkanen et al. US 20180295485 A1.
7. With regard to claim 1, Sarwar teaches:
A vehicle-based apparatus ([0011] Actuators 115 of each device 105 are components configured to perform a particular action that impacts a device's environment. For instance, devices (e.g., 105b, d) may include actuators 115 that accept an input and perform a respective action in response. Actuators can include controllers to activate additional functionality, such as an actuator to selectively toggle the power or operation of an alarm, camera (or other sensors), heating-ventilation-air conditioning (HVAC) appliance, household appliance, in-vehicle device, and/or lighting, among other examples; [0012] For instance, IoT systems may include networks built from sensors and communication modules integrated in, or attached to, “things” such as equipment, toys, tools, vehicles, etc. [...]; [0014] As shown in the example of FIG. 1, an IoT system 100 can include a variety of IoT edge devices 120, including sensor/actuator devices 105, end-user devices 130, resource brokers 160, and/or gateways 170, among other example [...] Other devices may be mobile, such as a sensor provisioned in the interior or exterior of a vehicle [...]; Examiner’s Note: The IoT system comprises devices that may be mobile and provisioned on the interior or exterior of a vehicle, making the apparatus vehicle-based. This also covers the mobile aspect of the edge gateway device that is mentioned throughout the limitations of the claims.) comprising:
an edge gateway device ([0014] As shown in the example of FIG. 1, an IoT system 100 can include a variety of IoT edge devices 120, including sensor/actuator devices 105, end-user devices 130, resource brokers 160, and/or gateways 170, among other examples. For instance, an IoT device 120 can include such examples as a mobile personal computing device (e.g., 130a), such as a smart phone or tablet device, a wearable computing device (e.g., a smart watch, smart garment, smart glasses, smart helmet, headset, etc.), less conventional computer-enhanced products such as home, building, and vehicle automation devices (e.g., smart heat-ventilation-air-conditioning (HVAC) controllers and sensors, light detection and controls, and energy management tools), smart appliances (e.g., smart televisions, smart refrigerators), among other examples. Some devices can be purposefully built to host sensor and/or actuator resources (i.e., “greenfield” devices), such as weather sensor devices that include multiple sensors related to weather monitoring (e.g., temperature, wind, humidity sensors, etc.), traffic sensors and controllers, among many other examples. [...] Other devices may be mobile, such as a sensor provisioned in the interior or exterior of a vehicle, in-package sensors (e.g., for tracking cargo), wearable devices worn by active humans or animals, and/or an aerial, ground-based, or underwater drone, among other examples. Indeed, it may be desired that some sensors move within an environment and applications can be built around use-cases involving mobile devices, mobile users, and/or changing environments; [0018] In some implementations, one or more gateway devices 170 can be utilized to facilitate communications with, or between, IoT devices 120 (e.g., sensor/actuator devices 105 and end-user devices 130) within a given IoT system 100. For instance, a gateway 170 can be utilized to extend the geographical reach of an IoT system, to provide a mechanism to communicate with IoT devices that possess limited or proprietary communications capabilities (e.g., sensor/actuator devices 105), or form sub-groups of devices within an IoT system deployment. For example, in some cases, gateways 170 may extend the reach of IoT devices built with short-range communication capabilities (e.g., Bluetooth or ZigBee devices) by providing a front-haul to those devices using their native communications capabilities, and providing a back-haul to the cloud through Wi-Fi, Ethernet, cellular, and/or any other wired or wireless communication medium; [0080] One or more embodiments may provide at least one machine accessible storage medium having instructions stored thereon, the instructions when executed on a machine, cause the machine to: detect deployment context information for an edge gateway, wherein the deployment context information identifies a deployment environment of the edge gateway based on information from one or more sensors; transmit, via a communications network, the deployment context information for the edge gateway to a gateway management node; receive, via the communications network, a gateway configuration for the edge gateway from the gateway management node; and configure the edge gateway based on the gateway configuration.) comprising:
one or more processors ([0031] In general, systems, servers, clients, computing devices, network elements, hosts, end-user devices 130, sensor/actuator devices 105, and/or any other IoT edge devices 120 or network services (e.g., cloud services 180, IoT management services 190) in example IoT system 100 may include electronic computing devices operable to receive, transmit, process, store, or manage data and information associated with the IoT system 100. As used in this document, the term “computer,” “processor,” “processor device,” or “processing device” is intended to encompass any suitable processing apparatus.); and
a memory storing program code, which, when executed by the one or more processors ([0064] Code 404, which may be one or more instructions to be executed by processor 400, may be stored in memory 402, or may be stored in software, hardware, firmware, or any suitable combination thereof, or in any other internal or external component, device, element, or object where appropriate and based on particular needs. In one example, processor 400 can follow a program sequence of instructions indicated by code 404.), causes the edge gateway device to:
execute one or more container-based applications of an Internet of Things (IoT) platform, wherein the container-based applications each perform a service associated with the IoT platform ([0015] Continuing with the example of FIG. 1, IoT management platforms 190 can be provided to allow developers and end users to build and configure IoT applications and systems. An IoT application can provide software support to organize and manage the operation of a set of IoT devices for a particular purpose or use-case. In some cases, an IoT application can be embodied as an application on an operating system of a user computing device (e.g., laptop 130b), a mobile application for execution on a smart phone, tablet, smart watch, or other mobile device (e.g., 130a), and/or an IoT application on another edge device (e.g., gateway 170). In some cases, an IoT management system 190 can provision one or more deployed devices in an IoT system with the appropriate IoT application(s).).
Although Sarwar teaches of an edge gateway device that comprises one or more processors and a memory storage program code that causes the edge gateway device to execute one or more applications of an IoT platform, where the applications perform a service associated with the IoT platform, Sarwar fails to explicitly teach that the applications are container-based.
However, in analogous art, Jalkanen teaches the idea of container-based applications of an IoT platform:
[0026] Using a container model such as Docker, it is possible to put software in a package which could then be run anywhere in the network edge or IP cloud. This offers a dynamic model since a container can be set up in a fraction of a second when needed and then terminated when no longer required. In practice, a container wraps up a piece of software in a complete file system that contains what is needed to run, guaranteeing it will always run the same, regardless of the environment. Docker is an open source container based virtualization technology which can help develop and scale IoT service applications easy and fast. The software of a container includes features and/or functions needed for running the requested resource/service or application.
[0029] In general and according to some embodiments herein, when an IoT device is switched on for the first time, or roams from a home network to a visited network, the IoT device automatically requests the network to create instances of the necessary services and brings them at the edge of the network. In practice, the IoT devices send a software/data container supporting the particular features and/or functions it needs to the network which is then responsible for running (or setting up) the container. Once the network has performed this, the IoT device can use (or run) the service instances to function properly. The container can be a very small restricted package since an IoT device does not necessarily need many features or resources from the network, thus including the container as part of even a very simple IoT device is feasible due to small memory demand and low complexity of the device.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Sarwar with the teachings of Jalkanen where the applications of an IoT platform are container-based. Similarly to Sarwar, Jalkanen teaches of providing services (applications) to an IoT device based on an IoT device request, and the network and associated network edge device sets up the container for the IoT device. Using a container helps an application be portable and accessible on a variety of different computing devices and systems. For example, as discussed in Jalkanen, using a container model such as Docker, it is possible to put software in a package which could then be run anywhere in the network edge or IP cloud. This offers a dynamic model since a container can be set up in a fraction of a second when needed and then terminated when no longer required. This ensures that the application/software will always run the same regardless of environment ([0026]).
8. With regard to claim 3, Sarwar further teaches:
wherein the apparatus is a vehicle ([0011] Actuators 115 of each device 105 are components configured to perform a particular action that impacts a device's environment. For instance, devices (e.g., 105b, d) may include actuators 115 that accept an input and perform a respective action in response. Actuators can include controllers to activate additional functionality, such as an actuator to selectively toggle the power or operation of an alarm, camera (or other sensors), heating-ventilation-air conditioning (HVAC) appliance, household appliance, in-vehicle device, and/or lighting, among other examples; [0012] For instance, IoT systems may include networks built from sensors and communication modules integrated in, or attached to, “things” such as equipment, toys, tools, vehicles, etc. [...]; [0014] As shown in the example of FIG. 1, an IoT system 100 can include a variety of IoT edge devices 120, including sensor/actuator devices 105, end-user devices 130, resource brokers 160, and/or gateways 170, among other example [...] Other devices may be mobile, such as a sensor provisioned in the interior or exterior of a vehicle [...]; Examiner’s Note: The IoT system comprises devices that may be mobile and provisioned on the interior or exterior of a vehicle, making the apparatus vehicle-based.).
9. With regard to claim 4, Sarwar further teaches:
wherein the one or more container-based applications include functionalities for at least one of vehicle telematics, vehicle health-readiness, or vehicle video capture ([0014] [...] vehicle automation devices (e.g., smart heat-ventilation-air-conditioning (HVAC) controllers and sensors, light detection and controls, and energy management tools), [...] Other devices may be mobile, such as a sensor provisioned in the interior or exterior of a vehicle, in-package sensors (e.g., for tracking cargo), wearable devices worn by active humans or animals, and/or an aerial, ground-based, or underwater drone, among other examples. Indeed, it may be desired that some sensors move within an environment and applications can be built around use-cases involving mobile devices, mobile users, and/or changing environments; [0015] Continuing with the example of FIG. 1, IoT management platforms 190 can be provided to allow developers and end users to build and configure IoT applications and systems. An IoT application can provide software support to organize and manage the operation of a set of IoT devices for a particular purpose or use-case; [0036] Intelligent gateways 270 may detect and leverage contextual information about their operating environment based on information from sensors (e.g., sensors 110 of FIG. 1), other IoT devices (e.g., sensor/actuator devices, end-user computing devices, and other gateways), cloud services, and/or other network resources. Gateways 270 may utilize context information from a gateway's own sensors and/or from sensors of other IoT devices. In some embodiments, sensors may be internal sensors or external sensors. Internal sensors, for example, may be configured to sense or monitor contextual information regarding a device's own internal operating environment, such as processor usage, device workload, memory capacity, battery capacity, network usage, internal temperature (e.g., heating of processors), software security alerts, software errors and exceptions, among other attributes and events. External sensors, for example, may be configured to detect, measure, and generate sensor data describing characteristics and contextual information of the device's external operating environment where it resides. For instance, a given sensor may be configured to detect contextual information of a device, such as movement, weight, physical contact, temperature, wind, noise, light, computer communications, wireless signals, location, humidity, the presence of radiation, liquid, or specific chemical compounds, among several other examples. Indeed, device sensors as described herein contemplate a potentially limitless universe of various sensors, each designed to detect and generate corresponding sensor data for new and unknown operating environment characteristics; [0037] For instance, IoT systems can adopt a paradigm where, instead of being programmed and/or configured to operate with specific IoT devices and/or cloud services in static environments and/or use-cases, the system can leverage contextual information about the operating environment of the IoT devices (e.g., gateways 270) to autonomously configure and deploy (and re-deploy) devices in an IoT system, and intelligently manage the IoT system with minimal human intervention. For example, context-aware gateways 270 may configure themselves autonomously based on their use-cases and context information about their operating environment, updating that configuration autonomously as their operating environment and/or use-cases change. In some cases, the use-case for a particular IoT gateway 270 may be determined automatically based on the gateway's contextual information.).
Although Sarwar teaches wherein the one or more applications include functionalities for at least one of vehicle telematics, vehicle health-readiness, or vehicle video capture, Sarwar fails to explicitly teach that the applications are container-based.
However, in analogous art, Jalkanen teaches the idea of container-based applications of an IoT platform:
[0026] Using a container model such as Docker, it is possible to put software in a package which could then be run anywhere in the network edge or IP cloud. This offers a dynamic model since a container can be set up in a fraction of a second when needed and then terminated when no longer required. In practice, a container wraps up a piece of software in a complete file system that contains what is needed to run, guaranteeing it will always run the same, regardless of the environment. Docker is an open source container based virtualization technology which can help develop and scale IoT service applications easy and fast. The software of a container includes features and/or functions needed for running the requested resource/service or application.
[0029] In general and according to some embodiments herein, when an IoT device is switched on for the first time, or roams from a home network to a visited network, the IoT device automatically requests the network to create instances of the necessary services and brings them at the edge of the network. In practice, the IoT devices send a software/data container supporting the particular features and/or functions it needs to the network which is then responsible for running (or setting up) the container. Once the network has performed this, the IoT device can use (or run) the service instances to function properly. The container can be a very small restricted package since an IoT device does not necessarily need many features or resources from the network, thus including the container as part of even a very simple IoT device is feasible due to small memory demand and low complexity of the device.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Sarwar with the teachings of Jalkanen where the applications of an IoT platform are container-based. Similarly to Sarwar, Jalkanen teaches of providing services (applications) to an IoT device based on an IoT device request, and the network and associated network edge device sets up the container for the IoT device. Using a container helps an application be portable and accessible on a variety of different computing devices and systems. For example, as discussed in Jalkanen, using a container model such as Docker, it is possible to put software in a package which could then be run anywhere in the network edge or IP cloud. This offers a dynamic model since a container can be set up in a fraction of a second when needed and then terminated when no longer required. This ensures that the application/software will always run the same regardless of environment ([0026]).
10. With regard to claim 5, Sarwar further teaches:
wherein the program code, when executed by the one or more processors, further causes the edge device to:
correlate data between the one or more container-based applications ([0010] External sensors 110, for example, may be configured to detect, measure, and generate sensor data describing characteristics and contextual information of the device's 105 external operating environment where it resides. For instance, a given sensor 110 may be configured to detect contextual information of a device 105, such as movement, weight, physical contact, temperature, wind, noise, light, computer communications, wireless signals, location, humidity, the presence of radiation, liquid, or specific chemical compounds, among several other examples. Indeed, device sensors 110 as described herein contemplate a potentially limitless universe of various sensors, each designed to detect and generate corresponding sensor data for new and unknown operating environment characteristics; [0012] In some instances, an IoT system can develop organically or unexpectedly, with a collection of sensors monitoring a variety of contextual attributes of their operating environments, which are then interconnected with data analytics systems and/or systems controlling one or more other smart devices to enable various novel use-cases and applications.); and
transmit the correlated data to a second one or more container-based applications ([0017] In some cases, IoT systems can interface (through a corresponding IoT management system or application or one or more of the participating IoT devices) with remote services, such as data storage, information services (e.g., media services, weather services), geolocation services, and computational services (e.g., data analytics, search, diagnostics, etc.) hosted in cloud-based and other remote systems (e.g., 180, 190). For instance, the IoT system can connect to a remote service over one or more networks 140. In some cases, the remote service can, itself, be considered an asset of an IoT application and system. Data received by a remotely-hosted service can be consumed by the governing IoT application and/or one or more of the component IoT devices to cause one or more results or actions to be performed, among other examples.).
Although Sarwar teaches wherein the program code, when executed by the one or more processors, further causes the edge device to: correlate data between the one or more applications; and transmit the correlated data to a second one or more applications, Sarwar fails to explicitly teach that the applications are container-based.
However, in analogous art, Jalkanen teaches the idea of container-based applications of an IoT platform:
[0026] Using a container model such as Docker, it is possible to put software in a package which could then be run anywhere in the network edge or IP cloud. This offers a dynamic model since a container can be set up in a fraction of a second when needed and then terminated when no longer required. In practice, a container wraps up a piece of software in a complete file system that contains what is needed to run, guaranteeing it will always run the same, regardless of the environment. Docker is an open source container based virtualization technology which can help develop and scale IoT service applications easy and fast. The software of a container includes features and/or functions needed for running the requested resource/service or application.
[0029] In general and according to some embodiments herein, when an IoT device is switched on for the first time, or roams from a home network to a visited network, the IoT device automatically requests the network to create instances of the necessary services and brings them at the edge of the network. In practice, the IoT devices send a software/data container supporting the particular features and/or functions it needs to the network which is then responsible for running (or setting up) the container. Once the network has performed this, the IoT device can use (or run) the service instances to function properly. The container can be a very small restricted package since an IoT device does not necessarily need many features or resources from the network, thus including the container as part of even a very simple IoT device is feasible due to small memory demand and low complexity of the device.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Sarwar with the teachings of Jalkanen where the applications of an IoT platform are container-based. Similarly to Sarwar, Jalkanen teaches of providing services (applications) to an IoT device based on an IoT device request, and the network and associated network edge device sets up the container for the IoT device. Using a container helps an application be portable and accessible on a variety of different computing devices and systems. For example, as discussed in Jalkanen, using a container model such as Docker, it is possible to put software in a package which could then be run anywhere in the network edge or IP cloud. This offers a dynamic model since a container can be set up in a fraction of a second when needed and then terminated when no longer required. This ensures that the application/software will always run the same regardless of environment ([0026]).
11. With regard to claim 6, Sarwar further teaches:
wherein the edge gateway device further comprises a programmable rules engine ([0016] In some cases, an IoT application can make use of a dedicated or general purpose management utility or administrative tool 190 allowing users to configure settings and policies to govern how the set of devices (e.g., IoT edge devices 120) are to operate when deployed in an IoT system. An IoT management utility 190 can also be used to select which devices are used with the application; [0024] In some embodiments, an IoT management system 190 may be used to facilitate autonomous configuration and/or deployment of IoT devices and applications, such as IoT gateways 170. For example, an IoT management system 190 may utilize asset abstraction to simplify the IoT device configuration and deployment process. For instance, users can simply select use-cases, classes, and/or taxonomies of IoT devices 120 and logically assemble a collection of select device classes to build and/or deploy at least a portion of an IoT system or application (e.g., without having to provide details regarding configuration, device identification, data transfer, etc.). In fact, in some cases, the use-case for a particular IoT device or application may be determined automatically based on contextual information from the IoT devices 120, such as a context-aware IoT gateway 170; Examiner’s Note: The administrative tool 190 is analogous with a programmable rules engine.).
12. With regard to claim 7, Sarwar teaches:
wherein the program code, when executed by the one or more processors, further causes the edge gateway device to:
receive a specification of one or more middleware functions for one of the one or more container-based applications ([0046] Gateway communication session management module 291a is the core component for communications between the gateway management service provider 290 and the IoT gateways 270. Communication module 291a manages the communications channel between the cloud agent 291 and the gateways 270, providing synchronous and asynchronous session management and tracking services. This component provides a mechanism for the gateway agents 271 to exchange information with the cloud agent 291, such as contextual deployment information, gateway configuration profiles, and status updates, among other examples. This module 291a may utilize any type of communications protocol, including TCP/IP, Wi-Fi, cellular, and/or any other wired or wireless communications protocol; Examiner’s Note: The gateway communication session management model 291a is middleware, specifically operation as a communications middleware.);
identify one or more low-level functions corresponding to the one or more middleware functions ([0048] Communication analyzing and optimization management module 291c analyzes information regarding the gateway's communications patterns, such as network traffic patterns. For example, gateway 270 may monitor its overall communications and may provide information regarding those communications to cloud agent 291. Communication analyzing module 291c of cloud agent 291 then performs further analysis to identify the gateway's communications patterns, allowing those communication patterns to be understood and leveraged for optimal autonomous deployment. For example, in some embodiments, machine learning techniques may be used to identify and derive meaning from the communications patterns, allowing models to be developed based on this learning, which can then be used to prescribe a particular action and/or configuration for IoT gateways under circumstances, as dictated by the models.);
generate, from the identified one or more low-level functions, a set of rules to associate with the one of the one or more container-based applications ([0024] In some embodiments, an IoT management system 190 may be used to facilitate autonomous configuration and/or deployment of IoT devices and applications, such as IoT gateways 170. For example, an IoT management system 190 may utilize asset abstraction to simplify the IoT device configuration and deployment process. For instance, users can simply select use-cases, classes, and/or taxonomies of IoT devices 120 and logically assemble a collection of select device classes to build and/or deploy at least a portion of an IoT system or application (e.g., without having to provide details regarding configuration, device identification, data transfer, etc.). In fact, in some cases, the use-case for a particular IoT device or application may be determined automatically based on contextual information from the IoT devices 120, such as a context-aware IoT gateway 170; [0049] Context-aware deployment management module 291d processes the information collected by the analyzing and optimization management module, along with any other context-based information regarding the gateway's operating environment, as discussed throughout this disclosure. Context-aware module 291d creates the context-aware configurations and settings for the distributed gateway management system. In addition, gateway settings and configurations are collected and categorized for different types of use-case deployments to help derive the patterns of communications, as discussed above. The model created from the communication pattern is used for configuration and management of IoT gateways.); and
load the rules into the programmable rules engine ([0024] In some embodiments, an IoT management system 190 may be used to facilitate autonomous configuration and/or deployment of IoT devices and applications, such as IoT gateways 170. For example, an IoT management system 190 may utilize asset abstraction to simplify the IoT device configuration and deployment process. For instance, users can simply select use-cases, classes, and/or taxonomies of IoT devices 120 and logically assemble a collection of select device classes to build and/or deploy at least a portion of an IoT system or application (e.g., without having to provide details regarding configuration, device identification, data transfer, etc.). In fact, in some cases, the use-case for a particular IoT device or application may be determined automatically based on contextual information from the IoT devices 120, such as a context-aware IoT gateway 170.).
Although Sarwar teaches wherein the program code, when executed by the one or more processors, further causes the edge gateway device to: receive a specification of one or more middleware functions for one of the one or more applications; identify one or more low-level functions corresponding to the one or more middleware functions; generate, from the identified one or more low-level functions, a set of rules to associate with the one of the one or more applications; and load the rules into the programmable rules engine., Sarwar fails to explicitly teach that the applications are container-based.
However, in analogous art, Jalkanen teaches the idea of container-based applications of an IoT platform:
[0026] Using a container model such as Docker, it is possible to put software in a package which could then be run anywhere in the network edge or IP cloud. This offers a dynamic model since a container can be set up in a fraction of a second when needed and then terminated when no longer required. In practice, a container wraps up a piece of software in a complete file system that contains what is needed to run, guaranteeing it will always run the same, regardless of the environment. Docker is an open source container based virtualization technology which can help develop and scale IoT service applications easy and fast. The software of a container includes features and/or functions needed for running the requested resource/service or application.
[0029] In general and according to some embodiments herein, when an IoT device is switched on for the first time, or roams from a home network to a visited network, the IoT device automatically requests the network to create instances of the necessary services and brings them at the edge of the network. In practice, the IoT devices send a software/data container supporting the particular features and/or functions it needs to the network which is then responsible for running (or setting up) the container. Once the network has performed this, the IoT device can use (or run) the service instances to function properly. The container can be a very small restricted package since an IoT device does not necessarily need many features or resources from the network, thus including the container as part of even a very simple IoT device is feasible due to small memory demand and low complexity of the device.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Sarwar with the teachings of Jalkanen where the applications of an IoT platform are container-based. Similarly to Sarwar, Jalkanen teaches of providing services (applications) to an IoT device based on an IoT device request, and the network and associated network edge device sets up the container for the IoT device. Using a container helps an application be portable and accessible on a variety of different computing devices and systems. For example, as discussed in Jalkanen, using a container model such as Docker, it is possible to put software in a package which could then be run anywhere in the network edge or IP cloud. This offers a dynamic model since a container can be set up in a fraction of a second when needed and then terminated when no longer required. This ensures that the application/software will always run the same regardless of environment ([0026]).
13. With regard to claim 8, Sarwar further teaches:
wherein the program code, when executed by the one or more processors, further causes the edge gateway device to:
receive a specification of one or more middleware functions for controlling one or more hardware components of the edge gateway device ([0032] Systems, such as those shown and illustrated herein, can include machine logic implemented in hardware and/or software, and/or embodied in a computer readable medium, to implement the solutions described throughout this disclosure; [0046] Gateway communication session management module 291a is the core component for communications between the gateway management service provider 290 and the IoT gateways 270. Communication module 291a manages the communications channel between the cloud agent 291 and the gateways 270, providing synchronous and asynchronous session management and tracking services. This component provides a mechanism for the gateway agents 271 to exchange information with the cloud agent 291, such as contextual deployment information, gateway configuration profiles, and status updates, among other examples. This module 291a may utilize any type of communications protocol, including TCP/IP, Wi-Fi, cellular, and/or any other wired or wireless communications protocol; Examiner’s Note: The gateway communication session management model 291a is middleware, specifically operation as a communications middleware.);
identify one or more low-level functions corresponding to the middleware functions ([0048] Communication analyzing and optimization management module 291c analyzes information regarding the gateway's communications patterns, such as network traffic patterns. For example, gateway 270 may monitor its overall communications and may provide information regarding those communications to cloud agent 291. Communication analyzing module 291c of cloud agent 291 then performs further analysis to identify the gateway's communications patterns, allowing those communication patterns to be understood and leveraged for optimal autonomous deployment. For example, in some embodiments, machine learning techniques may be used to identify and derive meaning from the communications patterns, allowing models to be developed based on this learning, which can then be used to prescribe a particular action and/or configuration for IoT gateways under circumstances, as dictated by the models.);
generate application code incorporating the identified one or more low-level functions ([0023] For instance, IoT management and applications can adopt a paradigm where, instead of being programmed and/or configured to operate with specific IoT devices 120 and/or cloud services 180 in static environments and/or use-cases, the system can leverage contextual information about the operating environment of the cognitive IoT devices 120 to autonomously configure and deploy (and re-deploy) an IoT system, and intelligently manage the IoT system, with minimal human intervention. For example, context-aware gateways 170 may configure themselves autonomously based on their use-case and context information about their operating environment, updating that configuration autonomously as their operating environment and/or use-case change); and
execute the generated application code ([0024] In some embodiments, an IoT management system 190 may be used to facilitate autonomous configuration and/or deployment of IoT devices and applications, such as IoT gateways 170. For example, an IoT management system 190 may utilize asset abstraction to simplify the IoT device configuration and deployment process. For instance, users can simply select use-cases, classes, and/or taxonomies of IoT devices 120 and logically assemble a collection of select device classes to build and/or deploy at least a portion of an IoT system or application (e.g., without having to provide details regarding configuration, device identification, data transfer, etc.). In fact, in some cases, the use-case for a particular IoT device or application may be determined automatically based on contextual information from the IoT devices 120, such as a context-aware IoT gateway 170.).
14. Regarding claim 9, it is rejected under the same reasoning as claim 1 above. Therefore, it is rejected under the same rationale.
15. Regarding claim 11, it is rejected under the same reasoning as claim 4 above. Therefore, it is rejected under the same rationale.
16. Regarding claim 12, it is rejected under the same reasoning as claim 5 above. Therefore, it is rejected under the same rationale.
17. Regarding claim 13, it is rejected under the same reasoning as claim 6 above. Therefore, it is rejected under the same rationale.
18. Regarding claim 14, it is rejected under the same reasoning as claim 7 above. Therefore, it is rejected under the same rationale.
19. Regarding claim 15, it is rejected under the same reasoning as claim 8 above. Therefore, it is rejected under the same rationale.
20. Regarding claim 16, it is rejected under the same reasoning as claim 1 above. Therefore, it is rejected under the same rationale.
21. Regarding claim 17, it is rejected under the same reasoning as claim 5 above. Therefore, it is rejected under the same rationale.
22. Regarding claim 18, it is rejected under the same reasoning as claim 7 above. Therefore, it is rejected under the same rationale.
23. Regarding claim 19, it is rejected under the same reasoning as claim 8 above. Therefore, it is rejected under the same rationale.
24. Regarding claim 20, it is rejected under the same reasoning as claim 4 above. Therefore, it is rejected under the same rationale.
25. Claims 2 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Sarwar et al. US 20190149361 A1 and Jalkanen et al. US 20180295485 A1, as applied in claim 1, in further view of Walkes et al. US 20220164177 A1.
26. With regard to claim 2, Sarwar and Jalkanen teach the apparatus of claim 1 but fail to explicitly teach wherein the program code, when executed by the one or more processors, further causes the edge gateway device to: retrieve, from a repository hosted on a cloud network, one or more additional container-based applications.
However, in analogous art, Walkes teaches:
wherein the program code, when executed by the one or more processors, further causes the edge gateway device to:
retrieve, from a repository hosted on a cloud network, one or more additional container-based applications ([0033] For example, the herein-disclosed docker engine may pull from an app store repository a docker container, which may then be run locally at an edge device; [0050] The edge engine framework may provide additional policy and mechanism to a container engine (e.g., Docker) for the purpose of deploying third party applications in a cloud hosted application store, which can then be deployed and run on edge device 145. The framework may include: (i) validating that a third party application meets policy requirements (e.g., where and/or how much persistent storage can be written by the application, how network access can be interacted by the application, how much processing resources and/or memory can be consumed by the application, etc.) through automated testing and compliance checks; (ii) configuring container engine 120, e.g., for appropriate repository access based on a policy controlled by cloud server 101; (iii) pulling and running third party applications on an edge device at the request of the cloud server; (iv) monitoring status of containers (e.g., temperature of a hardware component, CPU utilization, GPU utilization, storage utilization, or another parameter such as performance of processing in frames per second or a similar metric), interacting with a cloud server to support remote controlling (e.g., pause, stop, run, delete, restart, or another function, as shown in FIG. 3) and monitoring of each container's run state; and/or (v) deploying edge device firmware updates through an update repository with support for delta (e.g., comprising one or more changes from a previous version) updates.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Sarwar and Jalkanen with the teachings of Walkes wherein the program code, when executed by the one or more processors, further causes the edge gateway device to: retrieve, from a repository hosted on a cloud network, one or more additional container-based applications. Similarly to Sarwar and Jalkanen, Walkes teaches implementing docker containers with an application store that helps deploy the containers. The application store acts as a repository that the docker engine may pull a docker container from. Having a repository of docker containers allows the docker engine to pull the correct container and allow it to run locally at an edge device, as discussed in Walkes ([0033]; [0050]).
27. Regarding claim 10, it is rejected under the same reasoning as claim 2 above. Therefore, it is rejected under the same rationale.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AN-AN N NGUYEN whose telephone number is (571)272-6147. The examiner can normally be reached Monday-Friday 8:00-5:00 ET.
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, AIMEE LI can be reached at (571) 272-4169. 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.
/AN-AN NGOC NGUYEN/Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights