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 .
The Office Action is in response to claims filed 06/26/2026.
Claims 1-8 and 10-20 are pending.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 06/26/2026 has been entered.
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)). Claims 1, 12, and 16 additionally recite “the authentication proxy being a cloud-based service that is configured to receive the metadata associated with the containerized data-driven application.” This limitation is also considered field of use/technological environment (MPEP § 2106.05(h)) because it limits the authentication proxy to a cloud-based service. These fields 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 by downloading the containerized data-driven application via the authentication proxy”, “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 installed on the computer network device”. These limitations are insignificant extra-solution activities (MPEP § 2106.05(g)). 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 by downloading the containerized data-driven application via the authentication proxy”, “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 installed on the computer network device” 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, the authentication proxy being a cloud-based service that is configured to receive the metadata associated with the containerized data-driven application (¶ [0038] states “Virtualization management server 116 manages objects, such as data centers, clusters, hosts, VMs, resource pools, datastores, and the like.” ¶ [0036] states “Specific services (e.g., registry auth service 306, auth proxy 322) are referred to in the specific embodiments described herein.” ¶ [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.” Examiner’s Note: the auth proxy receives credentials and a session token during the authentication process. Credentials and the session token are metadata associated with the containerized data-driven application);
obtaining, in a cloud-based registry of containerized data-driven applications, the containerized data-driven application by downloading the containerized data-driven application via the authentication proxy (¶ [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. Examiner’s Note: during an image pull, or download process, the Docker client must authenticate with the auth proxy. The auth proxy returns a bearer token to the Docker client. When the Docker client uses the bearer token to download the image, the downloading of the image has occurred via the auth proxy).
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 installed on the computer network device, 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”. Col. 10 Lines 22-26 states “At “3,” the controller 116 may send the workload image 124 (or multiple workload images) to the edge device 106 of the enterprise network 102. In this way, the edge device 106 may install the workload image 124 to operationalize one or more function(s) 112.” 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 installed on the edge device).
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 installed on the computer network device, 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, the authentication proxy being a cloud based service that is configured to receive the metadata associated with the containerized data-driven application (¶ [0038] states “Virtualization management server 116 manages objects, such as data centers, clusters, hosts, VMs, resource pools, datastores, and the like.” ¶ [0036] states “Specific services (e.g., registry auth service 306, auth proxy 322) are referred to in the specific embodiments described herein.” ¶ [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.” Examiner’s Note: the auth proxy receives credentials and a session token during the authentication process. Credentials and the session token are metadata associated with the containerized data-driven application);
obtaining, in a cloud-based registry of containerized data-driven applications, the containerized data-driven application by downloading the containerized data-driven application via the authentication proxy (¶ [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. Examiner’s Note: during an image pull, or download process, the Docker client must authenticate with the auth proxy. The auth proxy returns a bearer token to the Docker client. When the Docker client uses the bearer token to download the image, the downloading of the image has occurred via the auth proxy).
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 installed on the computer network device, 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”. Col. 10 Lines 22-26 states “At “3,” the controller 116 may send the workload image 124 (or multiple workload images) to the edge device 106 of the enterprise network 102. In this way, the edge device 106 may install the workload image 124 to operationalize one or more function(s) 112.” 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 installed on the edge device).
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 installed on the computer network device, 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, the authentication proxy being a cloud-based service that is configured to receive the metadata associated with the containerized data-driven application (¶ [0038] states “Virtualization management server 116 manages objects, such as data centers, clusters, hosts, VMs, resource pools, datastores, and the like.” ¶ [0036] states “Specific services (e.g., registry auth service 306, auth proxy 322) are referred to in the specific embodiments described herein.” ¶ [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.” Examiner’s Note: the auth proxy receives credentials and a session token during the authentication process. Credentials and the session token are metadata associated with the containerized data-driven application):
obtaining, in a cloud-based registry of containerized data-driven applications, the containerized data-driven application by downloading 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. Examiner’s Note: during an image pull, or download process, the Docker client must authenticate with the auth proxy. The auth proxy returns a bearer token to the Docker client. When the Docker client uses the bearer token to download the image, the downloading of the image has occurred via the auth proxy).
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 installed on the computer network device, 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”. Col. 10 Lines 22-26 states “At “3,” the controller 116 may send the workload image 124 (or multiple workload images) to the edge device 106 of the enterprise network 102. In this way, the edge device 106 may install the workload image 124 to operationalize one or more function(s) 112.” 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 installed on the edge device).
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 installed on the computer network device, 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 06/26/2026 have been fully considered but they are not persuasive.
With regard to the 35 U.S.C. § 101 rejection of claims 1-8 and 9-20, applicant argues the amendments to claim 1, 12, and 16 show that the claims do not recite a mental process. Specifically, applicant states “a cloud-based authentication service that performs authentication, is configured to receive the metadata associated with the containerized data-driven application, and that downloads the containerized data-driven application are operations that cannot be performed in the human mind” (Page 4).
Examiner respectfully disagrees. The amendment “the authentication proxy being a cloud-based service that is configured to receive the metadata associated with the containerized application data-driven application” was analyzed as field of use/technological environment (MPEP § 2106.05(h)). The amendment “by downloading the containerized data-driven application via the authentication proxy” and “installed on the computer network device” were analyzed as insignificant extra-solution activity of data gathering (MPEP § 2106.05(g)). These amendments do not cause the mental process of authentication to no longer be a mental process. According to MPEP § 2106.04(a)(III)(C), mental processes can be performed on computers and within computer environments. Therefore, additional elements stating that authentication proxy is a cloud based service, the authentication proxy aids in downloading the containerized data-driven application, and the application is installed on the computer network device do not cause authentication to no longer be a mental process. Authentication is a mental process because it is an observation of an input and then forming a determination that the input is valid.
Examiner maintains that claims 1-8 and 10-20 recite a mental process and fail Step 2A Prong 1 under the framework provided in the 2019 Patent Eligibility Guidance.
Applicant further argues that claims 1, 12, and 16 integrate the judicial exception into a practical application. Applicant states “extending the functionality of the computer network device beyond an initial set of predefined functions improves the operation of the computer network device” (Page 6).
Examiner respectfully disagrees. As explained the 35 U.S.C. § 101 rejection of claims 1, 12, and 16, the limitation “wherein providing the containerized data-driven application comprises initiation a reconfiguration of the computer network device with the container data-driven application installed on the computer network device” is an insignificant extra-solution activity of data transmission (MPEP § 2106.05(g)). It is a post-solution activity that is incidental to the judicial exception. The limitation “which extends functionality of the computer network device beyond an initial set of predefined functions associated with hardware in the computer network device” is field of use/technological environment (MPEP § 2106.05(h)) because it limits the application to functionality that extends the computer network device. In other words, it limits the field of use to applications that have more functionality than the computer network device. These additional elements do not show an improvement to technology and do not integrate the judicial exception into a practical application.
The limitation “wherein providing the containerized data-driven application comprises initiating a reconfiguration of the computer network device with the containerized data-driven application installed on the computer network device, which extends functionality of the computer network device beyond an initial set of predefined functions associated with hardware in the computer network device” does not show an improvement to the functioning of a computer. Reconfiguring the computer network device with a containerized application installed on the computer network device does not improve the computer device itself. The computer network device had the capability to execute the application before and after reconfiguration because it is the same computer network device before and after the reconfiguration. It is similar to how installing an application from an app store on a mobile device does not improve the mobile device itself. The mobile device was capable of executing the application before installing the app. The mobile device is still the same device before and after installing an app. Therefore, these additional elements are not improvements to technology.
Examiner maintains that claims 1-8 and 10-20 do not integrate the judicial exception into a practical application and fail Step 2A Prong 2 under the framework provided in the 2019 Patent Eligibility Guidance.
Applicant further argues that claims 1, 12, and 16 improve the functioning of a computer and therefore qualifies as significantly more. Applicant asserts that “extending the functionality of the computer network device beyond an initial set of predefined functions improves the functioning of the computer network device” (Page 7).
Examiner respectfully disagrees. The limitation “wherein providing the containerized data-driven application comprises initiating a reconfiguration of the computer network device with the containerized data-driven application installed on the computer network device” was analyzed as insignificant extra-solution activity of data transmission because it is incidental to the judicial exception. As explained in the 35 U.S.C. § 101 rejection of claims 1, 12, and 16, this limitation is well-understood, routine, and conventional because MPEP § 2106.05(d)(II) lists that “Receiving or transmitting data over a network” is a well understood, routine, and conventional computer function. Therefore, this limitation does not show an improvement to technology and does not amount to an inventive that is significantly more.
The limitation “which extends functionality of the computer network device beyond an initial set of predefined functions associated with hardware in the computer network device” was analyzed as field of use/technological environment (MPEP § 2106.05(h)) because it limits the application to functionality that extends the computer network device. When reexamining this additional element in combination with other limitations, no inventive concept that is significantly more was found because limiting the application to functionality that extends the computer network device in the context of the other claim limitations cannot improve a device. Further, as explained in the examiner’s response to argument that claims 1, 12, and 16 integrate the judicial exception into a practical application, reconfiguring a device with a containerized application installation does not show an improvement to the device itself because the device was capable of performing the application before installing the application.
When reexamining the other additional elements of means to apply an exception and field of use/technological environment in combination with other limitations, no inventive concept that is significantly more was found. Therefore, the claims do not contain an inventive concept that amounts to significantly more.
Examiner maintains that claims 1-8 and 9-20 do not contain an inventive concept that amounts to significantly more and fail Step 2B under the framework provided in the 2019 Patent Eligibility Guidance. Examiner maintains the 35 U.S.C. § 101 rejection of claims 1-8 and 9-20.
With regard to the 35 U.S.C. § 103 rejection of claims 1-8 and 10-20, applicant argues that Wilson does not teach that the legacy network device is reconfigured by installing the containerized data-driven application.
Examiner respectfully disagrees. The 35 U.S.C. § 103 rejection of independent claims 1, 12, and 16 does not solely rely upon Wilson to teach the claim limitations. Rather, it is the combination of Raman, Cao, Parla, and Wilson that teaches the claim limitations.
Parla 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” and Col. 10 Lines 22-26 states “At “3,” the controller 116 may send the workload image 124 (or multiple workload images) to the edge device 106 of the enterprise network 102. In this way, the edge device 106 may install the workload image 124 to operationalize one or more function(s) 112.” From these quotations, the edge device has been reconfigured by installing, configuring, and operationalizing the workload image.
Wilson 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.” From this quotation, Wilson teaches extending a legacy device’s functionality.
In the combination, Wilson’s extension of functionality to a legacy device is applied to Parla’s edge device that a workload image is installed to. As a result, the workload image that is installed to the edge device extends the functionality of the edge device. Wilson does not need to explicitly teach that the legacy network device is reconfigured with an application installation because Parla supplies this teaching. As explained in the 35 U.S.C. § 103 rejection of independent claims 1, 12, and 16, it would have been obvious to a person having ordinary skill in the art to combine these references to extend functionality of legacy devices in a simple and efficient manner (Col. 3 Lines 16-20 states “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”).
Examiner maintains the 35 U.S.C. § 103 rejection of independent claims 1, 12, and 16 and dependent claims 2-8, 13-15, and 17-20.
Regarding the limitation “obtaining, in a cloud-based registry of containerized data-driven applications, the containerized data-driven application by downloading the containerized data-driven application via the authentication proxy,” examiner interpreted this limitation under its broadest reasonable interpretation (BRI) in light of the specification. The BRI of this claim limitation is that the authentication proxy is used in the download process. It does not require that data move through the authentication proxy. For the sake of compact prosecution, if the claim limitation were to be amended in a way where the BRI would require the data pass through the authentication proxy, Pat. No. US 20180054438 A1 in the table of pertinent but uncited references would be used to reject this amendment (see at least ¶ [0004]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20180054438 A1
teaches
PROXY SERVICE FOR UPLOADING DATA FROM A SOURCE TO A DESTINATION
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
