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 02/18/2026.
Claims 1-8 and 10-20 are pending.
Drawings
The amended drawings were received on 02/18/2026. The objections with the drawings are withdrawn. These amended drawings are accepted by the examiner.
Specification
The objections with the specification are withdrawn. The amended specification is accepted by the examiner.
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-8 and 10-20 are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, an abstract idea, and 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-8, 10, and 11 are directed to computer systems and fall within the statutory category of machines; claims 12-15 are directed to non-transitory computer readable storage media and falls within the statutory category of articles of manufacture; and claims 16-20 are directed to methods for dynamically configuring a computer network device and falls within the statutory category of processes. Therefore, “Are the claims to a process, machine, manufacture or composition of matter?” Yes.
Step 2A Prong 1:
Claims 1, 12, and 16: The limitation of “performing authentication using an authentication proxy”, as drafted, is a process that under its broadest reasonable interpretation, covers performance of the limitation in the mind. A person can authenticate another person by verifying their identity. First, they can observe who the person is. Then, they can compare the identity of a person to a known list of people to determine if they know who the person is. For example, a person can authenticate themselves by revealing their name and face. A second person who knows the first person can authenticate them by receiving their name and observing their face, and then recognizing that they have met this person before. The second person has an internal list of all the people they have met and what they look like.
Therefore, Yes, claims 1, 12, and 16 recite a judicial exception. Step 2A Prong 2 will evaluate whether the claims are directed to a judicial exception.
Step 2A Prong 2:
Claims 1, 12, and 16: The judicial exception in not integrated into a practical application. In particular, claim 1 recites the following additional elements – “a computer system”, “an interface circuit that communicates with a computer network device”, “a processor couples to the interface circuit”, “memory, coupled to the processor, configured to store program instructions, wherein, when executed by the processor, the program instructions cause the computer system to perform operations”, and claim 12 recites a “non-transitory computer-readable storage medium for use in conjunction with a computer system, the computer-readable storage medium storing program instructions that, when executed by the computer system cause the computer system to perform operations”. These additional elements are merely recitations of generic computing components and functions merely being used as a tool to apply the abstract idea (MPEP § 2106.05(f)) which does not integrate a judicial exception into practical application. Additionally, claims 1, 12, and 16 recite “which extends functionality of the computer network device beyond an initial set of predefined functions associated with hardware in the computer network device”. This additional element is considered to be a field of use/technological environment (MPEP § 2106.05(h)) because it specifies that the application comprises functionality that can extend beyond the hardware capabilities of the computer network device. Further, claim 16 recites a “method for dynamically configuring a computer network device with a containerized data-driven application and associated metadata, comprising: by a computer system”. This additional element is also considered a field of use and technological environment because it limits the judicial exception to the kind of process it is used in and limits the types of devices in the technological environment (MPEP § 2106.05(h)). This field of use and technological environment limitations do not integrate the judicial exception into a practical application. Additionally, in claims 1, 12, and 16, the following limitations are recited: “receiving information specifying a containerized data-driven application”, “receiving second information specifying metadata associated with the containerized data-driven application”, “obtaining, in a cloud-based registry of containerized data-driven applications, the containerized data-driven application”, “providing, addressed to the computer network device, the containerized data-driven application and the metadata”, and “wherein providing the containerized data-driven application comprises initiating a reconfiguration of the computer network device with the containerized data-driven application”. These limitations are insignificant extra-solution activities. They are mere data gathering and transmission steps and do not integrate the judicial exception into a practical application. The additional limitations are an insignificant application and do not integrate the judicial exception into a practical application.
Therefore, “Do the claims recite additional elements that integrate the judicial exception in 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 evaluated the inquiries set forth in Steps 2A Prong 1 and 2, it has been concluded that claims 1, 12, and 16 not only recite a judicial exception but that the claims are directed to the judicial exception as the judicial exception has not been integrated into practical application.
Step 2B:
Claims 1, 12, and 16: 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, the additional elements only amount to generic computing components being used as a tool to apply the abstract idea, field of use/technological environment, and insignificant extra-solution data gathering and transmission activity. When reevaluated alone or in combination, the limitations “receiving information specifying a containerized data-driven application”, “receiving second information specifying metadata associated with the containerized data-driven application”, “obtaining, in a cloud-based registry of containerized data-driven applications, the containerized data-driven application”, “providing, addressed to the computer network device, the containerized data-driven application and the metadata”, and “wherein providing the containerized data-driven application comprises initiating a reconfiguration of the computer network device with the containerized data-driven application” do not add an inventive concept that is other than what is well understood, routine, and conventional in the field. MPEP § 2106.05(d)(II) lists that “Receiving or transmitting data over a network, e.g., using the Internet to gather data,” is a well understood, routine, and conventional computer function. Receiving, obtaining, and providing are all considered a transfer of data over a network.
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 with in the provided framework, claims 1, 12, and 16 do not recite eligible subject matter under 35 U.S.C. § 101.
With regard to claims 2, 13, and 17, it recites additional element recitations of “wherein the computer network device comprises: an access point, a gateway or a router”. Under its broadest reasonable interpretation, this additional claim limitation is a field of use and technological environment (MPEP § 2106.05(h)) because it specifies the kind of hardware that the computer network device could be. Claims 2, 13, and 17 do not further integrate the judicial exception into a practical application and do not, alone or in combination, amount to significantly more than the judicial exception, so claims 2, 13, and 17 fails Step 2A Prong 2 and Step 2B. Therefore, claims 2, 13, and 17 do not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claims 3, 14, and 18, it recites additional element recitations of “wherein the metadata specifies resources that the containerized data-driven application is allowed to use on the computer network device”. Under its broadest reasonable interpretation, this additional claim limitation is an insignificant extra-solution activity of selecting a particular data source or type of data to be manipulated (MPEP § 2106.05(g)) because these claims limit the kind of data included in the metadata mentioned in claims 1, 12, and 16 respectively. The selection of data to be manipulated fails to integrate the judicial exception into a practical application. Therefore, claims 3, 14, and 18 fail Step 2A Prong 2. Additionally, claims 3, 14, and 18 do not amount to significantly more and fail Step 2B. Therefore, claims 3, 14, and 18 do not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claims 4, 15, and 19, it recites additional element recitations of “wherein the containerized data-driven application executes in a virtual machine for the containerized data-driven application” and “wherein the virtual machine comprises an operating system for the containerized data-driven application”. Under its broadest reasonable interpretation, both additional elements are considered field of use and technological environment (MPEP § 2106.05(h)). They specify that the application executes in a virtual machine that comprises an operating system for the application. Both elements of the limitation fail to integrate the judicial exception into a practical application, so it fails Step 2A Prong 2. Additionally, there are no other additional elements that amount to something significantly more, so the limitation fails Step 2B. Therefore, claims 4, 15, and 19 do not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claims 5 and 20, it recites additional element recitations of “wherein the metadata is constrained based at least in part on one or more of: resources of the computer network device, one or more other applications installed on the computer network device, or one or more functions of the computer network device”. Under its broadest reasonable interpretation, the additional element is an insignificant extra-solution activity (MPEP § 2106.05(g)) and specifically part of mere data gathering. Claims 5 and 20 further constrain the kind of data the metadata mentioned in claims 1 and 16 respectively. Claims 5 and 20 do not change how the information is sent over the network. The claims do not integrate the judicial exception into a practical application, so the claims fail Step 2A Prong 2. Additionally, there are no other additional elements that amount to something significantly more, so the limitation fails Step 2B. Therefore, claims 5 and 20 do not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 6, it recites an additional element recitation of “wherein the computer system comprises a controller of the computer network device that configures and manages operation of the computer network device”. Under its broadest reasonable interpretation, the additional element is considered a field of use and technological environment (MPEP § 2106.05(h)) because it further specifies the computer system in which the judicial exception is in. Claim 6 does not add any additional elements that integrates the judicial exception into a practical application, so claim 6 fails Step 2A Prong 2. Additionally, there are no other additional elements that amount to something significantly more, so the limitation fails Step 2B. Therefore, claim 6 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 7, it recites an additional element recitation of “wherein the containerized data-driven application comprises: Bluetooth low energy (BLE) monitoring of a BLE tag, a firewall, an analytics application, a radio resource manager that communicates using a communication protocol, or another micro-service”. Under its broadest reasonable interpretation, the additional element is considered an insignificant extra-solution activity (MPEP § 2106.05(g)). Specifically, the additional element is selecting a particular data source or type of data to be manipulated because the additional element explains the potential software applications the containerized data-driven application comprises. However, the additional elements do not integrate the judicial exception into a practical application, so claim 7 fails Step 2A Prong 2. Additionally, there are no other additional elements that amount to something significantly more, so the limitation fails Step 2B. Therefore, claim 7 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 8, it recites an additional element recitation of “wherein the containerized data-driven application is securely obtained from the cloud-based registry”. Under its broadest reasonable interpretation, the additional element is considered an insignificant extra-solution activity (MPEP § 2106.05(g)). Obtaining the containerized data-driven application is considered mere data gathering. The mere data gathering of claim 8 does not integrate the judicial exception into a practical application, so claim 8 fails Step 2A Prong 2. Additionally, there are no other additional elements that amount to something significantly more, so the limitation fails Step 2B. Therefore, claim 8 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 10, it recites an additional element recitation of “wherein the receiving of the information, the second information, or both occurs via a user interface”. Under its broadest reasonable interpretation, the additional element is considered an insignificant extra-solution activity because the user interface receiving information and second information is mere data gathering (MPEP § 2106.05(g)). The mere data gathering does not integrate the judicial exception into a practical application, so claim 10 fails Step 2A Prong 2. Additionally, there are no other additional elements that amount to something significantly more, so the limitation fails Step 2B. Therefore, claim 10 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 11, it recites an additional element recitation of “wherein the second information specifies one or more modifications to predefined metadata”. Under its broadest reasonable interpretation, the additional element is considered an insignificant extra-solution activity because specifying that second information can change predefined metadata is selecting a particular data source or type of data to manipulate and as well as data gathering activity (MPEP § 2106.05(g)). Specifying that second information can change predefined metadata does not integrate the judicial exception into a practical application, so claim 11 fails Step 2A Prong 2. Additionally, there are no other additional elements that amount to something significantly more, so the limitation fails Step 2B. Therefore, claim 11 does 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.
Claim(s) 1-4, 6, 8, and 10-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Raman et al. Pub. No. US 20210075890 A1 (hereafter Raman) in view of Cao et al. Pub. No. US 20210311758 A1 (hereafter Cao) and further in view of Parla et al. Pub. No. US 11652872 B1 (hereafter Parla) and Wilson et al. Pub. No. US 7082608 B1 (hereafter Wilson).
With regard to claim 1, Raman teaches a computer system, comprising: an interface circuit that communicates with a computer network device; a processor coupled to the interface circuit; and memory, coupled to the processor, configured to store program instructions, wherein, when executed by the processor, the program instructions cause the computer system to perform operations, comprising (FIG. 1 depicts the computer system. ¶ [0007] states “This electronic device includes: a network node; an interface circuit that is communicatively coupled to the network node; a processor; and memory that stores program instructions, where, when the executed by the processor, the program instructions cause the electronic device to perform one or more operations”);
receiving information specifying a containerized data-driven application (¶ [0089] states “the electronic device may receive a request, from a second electronic device, to create the electronic-device-specific application”. ¶ [0093] adds “The services manager may install and execute the electronic-device-specific application in a provider-specific or an electronic-device-specific environment in the services manager. For example, the provider-specific or the electronic-device-specific environment may include a virtual operating system in a container in the services manager, and the electronic-device-specific application may be a plugin that executes in the container”. FIG. 8 shows the electronic-device-specific application 718-1 inside of container 714-1. Examiner’s Note: since ¶ [0093] explains that the application can be installed and executed within a container, the application specified in ¶ [0089] must be able to be containerized);
receiving second information specifying metadata associated with the containerized data-driven application (¶ [0089] states “where the user interface is configured to present predefined configuration alternatives for the configuration parameters for the electronic-device-specific application and/or to receive inputs for the configuration parameters for the electronic-device-specific application”).
Raman does not teach authenticating with an authentication proxy and then receiving the application from a cloud-based registry.
However, in an analogous art, Cao teaches performing authentication using an authentication proxy; obtaining, in a cloud-based registry of containerized data-driven applications, the containerized data-driven application (¶ [0055] states “Credential helper 332 provides the SSO credentials to auth proxy 322, which uses the SSO credentials to obtain a session token from SSO service 108. SSO service 108 determines authenticity of the SSO user based on the SSO credentials. Upon receiving an image request from Docker client 334 using the session token, registry auth service 306 authenticates and authorizes the SSO user. For authentication, registry auth service 306 cooperates with auth proxy 322 to validate the session token. Registry auth service 306 then authorizes the SSO user and returns a bearer token to Docker client 334, which uses the bearer token to perform the image push or pull”. FIG. 3 shows the relationships between the client device, the credential helper, the auth proxy, and the image registry).
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 authentication proxy and obtaining the image from a cloud registry of Cao with the computer system receiving information specifying an application of Raman to create a system that can receive information related to a containerized application and obtain the containerized application securely. A person having ordinary skill in the art would have been motivated to make this combination to improve security and scalability. Cao ¶ [0024] states that “sensitive SSO user credentials (e.g., username and password) are not stored or cached by the client accessing the image registry”. A person of ordinary skill in the art would recognize the security benefits of not storing or caching the user credentials on a client device. For example, by not storing the user credentials on the client device, a malicious actor with access to the client device would not be able to push or pull images to the container registry. Malicious actors would also not be able to steal the user credentials from the client device. Additionally, ¶ [0055] states the “virtualization management server 116, in which SSO service 108 is deployed, is not directly accessible by credential helper 332”. FIG. 3 also shows this separation. A person of ordinary skill in the art would recognize that some software architectures that benefit from having proxy intermediary between the client and authentication service. By keeping them separate, they can scale independently of each other and improve computer resource utilization.
Raman and Cao do not teach the system directly providing the containerized data-driven application to a computer network device.
However, in an analogous art, Parla teaches providing, addressed to the computer network device, the containerized data-driven application and the metadata (Col. 3 Line. 11 states “In some examples, these cloud-delivered workload functions may be container images, virtual machine images, P4-functions (e.g., for SmartNICs), Lambda functions, or the like. In some examples, the cloud-delivered workload functions may be deployed, orchestrated, and operationalized at the edge (e.g., enterprise edge or other edge network) from a central delivery and control point in a cloud-computing network based on policies and/or intents”. Col. 6 Line. 66 through Col. 7 Line. 2 states “the cloud-computing network may include a workload or policy server that is configured to deliver workloads, functions, etc. to the edge device based on decisions made by the controller. For instance, the controller may make a decision to install a workload on the edge device, and the controller may signal to the workload/policy server to deliver the workload to the edge device”),
wherein providing the containerized data-driven application comprises initiating a reconfiguration of the computer network device with the containerized data-driven application, which extends functionality of the computer network device beyond an initial set of predefined functions associated with hardware in the computer network device (Col. 3 Lines 12-17 state “In some examples, these cloud-delivered workload functions may be container images, virtual machine images, P4-functions (e.g., for SmartNICs), Lambda functions, or the like. In some examples, the cloud-delivered workload functions may be deployed, orchestrated, and operationalized at the edge”. Col. 3 Lines 24-27 states “Once deployed, the one or more images and/or functions may be operationalized and configured (e.g., spun-up and provisioned) when needed, as well as spun-down when no longer required at the edge node”. Examiner’s Note: workload functions can include container images. When a workload function is deployed, orchestrated, operationalized, and configured at an edge device, that is the edge device being reconfigured with the containerized data-driven application).
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 deployment of a workload to a computer network device of Parla with the computer system receiving information specifying an application and using an authentication proxy and image registry of Raman and Cao. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of reducing unnecessary costs, such as transit expenses, increasing system bandwidth, and reducing cloud compute resources (Col. 2 Lines. 63 – Col. 3 Line 1 states “in the context of cloud-delivered security solutions, routing a packet all the way to a cloud-computing node simply to drop the packet at a cloud-delivered firewall results in unnecessary costs, such as transit expenses, decreased bandwidth in the flow, and a waste of cloud-delivered compute resources”). The system achieves these benefits by having implementing “technologies that assist with this problem by splitting the control plane and data plane components of cloud-delivered functions (e.g., security functions) to allow them to be operationalized at the edge (e.g., enterprise edge), while maintaining centralized intent, policy, and control” (Col. 3 Lines. 6-11). Further, by applying the specified application and its metadata to a computer network device, the edge device can operationalize the workload’s functions (Parla Col. 5 Line. 27-34 states “the workload image may be installed on the edge device to operationalize the function capability. In some examples, the edge device may be a generic edge device (e.g., a persona-less device) or a specific persona device (e.g., an edge router device, an edge firewall device, etc.), and installing the workload image may transform a persona of the edge device (e.g., from a persona-less device to a specific persona device, from a specific persona device to a multiple persona device, or the like”).
Raman, Cao, and Parla do not explicitly teach a reconfiguration of the computer network device to extend functionality of the device.
However, in an analogous art, Wilson teaches wherein providing the containerized data-driven application comprises initiating a reconfiguration of the computer network device with the containerized data-driven application, which extends functionality of the computer network device beyond an initial set of predefined functions associated with hardware in the computer network device (Col. 3 Line. 6-17 states “the invention provides a software implementation of a virtual device container which virtually represents additional functionality of a network device, as if the additional functionality were embedded in the network device. In this manner, a legacy device can be made to appear to other devices on the network as if the legacy device has the embedded functionality to support new enterprise-wide applications, such as e-mail printing, security applications, network management applications, job tracking applications, resource management applications and the like”).
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 computer network device functionality extension of Wilson with the computer system of Raman, Cao, and Parla. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of adding more functionality to a network device. Wilson explains how this invention particularly applies to extending legacy network devices (Col. 1 Lines. 7-13). The goal of the applicant’s application is to reduce fragmentation and the need for users to purchase additional networking equipment, so Wilson’s teachings aid in solving the same problem. Additionally, Wilson states “a legacy device can be made to appear to other devices on the network as if the legacy device has the embedded functionality to support new enterprise-wide applications, such as e-mail printing, security applications, network management applications, job tracking applications, resource management applications and the like” (Col. 3 Line. 10-16). In doing so, “This transparent virtual extension of the functionality of legacy devices is implemented through object-based modules so that new functions can be added for network devices in a simple and efficient manner” (Col. 3 Lines 16-20). One of ordinary skill in the art recognizes the benefits of extending devices for increased functionality in a simple and efficient manner.
Regarding claim 2, Raman, Cao, Parla, and Wilson teach the computer system of claim 1. Raman additionally teaches wherein the computer network device comprises: an access point, a gateway (¶ [0008] states “The services manager in the system hierarchy may be between a computer associated with a provider of a third electronic device (such as an IoT device) and a gateway (such as an access point or an eNodeB) that communicates with the third electronic device”).
Raman, Cao, and Wilson do not specifically teach the computer network device comprising a router.
However, in an analogous art, Parla teaches that the computer network device comprises: a router (Col. 2 Line. 21-27 states “a controller of the cloud-computing network may determine that the function capability is to be operationalized on an edge node (e.g., edge router, edge firewall, or other edge device) of the enterprise network”).
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 router of Parla and the access point or gateway of Raman as possible computer network devices. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of installing the containerized data-driven application on multiple types of networking equipment that fulfill different roles in a computer network environment.
Regarding claim 3, Raman, Cao, Parla, and Wilson teach the computer system of claim 1. Raman additionally teaches wherein the metadata specifies resources that the containerized data-driven application is allowed to use on the computer network device (¶ [0008] states “the electronic-device-specific application may be defined by the available system resources, and may be mapped to pools matching the service-level-agreement requested from the configurator (such as a user or an operator) for a given container”. ¶ [0012] states “the configuration parameters for the electronic-device-specific application may be associated with different system resources (such as computational resources, memory, and/or network resources) or priorities in the services manager and/or the system hierarchy”. ¶ [0094] states “A definition may configure the system resources used by the given container to match the requirements needed to satisfy a service level agreement, such as maximum packet latency under traffic of up to a specified number of packets per second”. Examiner’s Note: the definition of the electronic-device-specific application, the service-level-agreement, and the configuration parameters are all interpreted to be metadata).
Regarding claim 4, Raman, Cao, Parla and Wilson teach the computer system of claim 1. Raman additionally teaches that wherein the virtual machine comprises an operating system for the containerized data-driven application (¶ [0008] states “the provider-specific or the electronic-device-specific environment may include a virtual operating system in a container in the services manager, and the electronic-device-specific application may be a plugin that executes in the container”).
Raman, Parla, and Wilson do not specifically teach the containerized application executing in a virtual machine.
However, Cao, does teach wherein the containerized data-driven application executes in a virtual machine for the containerized data-driven application (¶ [0001] states “Applications today are deployed onto a combination of virtual machines (VMs), containers, application services, and more”. ¶ [0021] states “Kubernetes pods are implemented as “pod VMs,” each of which includes a kernel and container engine that supports execution of containers”. ¶ [0046] states “Each pod VM 130 has one or more containers 206 running therein in an execution space managed by container engine 208. The lifecycle of containers 206 is managed by pod VM agent 212. Both container engine 208 and pod VM agent 212 execute on top of a kernel”. FIG. 2 displays a pod virtual machine that includes the containers, the container engine, the pod VM agent, and the kernel).
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 containerized application executing within a virtual machine of Cao and the virtual environment including an operating system of Raman resulting in a virtual machine comprising an operating system for the execution of a containerized application. A person having ordinary skill in the art would have been motivated to combine virtual machines and containerization because it enables the use of orchestration platforms. Orchestration platforms are known for “automating deployment, scaling, and operations of application containers across clusters of hosts” and “It offers flexibility in application development and offers several useful tools for scaling” (Cao ¶ [0001]).
Regarding claim 6, Raman, Cao, Parla, and Wilson teach the computer system of claim 1. Raman additionally teaches wherein the computer system comprises a controller of the computer network device that configures and manages operation of the computer network device (¶ [0051] states “controller 124 is used to configure settings of access points 110, such as transmit power, a transmit antenna pattern, a receive antenna pattern, etc.". FIG. 1 also shows that the controller is part of the computer system and can communicate with computer network devices).
Regarding claim 8, Raman, Cao, Parla, and Wilson teach the computer system of claim 1. Cao additionally teaches wherein the containerized data-driven application is securely obtained from the cloud-based registry (¶ [0055] states “Upon receiving an image request from Docker client 334 using the session token, registry auth service 306 authenticates and authorizes the SSO user. For authentication, registry auth service 306 cooperates with auth proxy 322 to validate the session token. Registry auth service 306 then authorizes the SSO user and returns a bearer token to Docker client 334, which uses the bearer token to perform the image push or pull”).
Regarding claim 10, Raman, Cao, Parla, and Wilson teach the computer system of claim 1. Raman additionally teaches wherein the receiving of the information, the second information, or both occurs via a user interface (¶ [0089] states “In response to the request, the electronic device may provide, to the second electronic device, instructions for a user interface (operation 912), where the user interface is configured to present predefined configuration alternatives for the configuration parameters for the electronic-device-specific application and/or to receive inputs for the configuration parameters for the electronic-device-specific application”. ¶ [0107] states “This user interface may include predefined configuration alternatives (PCAs) 1110 for configuration parameters for an electronic-device-specific application and/or fields (such as field 1112) to receive inputs for the configuration parameters for the electronic-device-specific application”. Examiner’s Note: Since Raman’s interface describes presenting configuration parameters for the electronic-device-specific application, the user interface would include the information specifying the electronic-device-specific application or “information”).
Regarding claim 11, Raman, Cao, Parla and Wilson teach the computer system of claim 1. Raman additionally teaches wherein the second information specifies one or more modifications to predefined metadata (¶ [0089] states “where the user interface is configured to present predefined configuration alternatives for the configuration parameters for the electronic-device-specific application and/or to receive inputs for the configuration parameters for the electronic-device-specific application”).
With regard to claim 12, Raman teaches a non-transitory computer-readable storage medium for use in conjunction with a computer system, the computer-readable storage medium storing program instructions that, when executed by the computer system, cause the computer system to perform operations comprising (¶ [0017] states “Another embodiment provides a computer-readable storage medium with program instructions for use with the electronic device or the services manager. When executed by the electronic device or the services manager, the program instructions cause the electronic device or the services manager to perform at least some of the aforementioned operations in one or more of the preceding embodiments”. Examiner’s Note: the “aforementioned operations” is interpreted to refer to the operations mentioned in ¶ [0007] – [0015]. These operations are explained in more detail later in Raman’s application, so “aforementioned operations” is interpreted to include those later details. These later details address the additional elements of the claim):
receiving information specifying a containerized data-driven application (¶ [0089] states “the electronic device may receive a request, from a second electronic device, to create the electronic-device-specific application”. ¶ [0093] adds “The services manager may install and execute the electronic-device-specific application in a provider-specific or an electronic-device-specific environment in the services manager. For example, the provider-specific or the electronic-device-specific environment may include a virtual operating system in a container in the services manager, and the electronic-device-specific application may be a plugin that executes in the container”. FIG. 8 shows the electronic-device-specific application 718-1 inside of container 714-1. Examiner’s Note: since ¶ [0093] explains that the application can be installed and executed within a container, the application specified in ¶ [0089] must be able to be containerized);
receiving second information specifying metadata associated with the containerized data-driven application (¶ [0089] states “where the user interface is configured to present predefined configuration alternatives for the configuration parameters for the electronic-device-specific application and/or to receive inputs for the configuration parameters for the electronic-device-specific application”).
Raman does not teach authenticating with an authentication proxy and then receiving the application from a cloud-based registry.
However, in an analogous art, Cao teaches performing authentication using an authentication proxy; obtaining, in a cloud-based registry of containerized data-driven applications, the containerized data-driven application (¶ [0055] states “Credential helper 332 provides the SSO credentials to auth proxy 322, which uses the SSO credentials to obtain a session token from SSO service 108. SSO service 108 determines authenticity of the SSO user based on the SSO credentials. Upon receiving an image request from Docker client 334 using the session token, registry auth service 306 authenticates and authorizes the SSO user. For authentication, registry auth service 306 cooperates with auth proxy 322 to validate the session token. Registry auth service 306 then authorizes the SSO user and returns a bearer token to Docker client 334, which uses the bearer token to perform the image push or pull”. FIG. 3 shows the relationships between the client device, the credential helper, the auth proxy, and the image registry).
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 authentication proxy and obtaining the image from a cloud registry of Cao with the computer system receiving information specifying an application of Raman to create a system that can receive information related to a containerized application and obtain the containerized application securely. A person having ordinary skill in the art would have been motivated to make this combination to improve security and scalability. Cao ¶ [0024] states that “sensitive SSO user credentials (e.g., username and password) are not stored or cached by the client accessing the image registry”. A person of ordinary skill in the art would recognize the security benefits of not storing or caching the user credentials on a client device. For example, by not storing the user credentials on the client device, a malicious actor with access to the client device would not be able to push or pull images to the container registry. Malicious actors would also not be able to steal the user credentials from the client device. Additionally, ¶ [0055] states the “virtualization management server 116, in which SSO service 108 is deployed, is not directly accessible by credential helper 332”. FIG. 3 also shows this separation. A person of ordinary skill in the art would recognize that some software architectures that benefit from having proxy intermediary between the client and authentication service. By keeping them separate, they can scale independently of each other and improve computer resource utilization.
Raman and Cao do not teach the system directly providing the containerized data-driven application to a computer network device.
However, in an analogous art, Parla teaches providing, addressed to the computer network device, the containerized data-driven application and the metadata (Col. 3 Line. 11 states “In some examples, these cloud-delivered workload functions may be container images, virtual machine images, P4-functions (e.g., for SmartNICs), Lambda functions, or the like. In some examples, the cloud-delivered workload functions may be deployed, orchestrated, and operationalized at the edge (e.g., enterprise edge or other edge network) from a central delivery and control point in a cloud-computing network based on policies and/or intents”. Col. 6 Line. 66 through Col. 7 Line. 2 states “the cloud-computing network may include a workload or policy server that is configured to deliver workloads, functions, etc. to the edge device based on decisions made by the controller. For instance, the controller may make a decision to install a workload on the edge device, and the controller may signal to the workload/policy server to deliver the workload to the edge device”).
wherein providing the containerized data-driven application comprises initiating a reconfiguration of the computer network device with the containerized data-driven application, which extends functionality of the computer network device beyond an initial set of predefined functions associated with hardware in the computer network device (Col. 3 Lines 12-17 state “In some examples, these cloud-delivered workload functions may be container images, virtual machine images, P4-functions (e.g., for SmartNICs), Lambda functions, or the like. In some examples, the cloud-delivered workload functions may be deployed, orchestrated, and operationalized at the edge”. Col. 3 Lines 24-27 states “Once deployed, the one or more images and/or functions may be operationalized and configured (e.g., spun-up and provisioned) when needed, as well as spun-down when no longer required at the edge node”. Examiner’s Note: workload functions can include container images. When a workload function is deployed, orchestrated, operationalized, and configured at an edge device, that is the edge device being reconfigured with the containerized data-driven application).
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 deployment of a workload to a computer network device of Parla with the computer system receiving information specifying an application and using an authentication proxy and image registry of Raman and Cao. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of reducing unnecessary costs, such as transit expenses, increasing system bandwidth, and reducing cloud compute resources (Col. 2 Lines. 63 – Col. 3 Line 1 states “in the context of cloud-delivered security solutions, routing a packet all the way to a cloud-computing node simply to drop the packet at a cloud-delivered firewall results in unnecessary costs, such as transit expenses, decreased bandwidth in the flow, and a waste of cloud-delivered compute resources”). The system achieves these benefits by having implementing “technologies that assist with this problem by splitting the control plane and data plane components of cloud-delivered functions (e.g., security functions) to allow them to be operationalized at the edge (e.g., enterprise edge), while maintaining centralized intent, policy, and control” (Col. 3 Lines. 6-11). Further, by applying the specified application and its metadata to a computer network device, the edge device can operationalize the workload’s functions (Parla Col. 5 Line. 27-34 states “the workload image may be installed on the edge device to operationalize the function capability. In some examples, the edge device may be a generic edge device (e.g., a persona-less device) or a specific persona device (e.g., an edge router device, an edge firewall device, etc.), and installing the workload image may transform a persona of the edge device (e.g., from a persona-less device to a specific persona device, from a specific persona device to a multiple persona device, or the like”).
Raman, Cao, and Parla do not explicitly teach a reconfiguration of the computer network device to extend functionality of the device.
However, in an analogous art, Wilson teaches wherein providing the containerized data-driven application comprises initiating a reconfiguration of the computer network device with the containerized data-driven application, which extends functionality of the computer network device beyond an initial set of predefined functions associated with hardware in the computer network device (Col. 3 Line. 6-17 states “the invention provides a software implementation of a virtual device container which virtually represents additional functionality of a network device, as if the additional functionality were embedded in the network device. In this manner, a legacy device can be made to appear to other devices on the network as if the legacy device has the embedded functionality to support new enterprise-wide applications, such as e-mail printing, security applications, network management applications, job tracking applications, resource management applications and the like”).
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 computer network device functionality extension of Wilson with the computer system of Raman, Cao, and Parla. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of adding more functionality to a network device. Wilson explains how this invention particularly applies to extending legacy network devices (Col. 1 Lines. 7-13). The goal of the applicant’s application is to reduce fragmentation and the need for users to purchase additional networking equipment, so Wilson’s teachings aid in solving the same problem. Additionally, Wilson states “a legacy device can be made to appear to other devices on the network as if the legacy device has the embedded functionality to support new enterprise-wide applications, such as e-mail printing, security applications, network management applications, job tracking applications, resource management applications and the like” (Col. 3 Line. 10-16). In doing so, “This transparent virtual extension of the functionality of legacy devices is implemented through object-based modules so that new functions can be added for network devices in a simple and efficient manner” (Col. 3 Lines 16-20). One of ordinary skill in the art recognizes the benefits of extending devices for increased functionality in a simple and efficient manner.
Regarding claim 13, Raman, Cao, Parla, and Wilson teach the non-transitory computer-readable storage medium of claim 12. Raman additionally teaches wherein the computer network device comprises: an access point, a gateway (¶ [0008] states “The services manager in the system hierarchy may be between a computer associated with a provider of a third electronic device (such as an IoT device) and a gateway (such as an access point or an eNodeB) that communicates with the third electronic device”).
Raman, Cao, and Wilson do not specifically teach the computer network device comprising a router.
However, in an analogous art, Parla teaches that the computer network device comprises: a router (Col. 2 Line. 21-27 states “a controller of the cloud-computing network may determine that the function capability is to be operationalized on an edge node (e.g., edge router, edge firewall, or other edge device) of the enterprise network”).
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 router of Parla and the access point or gateway of Raman as possible computer network devices. A person having ordinary skill in the art would have motivated to make this combination for the purpose of installing the containerized data-driven application on multiple types of networking equipment that fulfill different roles in a computer network environment.
Regarding claim 14, Raman, Cao, Parla, and Wilson teach the non-transitory computer-readable storage medium of claim 12. Raman additionally teaches wherein the metadata specifies resources that the containerized data-driven application is allowed to use on the computer network device (¶ [0008] states “the electronic-device-specific application may be defined by the available system resources, and may be mapped to pools matching the service-level-agreement requested from the configurator (such as a user or an operator) for a given container”. ¶ [0012] states “the configuration parameters for the electronic-device-specific application may be associated with different system resources (such as computational resources, memory, and/or network resources) or priorities in the services manager and/or the system hierarchy”. ¶ [0094] states “A definition may configure the system resources used by the given container to match the requirements needed to satisfy a service level agreement, such as maximum packet latency under traffic of up to a specified number of packets per second”. Examiner’s Note: the definition of the electronic-device-specific application, the service-level-agreement, and the configuration parameters are all interpreted to be metadata).
Regarding claim 15, Rama, Cao, Parla, and Wilson teach the non-transitory computer-readable storage medium of claim 12. Raman additionally teaches that wherein the virtual machine comprises an operating system for the containerized data-driven application (¶ [0008] states “the provider-specific or the electronic-device-specific environment may include a virtual operating system in a container in the services manager, and the electronic-device-specific application may be a plugin that executes in the container”).
Raman, Parla, and Wilson do not specifically teach the containerized application executing in a virtual machine.
However, Cao, does teach wherein the containerized data-driven application executes in a virtual machine for the containerized data-driven application (¶ [0001] states “Applications today are deployed onto a combination of virtual machines (VMs), containers, application services, and more”. ¶ [0021] states “Kubernetes pods are implemented as “pod VMs,” each of which includes a kernel and container engine that supports execution of containers”. ¶ [0046] states “Each pod VM 130 has one or more containers 206 running therein in an execution space managed by container engine 208. The lifecycle of containers 206 is managed by pod VM agent 212. Both container engine 208 and pod VM agent 212 execute on top of a kernel”. FIG. 2 displays a pod virtual machine that includes the containers, the container engine, the pod VM agent, and the kernel).
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 containerized application executing within a virtual machine of Cao and the virtual environment including an operating system of Raman resulting in a virtual machine comprising an operating system for the execution of a containerized application. A person having ordinary skill in the art would have been motivated to combine virtual machines and containerization because it enables the use of orchestration platforms. Orchestration platforms are known for “automating deployment, scaling, and operations of application containers across clusters of hosts” and “It offers flexibility in application development and offers several useful tools for scaling” (Cao ¶ [0001]).
With regard to claim 16, Raman teaches A method for dynamically configuring a computer network device with a containerized data-driven application and associated metadata, comprising: by a computer system: (¶ [0018] states “Another embodiment provides a method, which may be performed by the electronic device or the services manager. This method includes at least some of the aforementioned operations in one or more of the preceding embodiments”. Examiner’s Note: the “aforementioned operations” is interpreted to refer to the operations mentioned in ¶ [0007] – [0015]. These operations are explained in more detail later in the application, so “aforementioned operations” is interpreted to include those later details. These later details address the additional elements of the claim):
receiving information specifying a containerized data-driven application (¶ [0089] states “the electronic device may receive a request, from a second electronic device, to create the electronic-device-specific application”. ¶ [0093] adds “The services manager may install and execute the electronic-device-specific application in a provider-specific or an electronic-device-specific environment in the services manager. For example, the provider-specific or the electronic-device-specific environment may include a virtual operating system in a container in the services manager, and the electronic-device-specific application may be a plugin that executes in the container”. FIG. 8 shows the electronic-device-specific application 718-1 inside of container 714-1. Examiner’s Note: since ¶ [0093] explains that the application can be installed and executed within a container, the application specified in ¶ [0089] must be able to be containerized);
receiving second information specifying metadata associated with the containerized data-driven application (¶ [0089] states “where the user interface is configured to present predefined configuration alternatives for the configuration parameters for the electronic-device-specific application and/or to receive inputs for the configuration parameters for the electronic-device-specific application”).
Raman does not teach authenticating with an authentication proxy and then receiving the application from a cloud-based registry.
However, in an analogous art, Cao teaches performing authentication using an authentication proxy; obtaining, in a cloud-based registry of containerized data-driven applications, the containerized data-driven application (¶ [0055] states “Credential helper 332 provides the SSO credentials to auth proxy 322, which uses the SSO credentials to obtain a session token from SSO service 108. SSO service 108 determines authenticity of the SSO user based on the SSO credentials. Upon receiving an image request from Docker client 334 using the session token, registry auth service 306 authenticates and authorizes the SSO user. For authentication, registry auth service 306 cooperates with auth proxy 322 to validate the session token. Registry auth service 306 then authorizes the SSO user and returns a bearer token to Docker client 334, which uses the bearer token to perform the image push or pull”. FIG. 3 shows the relationships between the client device, the credential helper, the auth proxy, and the image registry).
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 authentication proxy and obtaining the image from a cloud registry of Cao with the computer system receiving information specifying an application of Raman to create a system that can receive information related to a containerized application and obtain the containerized application securely. A person having ordinary skill in the art would have been motivated to make this combination to improve security and scalability. Cao ¶ [0024] states that “sensitive SSO user credentials (e.g., username and password) are not stored or cached by the client accessing the image registry”. A person of ordinary skill in the art would recognize the security benefits of not storing or caching the user credentials on a client device. For example, by not storing the user credentials on the client device, a malicious actor with access to the client device would not be able to push or pull images to the container registry. Malicious actors would also not be able to steal the user credentials from the client device. Additionally, ¶ [0055] states the “virtualization management server 116, in which SSO service 108 is deployed, is not directly accessible by credential helper 332”. FIG. 3 also shows this separation. A person of ordinary skill in the art would recognize that some software architectures that benefit from having proxy intermediary between the client and authentication service. By keeping them separate, they can scale independently of each other and improve computer resource utilization.
Raman and Cao do not teach the system directly providing the containerized data-driven application to a computer network device.
However, in an analogous art, Parla teaches providing, addressed to the computer network device, the containerized data-driven application and the metadata (Col. 3 Line. 11 states “In some examples, these cloud-delivered workload functions may be container images, virtual machine images, P4-functions (e.g., for SmartNICs), Lambda functions, or the like. In some examples, the cloud-delivered workload functions may be deployed, orchestrated, and operationalized at the edge (e.g., enterprise edge or other edge network) from a central delivery and control point in a cloud-computing network based on policies and/or intents”. Col. 6 Line. 66 through Col. 7 Line. 2 states “the cloud-computing network may include a workload or policy server that is configured to deliver workloads, functions, etc. to the edge device based on decisions made by the controller. For instance, the controller may make a decision to install a workload on the edge device, and the controller may signal to the workload/policy server to deliver the workload to the edge device”).
wherein providing the containerized data-driven application comprises initiating a reconfiguration of the computer network device with the containerized data-driven application, which extends functionality of the computer network device beyond an initial set of predefined functions associated with hardware in the computer network device (Col. 3 Lines 12-17 state “In some examples, these cloud-delivered workload functions may be container images, virtual machine images, P4-functions (e.g., for SmartNICs), Lambda functions, or the like. In some examples, the cloud-delivered workload functions may be deployed, orchestrated, and operationalized at the edge”. Col. 3 Lines 24-27 states “Once deployed, the one or more images and/or functions may be operationalized and configured (e.g., spun-up and provisioned) when needed, as well as spun-down when no longer required at the edge node”. Examiner’s Note: workload functions can include container images. When a workload function is deployed, orchestrated, operationalized, and configured at an edge device, that is the edge device being reconfigured with the containerized data-driven application).
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 deployment of a workload to a computer network device of Parla with the computer system receiving information specifying an application and using an authentication proxy and image registry of Raman and Cao. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of reducing unnecessary costs, such as transit expenses, increasing system bandwidth, and reducing cloud compute resources (Col. 2 Lines. 63 – Col. 3 Line 1 states “in the context of cloud-delivered security solutions, routing a packet all the way to a cloud-computing node simply to drop the packet at a cloud-delivered firewall results in unnecessary costs, such as transit expenses, decreased bandwidth in the flow, and a waste of cloud-delivered compute resources”). The system achieves these benefits by having implementing “technologies that assist with this problem by splitting the control plane and data plane components of cloud-delivered functions (e.g., security functions) to allow them to be operationalized at the edge (e.g., enterprise edge), while maintaining centralized intent, policy, and control” (Col. 3 Lines. 6-11). Further, by applying the specified application and its metadata to a computer network device, the edge device can operationalize the workload’s functions (Parla Col. 5 Line. 27-34 states “the workload image may be installed on the edge device to operationalize the function capability. In some examples, the edge device may be a generic edge device (e.g., a persona-less device) or a specific persona device (e.g., an edge router device, an edge firewall device, etc.), and installing the workload image may transform a persona of the edge device (e.g., from a persona-less device to a specific persona device, from a specific persona device to a multiple persona device, or the like”).
Raman, Cao, and Parla do not explicitly teach a reconfiguration of the computer network device to extend functionality of the device.
However, in an analogous art, Wilson teaches wherein providing the containerized data-driven application comprises initiating a reconfiguration of the computer network device with the containerized data-driven application, which extends functionality of the computer network device beyond an initial set of predefined functions associated with hardware in the computer network device (Col. 3 Line. 6-17 states “the invention provides a software implementation of a virtual device container which virtually represents additional functionality of a network device, as if the additional functionality were embedded in the network device. In this manner, a legacy device can be made to appear to other devices on the network as if the legacy device has the embedded functionality to support new enterprise-wide applications, such as e-mail printing, security applications, network management applications, job tracking applications, resource management applications and the like”).
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 computer network device functionality extension of Wilson with the computer system of Raman, Cao, and Parla. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of adding more functionality to a network device. Wilson explains how this invention particularly applies to extending legacy network devices (Col. 1 Lines. 7-13). The goal of the applicant’s application is to reduce fragmentation and the need for users to purchase additional networking equipment, so Wilson’s teachings aid in solving the same problem. Additionally, Wilson states “a legacy device can be made to appear to other devices on the network as if the legacy device has the embedded functionality to support new enterprise-wide applications, such as e-mail printing, security applications, network management applications, job tracking applications, resource management applications and the like” (Col. 3 Line. 10-16). In doing so, “This transparent virtual extension of the functionality of legacy devices is implemented through object-based modules so that new functions can be added for network devices in a simple and efficient manner” (Col. 3 Lines 16-20). One of ordinary skill in the art recognizes the benefits of extending devices for increased functionality in a simple and efficient manner.
Regarding claim 17, Raman, Cao, Parla, and Wilson teach the method of claim 16. Raman additionally teaches wherein the computer network device comprises: an access point, a gateway (¶ [0008] states “The services manager in the system hierarchy may be between a computer associated with a provider of a third electronic device (such as an IoT device) and a gateway (such as an access point or an eNodeB) that communicates with the third electronic device”).
Raman, Cao, and Wilson do not specifically teach the computer network device comprising a router.
However, in an analogous art, Parla teaches that the computer network device comprises: a router (Col. 2 Line. 21-27 states “a controller of the cloud-computing network may determine that the function capability is to be operationalized on an edge node (e.g., edge router, edge firewall, or other edge device) of the enterprise network”).
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 router of Parla and the access point or gateway of Raman as possible computer network devices. A person having ordinary skill in the art would have motivated to make this combination for the purpose of installing the containerized data-driven application on multiple types of networking equipment that fulfill different roles in a computer network environment.
Regarding claim 18, Raman, Cao, Parla, and Wilson teach the method of claim 16. Raman additionally teaches wherein the metadata specifies resources that the containerized data-driven application is allowed to use on the computer network device (¶ [0008] states “the electronic-device-specific application may be defined by the available system resources, and may be mapped to pools matching the service-level-agreement requested from the configurator (such as a user or an operator) for a given container”. ¶ [0012] states “the configuration parameters for the electronic-device-specific application may be associated with different system resources (such as computational resources, memory, and/or network resources) or priorities in the services manager and/or the system hierarchy”. ¶ [0094] states “A definition may configure the system resources used by the given container to match the requirements needed to satisfy a service level agreement, such as maximum packet latency under traffic of up to a specified number of packets per second”. Examiner’s Note: the definition of the electronic-device-specific application, the service-level-agreement, and the configuration parameters are all interpreted to be metadata).
Regarding claim 19, Raman, Cao, Parla, and Wilson teach the method of claim 16. Raman additionally teaches that wherein the virtual machine comprises an operating system for the containerized data-driven application (¶ [0008] states “the provider-specific or the electronic-device-specific environment may include a virtual operating system in a container in the services manager, and the electronic-device-specific application may be a plugin that executes in the container”).
Raman, Parla, and Wilson do not specifically teach the containerized application executing in a virtual machine.
However, Cao, does teach wherein the containerized data-driven application executes in a virtual machine for the containerized data-driven application (¶ [0001] states “Applications today are deployed onto a combination of virtual machines (VMs), containers, application services, and more”. ¶ [0021] states “Kubernetes pods are implemented as “pod VMs,” each of which includes a kernel and container engine that supports execution of containers”. ¶ [0046] states “Each pod VM 130 has one or more containers 206 running therein in an execution space managed by container engine 208. The lifecycle of containers 206 is managed by pod VM agent 212. Both container engine 208 and pod VM agent 212 execute on top of a kernel”. FIG. 2 displays a pod virtual machine that includes the containers, the container engine, the pod VM agent, and the kernel).
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 containerized application executing within a virtual machine of Cao and the virtual environment including an operating system of Raman resulting in a virtual machine comprising an operating system for the execution of a containerized application. A person having ordinary skill in the art would have been motivated to combine virtual machines and containerization because it enables the use of orchestration platforms. Orchestration platforms are known for “automating deployment, scaling, and operations of application containers across clusters of hosts” and “It offers flexibility in application development and offers several useful tools for scaling” (Cao ¶ [0001]).
Claim(s) 5 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Raman, Cao, Parla, and Wilson in view of Koushik et al. Pub. No. US 20160134616 A1 (hereafter Koushik).
Regarding claim 5, Raman, Cao, Parla, and Wilson teach the computer system of claim 1. Raman additionally teaches wherein the metadata is constrained based at least in part on one or more of: resources of the computer network device (¶ [0008] states “the electronic-device-specific application may be defined by the available system resources, and may be mapped to pools matching the service-level-agreement requested from the configurator (such as a user or an operator) for a given container”. ¶ [0012] states “the configuration parameters for the electronic-device-specific application may be associated with different system resources (such as computational resources, memory, and/or network resources) or priorities in the services manager and/or the system hierarchy”. ¶ [0094] states “A definition may configure the system resources used by the given container to match the requirements needed to satisfy a service level agreement, such as maximum packet latency under traffic of up to a specified number of packets per second”).
Raman, Cao, Parla, and Wilson do not explicitly teach the metadata including applications installed on the computer network device or functions of the computer network device.
However, in an analogous art, Koushik does teach wherein the metadata is constrained based at least in part on one or more of: one or more other applications installed on the computer network device (¶ [0088] - [0090] describe a fulfillment service. ¶ [0089] states “the fulfillment service 620 may maintain a record (e.g., a list) of the intended state of the application fulfillment platform for each user, which may detail the resources (including applications) that are intended to be assigned and/or provided to the end user. Inputs indicating the intended state may be received from the IT administrator (e.g., through service provider system console 616) or from an end user's machine (e.g., from control plane agent 640, through proxy service 628)”. Further, ¶ [0089] states “the control plane agent 640 may be configured to determine whether the current state matches the intended state, and if not, to initiate the taking of corrective action (e.g., initiating the performance of a “create fulfillment” workflow …)”. Examiner’s Note: the “record of the intended state of the application fulfillment platform for each user” is interpreted to be the metadata and it includes a list of applications that are installed or that need to be installed on the end user’s system. That metadata can be used by other services to complete the installation of applications on the end user’s system. The intended state, or metadata, is received by the computer system and received from the IT administrator or the end user’s machine).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the metadata constraint of listing installed applications of Koushik with the computer system of Raman, Cao, Parla, and Wilson for the purpose of creating a system that can be configured with metadata related to the applications installed on each network device. A person having ordinary skill in the art would have motivated to make this combination for the purpose of aiding dynamic resource management. Koushik ¶ [0088] states that the fulfillment service can “receive requests for subscribing to or unsubscribing from applications from end users” and “receive a notification when a new computing resource instance (e.g., a new virtualized computing resource instance and/or virtual desktop instance) is provisioned for an end user”. Additionally, ¶ [0088] states “if (or when) a request is made (e.g., by an IT administrator) to provision or deprovision a computing resource instance (e.g., a virtualized computing resource instance or virtual desktop instance), an end user submits a request to subscribe to or unsubscribe from an application or to install, unstill, or launch an application, or an IT administrator submits a request or command that expresses some other intent, these requests/commands may be passed from the console to the fulfillment service 620 for handling”. Having metadata constrained to the installed applications would aid the user when choosing to subscribe or unsubscribe from applications because users could avoid installing duplicate applications and could be warned if there are not enough available resources to install a new application. Users could do this without intervention or assistance from the IT administrator. Additionally, it is interpreted that having a list of installed applications would aid in the decision to provision or deprovision computer resources to maximize computer resource utilization.
Raman, Cao, Wilson, and Koushik do not teach metadata about the functions of the computer network device.
However, Parla does teach wherein the metadata is constrained based at least in part on one or more of: one or more functions of the computer network device (Col. 9 Line. 58-65 states “the enterprise policy 122 may indicate how certain enterprise network 102 devices are to operate, function(s) 112 that the enterprise devices are to perform, specific personas of the enterprise network devices (e.g., router, firewall, proxy, remote access, etc.), capacity constraints for the enterprise devices, or the like”. Examiner’s Note: the “enterprise policy” is interpreted to be the metadata).
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 metadata constrained to the functions of the computer network device of Parla with the metadata constrained to the computer network device resources and applications installed on the computer resources of Raman, Cao, Wilson, and Koushik. A person having ordinary skill in the art would have been motivated to make this combination in order to inform the computer system of the capabilities of the computer network device. By understanding the capabilities and combined with the computer network device resource information and applications installed, the computer system can accurately determine if the application can execute on the computer network device. Parla Col. 3 Line. 32-38 give an example stating “the images and/or functions may have specific hardware requirements that dictate whether they can be operationalized on particular network components. For example, if one edge device has a graphic processing unit (GPU) and another does not, a workload may be placed on the GPU-enabled edge device if it is required”.
Regarding claim 20, Raman, Cao, Parla, and Wilson teach the method of claim 16. Raman additionally teaches wherein the metadata is constrained based at least in part on one or more of: resources of the computer network device (¶ [0008] states “the electronic-device-specific application may be defined by the available system resources, and may be mapped to pools matching the service-level-agreement requested from the configurator (such as a user or an operator) for a given container”. ¶ [0012] states “the configuration parameters for the electronic-device-specific application may be associated with different system resources (such as computational resources, memory, and/or network resources) or priorities in the services manager and/or the system hierarchy”. ¶ [0094] states “A definition may configure the system resources used by the given container to match the requirements needed to satisfy a service level agreement, such as maximum packet latency under traffic of up to a specified number of packets per second”).
Raman, Cao, Parla, and Wilson do not teach explicitly the metadata including applications installed on the computer network device or functions of the computer network device.
However, in an analogous art, Koushik does teach wherein the metadata is constrained based at least in part on one or more of: one or more other applications installed on the computer network device (¶ [0088] - [0090] describe a fulfillment service. ¶ [0089] states “the fulfillment service 620 may maintain a record (e.g., a list) of the intended state of the application fulfillment platform for each user, which may detail the resources (including applications) that are intended to be assigned and/or provided to the end user. Inputs indicating the intended state may be received from the IT administrator (e.g., through service provider system console 616) or from an end user's machine (e.g., from control plane agent 640, through proxy service 628)”. Further, ¶ [0089] states “the control plane agent 640 may be configured to determine whether the current state matches the intended state, and if not, to initiate the taking of corrective action (e.g., initiating the performance of a “create fulfillment” workflow …)”. Examiner’s Note: the “record of the intended state of the application fulfillment platform for each user” is interpreted to be the metadata and it includes a list of applications that are installed or that need to be installed on the end user’s system. That metadata can be used by other services to complete the installation of applications on the end user’s system. The intended state, or metadata, is received by the computer system and received from the IT administrator or the end user’s machine).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the metadata constraint of listing installed applications of Koushik with the computer system of Raman, Cao, Parla, and Wilson for the purpose of creating a system that can be configured with metadata related to the applications installed on each network device. A person having ordinary skill in the art would have motivated to make this combination for the purpose of aiding dynamic resource management. Koushik ¶ [0088] states that the fulfillment service can “receive requests for subscribing to or unsubscribing from applications from end users” and “receive a notification when a new computing resource instance (e.g., a new virtualized computing resource instance and/or virtual desktop instance) is provisioned for an end user”. Additionally, ¶ [0088] states “if (or when) a request is made (e.g., by an IT administrator) to provision or deprovision a computing resource instance (e.g., a virtualized computing resource instance or virtual desktop instance), an end user submits a request to subscribe to or unsubscribe from an application or to install, unstill, or launch an application, or an IT administrator submits a request or command that expresses some other intent, these requests/commands may be passed from the console to the fulfillment service 620 for handling”. Having metadata constrained to the installed applications would aid the user when choosing to subscribe or unsubscribe from applications because users could avoid installing duplicate applications and could be warned if there are not enough available resources to install a new application. Users could do this without intervention or assistance from the IT administrator. Additionally, it is interpreted that having a list of installed applications would aid in the decision to provision or deprovision computer resources to maximize computer resource utilization.
Raman, Cao, Wilson, and Koushik do not teach metadata about the functions of the computer network device.
However, Parla does teach wherein the metadata is constrained based at least in part on one or more of: one or more functions of the computer network device (Col. 9 Line. 58-65 states “the enterprise policy 122 may indicate how certain enterprise network 102 devices are to operate, function(s) 112 that the enterprise devices are to perform, specific personas of the enterprise network devices (e.g., router, firewall, proxy, remote access, etc.), capacity constraints for the enterprise devices, or the like”. Examiner’s Note: the “enterprise policy” is interpreted to be the metadata).
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 metadata constrained to the functions of the computer network device of Parla with the metadata constrained to the computer network device resources and applications installed on the computer resources of Raman, Cao, Wilson, and Koushik. A person having ordinary skill in the art would have been motivated to make this combination in order to inform the computer system of the capabilities of the computer network device. By understanding the capabilities and combined with the computer network device resource information and applications installed, the computer system can accurately determine if the application can execute on the computer network device. Parla Col. 3 Line. 32-38 give an example stating “the images and/or functions may have specific hardware requirements that dictate whether they can be operationalized on particular network components. For example, if one edge device has a graphic processing unit (GPU) and another does not, a workload may be placed on the GPU-enabled edge device if it is required”.
Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Raman, Cao, Parla, and Wilson in view of Annambhotla Pub. No. US 10470059 B1 (hereafter Annambhotla).
Regarding claim 7, Raman, Cao, Parla, and Wilson teach the computer system of claim 1. Raman and Parla additionally teach wherein the containerized data-driven application comprises: a firewall (Parla Col. 2 Line. 22-27 states “a controller of the cloud-computing network may determine that the function capability is to be operationalized on an edge node (e.g., edge router, edge firewall, or other edge device) of the enterprise network”), an analytics application (Raman ¶ [0081] states “The core functions of the solution (which is sometimes referred to as an ‘IoT gateway’) implemented in access point 200 (FIG. 2) and services manager 300 may include: centralized management (secure onboarding management of IoT devices and gateways), data aggregation (aggregate and transform data from multiple gateways), edge analytics (process data at the edge, i.e., behind the firewall, from multiple gateways”), or another microservice (Raman ¶ [0056] states “the virtual environments in containers 716 may be virtual machines that provide a micro-service for corresponding electronic devices”).
Raman, Cao, Parla, and Wilson do not teach the data-driven application comprising Bluetooth low energy (BLE) monitoring of a BLE tag and a radio resource manager that communicates using a communication protocol.
However, in an analogous art, Annambhotla teaches wherein the containerized data-driven application comprises: Bluetooth low energy (BLE) monitoring of a BLE tag (Col. 16 Line. 27-36 states “network management device 404 manages, among other things, the deployment and re-deployment of the containerized application for the set of wireless access points 402a, 402b, and 402c in providing functions, e.g., for a Zigbee-based thermostat 410a, a Bluetooth low energy (BLE) tagged wheelchair (410b), and a BLE-based heart rate monitor (410c)”. FIG. 4 shows the access point communicating with the BLE tagged apparatus), a radio resource manager that communicates using a communication protocol (Col. 2 Line. 57-66 states “wherein each of the plurality of access points is configured to execute at least one containerized application deployment associated with at least one radio interface (e.g., Bluetooth, ZigBee) and an associated edge computing gateway application to interface with a plurality of end-point computing devices (e.g., a class of end-point computing devices)").
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the Bluetooth low energy (BLE) monitoring of a BLE tag and the radio resource manager of Annambhotla with the firewall, analytics application, and microservice of Raman and Parla for the purpose of creating a containerized data-driven application that can communicate with external devices using radio and provide other services. A person having ordinary skill in the art would have motivated to make this combination for the purpose of allowing access points to “concurrently and simultaneously talk to multiple different wireless technologies such as Bluetooth, ZigBee, 3.5 GHz. CBRS, 900 MHz ISM, etc.” (Annambhotla Col. 20 Line. 43-47). A person of ordinary skill in the art would recognize that the ability for access points to concurrently and simultaneously communicate would increase the access point’s utility because a single access point could serve multiple IoT devices. Additionally, the ability to support a firewall, an analytics application, or another micro-service can provide security, improved insight, and allow the use of other “associated edge-computing application(s) (e.g., a Bluetooth or ZigBee radio application to bridge non-IP traffic, a local building automation/sensor management application, an application to provide real time location information for an indoor drone, etc.)” (Annambhotla Col 20. Line. 50-56).
Response to Arguments
Applicant's arguments filed 02/18/2026 have been fully considered but they are not persuasive. Applicant’s arguments related to 35 U.S.C. 103 are moot.
With regard to applicants’ argument that claims 1, 12, and 16 pass Step 2A Prong 1, applicant states that the amendment added to claims 1, 12, and 16 cannot be practically be performed in the mind. The amendment includes “initiating a reconfiguration of the network device” and extending network device functionality. Therefore, applicant believes that the claims do not recite a judicial exception.
MPEP § 2106.04(a)(III) states “The courts consider a mental process (thinking) that "can be performed in the human mind, or by a human using a pen and paper" to be an abstract idea” and “Accordingly, the "mental processes" abstract idea grouping is defined as concepts performed in the human mind, and examples of mental processes include observations, evaluations, judgments, and opinions”. MPEP § 2106.04(a)(III)(C) states “Claims can recite a mental process even if they are claimed as being performed on a computer”.
The limitations in claims 1, 12, and 16 are understood to be performed in a computer system. As explained by the MPEP, this does not exclude the claim from claiming a mental process. The limitations in applicant’s amendment are not considered to be a mental process but rather they are additional elements of insignificant extra-solution activity of mere data gathering/transmission (MPEP § 2106.05(g)) and field of use/technological environment (MPEP § 2106.05(h)) as explained in the 35 U.S.C. 101 claim rejections. Applicant’s remarks do not address the limitation “performing authentication using an authentication proxy” being a mental process.
Examiner maintains that claims 1, 12, and 16 are directed to a mental process and fail Step 2A Prong 1.
With regard to applicant’s argument that claims 1, 12, and 16 pass Step 2A Prong 2, applicant believes the amendment added to claims 1, 12, and 16 add an improvement to the function of the computer.
MPEP § 2106.05(g) states “The term "extra-solution activity" can be understood as activities incidental to the primary process or product that are merely a nominal or tangential addition to the claim” and that examiner should consider “Whether the limitation amounts to necessary data gathering and outputting, (i.e., all uses of the recited judicial exception require such data gathering or data output)”. MPEP § 2106.05(h) states “limitations that amount to merely indicating a field of use or technological environment in which to apply a judicial exception do not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application”.
The amendment limitation “wherein providing the containerized data-driven application comprises initiating a reconfiguration of the computer network device with the containerized data-driven application” is considered an additional element of insignificant extra-solution activity of mere data gathering/transmission (MPEP § 2106.05(g)). The phrase “providing the containerized data-driven application” is interpreted to include a transfer of data (the application). Additionally, the broadest reasonable interpretation of “initiating a reconfiguration” would simply mean to change how the network device is configured, including what applications are on the network device. This additional element does not integrate the mental process of authentication into a practical application because it is only a post-solution activity incidental to the mental process of authentication.
The amendment limitation of “which extends functionality of the computer network device beyond an initial set of predefined functions associated with hardware in the computer network device” is considered an additional element of field of use/technological environment (MPEP § 2106.05(h)) because the claim limits the idea of extending functionality beyond an initial set of predefined functions to the environment of a computer device. Examiner disagrees that extending the functionality of a computer network device is an improvement to the computer because extending functionality using a containerized application is simply adding a software function to a computer. It does not improve how the computer performs tasks. Instead, installing containerized applications to extend functionality makes use of the existing hardware. The computer network device itself was capable of executing the application before the reconfiguration using a containerized application. It is similar to how installing an app from an app store onto a smartphone does not improve the smartphone itself. The smartphone was capable of executing the app before the user decided to install the application.
Examiner maintains that claims 1, 12, and 16 do not integrate the judicial exception into a practical application and fail Step 2A Prong 2.
With regard to applicant’s arguments that claims 1, 12, and 16 pass Step 2B, applicant argues that limitations in the amendment improve the computer network device and that is an inventive concept that qualifies as significantly more.
MPEP § 2106.05(d) states “If, however, the additional element (or combination of elements) is no more than well-understood, routine, conventional activities previously known to the industry, which is recited at a high level of generality, then this consideration does not favor eligibility”. MPEP § 2106.05(d)(II) lists that “Receiving or transmitting data over a network” is a well-understood, routine, and conventional activity.
Examiner reevaluates the limitations in combination with each other. The computer components in claims 1, 12, and 16 are generic and do not add anything that was not already present when examining the limitations separately. Limiting the scope of the invention and idea of extending functionality beyond an initial set of predefined functions to configuration of a computer network device is not an inventive concept that is significantly more because limiting an idea to a specific technological environment cannot add something significantly more to the judicial exception and cannot add an improvement to the functioning of a computer. When reevaluating the limitations of receiving first and second data, obtaining the application, and providing the application to the computer network device, examiner finds all of these insignificant extra-solution activities of data gathering/transmission to be well-understood, routine, and conventional activities because they all fall within “Receiving or transmitting data over a network” (MPEP § 2106.05(d)(II)). The terms “receiving”, “obtaining”, and “providing” indicate a transmission of data. Examiner disagrees that the amendment limitation adds an improvement to the functioning of the computer because reconfiguring a computer network device with a containerized application does not improve the computer network device itself. The computer network device was capable of executing the application before the reconfiguration. See examiner’s response to applicant arguments against Step 2A Prong 2 above for more explanation.
Since the examiner found that the generic computing components and field of use/technological environment did not add anything significantly more or an improvement to the functioning of a computer and the insignificant extra-solution activities of mere data gathering/transmission did not disclose of anything other than what is well-understood, routine, and conventional, examiner concludes that the limitations in claims 1, 12, and 16, alone or in combination, do not contain an inventive concept that is significantly more. Examiner maintains that claims 1, 12, and 16 fail Step 2B. Therefore, examiner maintains that claims 1, 12, and 16 do not recite patent eligible matter under 35 U.S.C. § 101.
With regard to applicant’s arguments that Raman, Cao, Parla, and Wilson do not teach the amendment in claims 1, 12, and 16, applicant argues Wilson does not teach the network device being reconfigured itself.
Examiner has fully considered applicant’s arguments. However, examiner finds applicant’s arguments moot because examiner relies on Parla to teach initiating a reconfiguration of the computer network device. Parla teaches deploying, orchestrating, operationalizing, and configuring a workload function, or a container image, at an edge device (Col. 3 Lines 12-17 and 24-27). By deploying, orchestrating, operationalizing, and configuring the container image at the edge device, the edge device has been reconfigured. Therefore, Parla teaches the “reconfiguration of the computer network device”. See 103 claim rejections for more details. The network device taught by Wilson is a legacy device that cannot execute new enterprise applications (Col. 2 Lines 7-13). This legacy device of Wilson has the “initial set of predefined functions associated with hardware in the computer network device”. To solve this, Wilson teaches “an open, object-oriented architecture which virtually extends the functionality of a network device, particularly a legacy network device” (Col. 3 Lines 4-6). This idea is implemented using “a virtual device container which virtually represents additional functionality of a network device” (Col. 3 Lines 7-9). As a result of Wilson’s teachings, “a legacy device can be made to appear to other devices on the network as if the legacy device has the embedded functionality to support new enterprise-wide applications” (Col. 3. Lines 10-13). Clearly, a legacy network device’s functionality is extended to support previously unsupported functionality. The combination of Parla and Wilson would result in a system where a container image is deployed, orchestrated, operationalized, and configured on an edge device (thereby reconfiguring the edge device) such that the edge device is extended with new functionality. One of ordinary skill in the art would have been motivated to make this combination so that “new functions can be added for network devices in a simple and efficient manner” (Wilson Col. 3 Lines 16-20).
Examiner finds that Raman, Cao, Parla, and Wilson teach the claim amendment. Therefore, examiner maintains rejection of claims 1-8 and 9-20 under 35 U.S.C. 103.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20140331297 A1
teaches
Secured Access to Resources Using a Proxy
US 11171842 B2
teaches
Microservices Application Network Control Plane
US 20180316725 A1
teaches
Secure and Policy-Driven Computing for Fog Node Applications
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 PETER L YUAN whose telephone number is (571)272-5737. 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.
/PETER LI YUAN/Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197