Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
The office action is a response to application filed on 11/13/2024. Wherein claims 1-20 are pending and ready for examination.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-20 and are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. US12169732B2. The instant claims are being anticipated by the patented application. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims in the patent disclose the limitations in the instant application as follows:
Instant Application
US12169732B2
Claim 1
A method comprising
identifying a container record stored in a container responsive to an ended virtual private network (VPN) session;
performing an exit operation to unload use of the container, wherein the exit operation is performed by a container parent process which terminates one or more other container processes;
updating the container record to an available status;
assigning the container to a new session with a client device and a VPN server; and
responsive to assigning the container to the new session, initiating one or more new container processes with the container and maintaining the container parent process.
Claim 1
A method comprising
determining during an audit operation a status of a container has changed from an actively assigned session to available based on an ended session being detected, wherein the container is identified as being in a dormant state and having a plurality of previously active session dependent processes which are currently cancelled and one or more active parent processes;
modifying the status of the container and maintaining the one or more active parent processes in an active status of the container, wherein the modifying the status of the container comprises updating a container state file to include a session identifier identifying the available operational status;
receiving a token from a client device to establish a communication session with a virtual machine;
assigning the client device to the container;
updating the container state file to include a client device identifier; and
responsive to assigning the client device, initiating one or more new container processes with the container and maintaining the one or more active parent processes.
2. The method of claim 1, comprising
receiving a token from the client device to establish the new session.
1. receiving a token from a client device to establish a communication session with a virtual machine;
3. The method of claim 1, comprising writing an exit time and session identifier to a container file after the container is unloaded.
1. determining during an audit operation a status of a container has changed from an actively assigned session to available based on an ended session being detected, wherein the container is identified as being in a dormant state and having a plurality of previously active session dependent processes which are currently cancelled and one or more active parent processes;
4. The method of claim 1, comprising determining during an audit operation a status of the container has changed from an actively assigned session to available based on a detected ended session, wherein the container is identified as being in a dormant state and having a plurality of previously active processes which are currently cancelled.
1. determining during an audit operation a status of a container has changed from an actively assigned session to available based on an ended session being detected, wherein the container is identified as being in a dormant state and having a plurality of previously active session dependent processes which are currently cancelled and one or more active parent processes;
5. The method of claim 1, comprising responsive to updating the container record, removing a previously assigned log file and the container processes which were operating with the container.
2. The method of claim 1, comprising
responsive to modifying a status of the container, removing a previously assigned file system, the log file and one or more processes which were operating with the container.
6. The method of claim 1, comprising responsive to assigning the client device to the container, loading a file system associated with an application of the client device.
3. The method of claim 1, comprising
responsive to assigning the client device to the container, loading a file system associated with an application of the client device.
7. The method of claim 1, wherein the container parent process maintains a firewall process, a port range of assigned ports assigned to the container, and a virtual network adapter.
4. The method of claim 1, wherein the maintaining active parent processes already operating in an active status comprises maintaining a firewall process, a port range of assigned ports assigned to the container, and a virtual network adapter.
8. The method of claim 1, wherein updating the container record to an available status after the session has ended comprises removing a TCP proxy process and a DNS server process from the container.
5. The method of claim 1, wherein modifying the status of the container after the communication session has ended comprises removing a TCP proxy process and a DNS server process from the container.
9. An apparatus comprising: a processor configured to identify a container record stored in a container responsive to an ended virtual private network (VPN) session;
perform an exit operation to unload use of the container, wherein the exit operation is performed by a container parent process which terminates one or more other container processes;
update the container record to an available status;
assign the container to a new session with a client device and a VPN server; and
responsive to assignment of the container to the new session, initiate one or more new container processes with the container and maintain the container parent process.
7. An apparatus comprising:
a processor configured to
determine during an audit operation an operational status of a container has changed from an actively assigned session to available based on an ended session being detected, wherein the container is identified as being in a dormant state and having a plurality of previously active session dependent processes which are currently cancelled and one or more active parent processes;
modify the status of the container and maintain the one or more active parent processes in an active status of the container, wherein the modifying the status of the container comprises updating a container state file to include a session identifier identifying the available operational status; and
a receiver configured to receive a token from a client device to establish a communication session with a virtual machine;
wherein the processor is further configured to
assign the client device to the container;
update the container state file to include a client device identifier; and
responsive to the client device being assigned, initiate one or more new container processes with the container and maintain the one or more active parent processes.
10. The apparatus of claim 9, wherein the processor is further configured to receive a token from the client device to establish the new session.
1. receiving a token from a client device to establish a communication session with a virtual machine;
11. The apparatus of claim 9, wherein the processor is further configured to write an exit time and session identifier to a container file after the container is unloaded.
1. determining during an audit operation a status of a container has changed from an actively assigned session to available based on an ended session being detected, wherein the container is identified as being in a dormant state and having a plurality of previously active session dependent processes which are currently cancelled and one or more active parent processes;
12. The apparatus of claim 9, wherein the processor is further configured to determine during an audit operation a status of the container has changed from an actively assigned session to available based on a detected ended session, wherein the container is identified as being in a dormant state and having a plurality of previously active processes which are currently cancelled
1. determining during an audit operation a status of a container has changed from an actively assigned session to available based on an ended session being detected, wherein the container is identified as being in a dormant state and having a plurality of previously active session dependent processes which are currently cancelled and one or more active parent processes;
13. The apparatus of claim 9, wherein the processor is further configured to, responsive to the container record being updated, remove a previously assigned log file and the container processes which were operating with the container.
2. The method of claim 1, comprising responsive to modifying a status of the container, removing a previously assigned file system, the log file and one or more processes which were operating with the container.
14. The apparatus of claim 9, wherein the processor is further configured to, responsive to the client device being assigned to the container, load a file system associated with an application of the client device.
9. The apparatus of claim 7, wherein the processor is further configured to responsive to the client device being assigned to the container, load a file system associated with an application of the client device.
15. The apparatus of claim 9, wherein the container parent process maintains a firewall process, a port range of assigned ports assigned to the container, and a virtual network adapter.
4. The method of claim 1, wherein the maintaining active parent processes already operating in an active status comprises maintaining a firewall process, a port range of assigned ports assigned to the container, and a virtual network adapter.
16. The apparatus of claim 9, wherein the update of the container record to an available status after the session has ended comprises removal of a TCP proxy process and a DNS server process from the container.
5. The method of claim 1, wherein modifying the status of the container after the communication session has ended comprises removing a TCP proxy process and a DNS server process from the container.
17. A non-transitory computer readable storage medium configured to store instructions that when executed cause a processor to perform:
identifying a container record stored in a container responsive to an ended virtual private network (VPN) session;
performing an exit operation to unload use of the container, wherein the exit operation is performed by a container parent process which terminates one or more other container processes;
updating the container record to an available status;
assigning the container to a new session with a client device and a VPN server; and
responsive to assigning the container to the new session, initiating one or more new container processes with the container and maintaining the container parent process.
13. A non-transitory computer readable medium configured to store instructions that when executed causes a processor to perform:
determining during an audit operation a status of a container has changed from an actively assigned session to available based on an ended session being detected, wherein the container is identified as being in a dormant state and having a plurality of previously active session dependent processes which are currently cancelled and one or more active parent processes;
modifying the status of the container and maintaining the one or more active parent processes in an active status of the container, wherein the modifying the status of the container comprises updating a container state file to include a session identifier identifying the available operational status;
receiving a token from a client device to establish a communication session with a virtual machine;
assigning the client device to the container;
updating the container state file to include a client device identifier; and
responsive to assigning the client device, initiating one or more new container processes with the container and maintaining the one or more active parent processes.
18. The non-transitory computer readable storage of claim 17, wherein processor is further configured to perform:
receiving a token from the client device to establish the new session.
1. receiving a token from a client device to establish a communication session with a virtual machine;
19. The non-transitory computer readable storage of claim 17, wherein processor is further configured to perform:
writing an exit time and session identifier to a container file after the container is unloaded.
1. determining during an audit operation a status of a container has changed from an actively assigned session to available based on an ended session being detected, wherein the container is identified as being in a dormant state and having a plurality of previously active session dependent processes which are currently cancelled and one or more active parent processes;
20. The non-transitory computer readable storage of claim 17, wherein processor is further configured to perform:
determining during an audit operation a status of the container has changed from an actively assigned session to available based on a detected ended session, wherein the container is identified as being in a dormant state and having a plurality of previously active processes which are currently cancelled.
1. determining during an audit operation a status of a container has changed from an actively assigned session to available based on an ended session being detected, wherein the container is identified as being in a dormant state and having a plurality of previously active session dependent processes which are currently cancelled and one or more active parent processes;
2. “A later patent claim is not patentably distinct from an earlier patent claim if the later claim obvious over, or anticipated by, the earlier claim. In re Longi, 759 F.2d at 896, 225 USPQ at 651 (affirming a holding of obviousness-type double patenting because the claims at issue were obvious over claims in four prior art patents); In re Berg, 140 F.3d at 1437, 46 USPQ2d at 1233 (Fed. Cir. 1998) (affirming a holding obviousness-type double patenting where a patent application claim to a genus is anticipated by a patent claim to a species within that genus)”. ELI LILLY AND COMPANY vs. BARR LABORATORIES INC., United States Court of Appeals for the Federal Circuit, ON PETITION FOR REHEARING EN BANC (DECIDED: May 30, 2001).
This is a non-provisional obviousness-type double patenting rejection because the conflicting claims have not in fact been patented.
3. Thus, this double patenting rejection is necessary to prevent unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees.
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 of this title, 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.
1. Claim(s) 1, 4-6, 9, 12-14, 17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Fichtenholtz (US20210026703 A1) in view of Zengerle (US 20210286640 A1).
With respect to independent claims:
Regarding claim(s) 1, a method comprising
Fichtenholtz teaches identifying a container record stored in a container responsive to an ended virtual private network (VPN) session; (Fichtenholtz, [0063], FIG. 10; network(s) 1010 in distributed system 1000 may be any type of network familiar to those skilled in the art that can support data communications using any of a variety of commercially-available protocols. Network(s) 1010 can be a wide-area network and the Internet. It can include a virtual network, including without limitation a virtual private network (VPN). [0044] After sitting idle for a predetermined time interval (if the container is determined sitting idle for a predetermined time interval means that ended session being detected), the container can be unassigned or unbound in state 610(the container is available). When a container is no longer bound to a particular tenant, the internal configuration, application, and/or runtime state can be flushed. In some embodiments, an unbound container does not need to flush its internal contents until it is reassigned to a new tenant. If the container is not assigned to a new tenant, then the container can be removed in state 612.)
updating the container record to an available status; (Fichtenholtz, [0044], Fig.1-2; the data store 112 also maintains the service registry 214 that monitors the state of the container pool at any time (audit operation). The data store 112 uses this service registry 214 to communicate with the routers 106 to determine when the pool of available containers should grow and/or shrink. [0046], Fig.6A; State 606 is referred to as active because the container may be actively servicing requests received from the routers 106. In state 608, the container may still be bound or assigned to the particular tenant, but is passive, in that it is not actively processing any requests with its internally stored configuration. After sitting idle for a predetermined time interval (if the container is determined sitting idle for a predetermined time interval means that ended session being detected), the container can be unassigned or unbound in state 610(the container is available). When a container is no longer bound to a particular tenant, the internal configuration, application, and/or runtime state can be flushed. In some embodiments, an unbound container does not need to flush its internal contents until it is reassigned to a new tenant. If the container is not assigned to a new tenant, then the container can be removed in state 612.)
assigning the container to a new session with a client device and a VPN server; (Fichtenholtz, [0042], FIG.4; after all the requests have been processed and the responses (if any) have been sent back to the requesting client devices, the container 108-3 can become idle, or passive. While the container 108-3 is still assigned or bound to the specific tenant, it is not currently being used to process any requests. After predetermined time interval, the container 108-3 can be unassigned from that particular tenant and placed back into the pool of available containers 108-3 awaiting assignment to a new tenant with new configurations. [0046] FIG. 6A illustrates a state diagram of the lifecycle of a container in the multi-tenant environment, according to some embodiments. At an initial state 602, the container does not exist. At state 604, the container has been instantiated with the set of processes described above (e.g., web server, endpoint, etc.), but the container is unbound or unassigned to a particular tenant and empty. [0063] It can include a virtual network, including without limitation a virtual private network (VPN).)
Fichtenholtz does not teach performing an exit operation to unload use of the container, wherein the exit operation is performed by a container parent process which terminates one or more other container processes; and responsive to assigning the container to the new session, initiating one or more new container processes with the container and maintaining the container parent process.
Zengerle however in the same field of computer networking teaches performing an exit operation to unload use of the container, wherein the exit operation is
performed by a container parent process which terminates one or more other container processes; (Zengerle, (Zengerle, [0030], FIG.1A-1D; when executing steps 108 and 112, an orchestrator command is used, as shown in line 4 of the listing 170 in FIG. 1C. A CMD command 172 executes an orchestrator command 174 (rather than directly executing the application). The orchestrator command 174 is a proxy command that wraps execution (both initial and restart) of an application process. The orchestrator command 174, when executed as a main process for the container, initiates execution of a python command 176 with an application reference 178 as a parameter. Execution of the python command 176 results in execution of the application (microservice), as a new sub process of the orchestrator command 174. Indirect execution of the application can provide a benefit of the orchestrator command 174 continuing to run even when application binaries or executables are updated. If a current application process is ended when switching to a new application process, the container is maintained because the orchestrator process is running as the main container process, instead of an application process. From 112, method 100 proceeds to 116. [0050], FIG.2; at 214, the old process is killed. The killing of the old process does not result in termination of the container, since the old process is a child process of the main orchestrator process and is not itself the main container process. From 214, method 200 returns to 206, for continued listening for binary changes. If a stopping condition is detected, method 200 can stop.)
and responsive to assigning the container to the new session, initiating one or more new container processes with the container and maintaining the container parent process. (Zengerle, (Zengerle, [0030], FIG.1A-1D; when executing steps 108 and 112, an orchestrator command is used, as shown in line 4 of the listing 170 in FIG. 1C. A CMD command 172 executes an orchestrator command 174 (rather than directly executing the application). The orchestrator command 174 is a proxy command that wraps execution (both initial and restart) of an application process. The orchestrator command 174, when executed as a main process for the container, initiates execution of a python command 176 with an application reference 178 as a parameter. Execution of the python command 176 results in execution of the application (microservice), as a new sub process of the orchestrator command 174. Indirect execution of the application can provide a benefit of the orchestrator command 174 continuing to run even when application binaries or executables are updated. If a current application process is ended when switching to a new application process, the container is maintained because the orchestrator process is running as the main container process, instead of an application process. From 112, method 100 proceeds to 116. [0050], FIG.2; at 214, the old process is killed. The killing of the old process does not result in termination of the container, since the old process is a child process of the main orchestrator process and is not itself the main container process. From 214, method 200 returns to 206, for continued listening for binary changes. If a stopping condition is detected, method 200 can stop.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Fichtenholtz by incorporating the teachings of Zengerle. The motivation/suggestion would have been because there is a need to a reduce integration test steps can occur when testing a new deployment of a microservice (Zengerle, [0004]).
Claim(s) 9 and 17 is/are substantially similar to claim 1, and is thus rejected under substantially the same rationale.
With respect to dependent claims:
Regarding claim(s) 4, the method of claim 1,
Fichtenholtz-Zengerle teach comprising determining during an audit operation a status of the container has changed from an actively assigned session to available based on a detected ended session, (Fichtenholtz, [0044], Fig.1-2; The data store 112 also maintains the service registry 214 that monitors the state of the container pool at any time (audit operation). The data store 112 uses this service registry 214 to communicate with the routers 106 to determine when the pool of available containers should grow and/or shrink. [0046], Fig.6A; State 606 is referred to as active because the container may be actively servicing requests received from the routers 106. In state 608, the container may still be bound or assigned to the particular tenant, but is passive, in that it is not actively processing any requests with its internally stored configuration. After sitting idle for a predetermined time interval (if the container is determined sitting idle for a predetermined time interval means that ended session being detected), the container can be unassigned or unbound in state 610(the container is available). When a container is no longer bound to a particular tenant, the internal configuration, application, and/or runtime state can be flushed. In some embodiments, an unbound container does not need to flush its internal contents until it is reassigned to a new tenant. If the container is not assigned to a new tenant, then the container can be removed in state 612.) wherein the container is identified as being in a dormant state and having a plurality of previously active processes which are currently cancelled. (Fichtenholtz, [0026] When a container is flushed and reassigned to a different tenant, runtime information that needs to be saved in the container can be sent back to the data store 112. This ensures that the next time that specific application or API is instantiated in an empty container, the runtime information can be transferred and used by the new container to continue execution where it left off. [0044], FIG. 5 illustrates a simplified block diagram of a container 108-3 being placed back (modified from an active status to an available status) into the pool of available containers, according to some embodiments. After the runtime state information 302 is transferred back to the data store 112, the container 108-3 can be flushed of the configuration 202, the application 204, and/or the runtime state 302. The empty container 108-3 can now be reassigned by the router 106 to a different tenant to service a different API call. [0042] FIG. 4 illustrates how the populated container 108-3 can service the request, according to some embodiments. The container 108-3 can service any requests for this tenant for the API defined by the configuration 202. In some cases, this may include only processing the single request that caused the configuration 202 to be transferred to the container 108-3. In other cases, this may include processing a plurality of similar requests sent to the routers 106 for the same tenant. After all the requests have been processed and the responses (if any) have been sent back to the requesting client devices, the container 108-3 can become idle, or passive. While the container 108-3 is still assigned or bound to the specific tenant, it is not currently being used to process any requests. After predetermined time interval, the container 108-3 can be unassigned from that particular tenant and placed back into the pool of available containers 108-3 awaiting assignment to a new tenant with new configurations. [0043] Before the container 108-3 is flushed and reassigned to a different tenant, any runtime state information 302 that was generated or updated by the application 204 running on the container 108-3 can be saved in the data store 112. The runtime state information 302 can then be transmitted to a different container when the configuration 202 and/or application 204 is reassigned to a new container to service future requests. [examiner notes: inactive, Idle, passive or sleeping etc. state interprets to be a dormant state.])
Regarding claim(s) 5, the method of claim 1,
Fichtenholtz-Zengerle teach comprising responsive to updating the container record, removing a previously assigned log file and the container processes which were operating with the container. (Fichtenholtz, [0026], once the containerized service handles the request and (if necessary) returns a response to the client device, the containerized service can be either reused to service additional requests for that specific tenant/service combination, or the container can be flushed of its contents can be made available to other tenants. When a container is flushed and reassigned to a different tenant, runtime information that needs to be saved in the container can be sent back to the data store 112. This ensures that the next time that specific application or API is instantiated in an empty container, the runtime information can be transferred and used by the new container to continue execution where it left off. [0044], FIG. 5 illustrates a simplified block diagram of a container 108-3 being placed back (modified from an active status to an available status) into the pool of available containers, according to some embodiments. After the runtime state information 302 is transferred back to the data store 112, the container 108-3 can be flushed of the configuration 202, the application 204, and/or the runtime state 302. The empty container 108-3 can now be reassigned by the router 106 to a different tenant to service a different API call. [0054], FIG. 9 illustrates a flowchart of a method of efficiently allocating a pool of containers for servicing requests in a multi-tenant environment, according to some embodiments. The method may include assigning a plurality of containers to a first tenant in the multi-tenant environment (902). The method may also include identifying one or more containers in the plurality of containers that are assigned to the first tenant but that are not being used by the first tenant (904). The method may additionally include flushing the contents of the one or more containers (906). The method may further include reassigning the one or more containers to a second tenant in the multi-tenant environment (908).)
Regarding claim(s) 6, the method of claim 1,
Fichtenholtz-Zengerle teach comprising responsive to assigning the client device to the container, loading a file system associated with an application of the client device. (Fichtenholtz, [0047], the container can be assigned to a tenant and loaded with a configuration, application, state information, etc., in state 606.)
Claim(s) 12 and 20 is/are substantially similar to claim 4, and is thus rejected under substantially the same rationale.
Claim(s) 13 is/are substantially similar to claim 5, and is thus rejected under substantially the same rationale.
Claim(s) 14 is/are substantially similar to claim 6, and is thus rejected under substantially the same rationale.
2. Claim(s) 2, 10 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Fichtenholtz in view of Zengerle further in view of Radhakrishnan US 20130047203 A1).
Regarding claim(s) 2, the method of claim 1,
Fichtenholtz-Zengerle do not teach comprising receiving a token from the client device to establish the new session.
Radhakrishnan however in the same field of computer networking teaches comprising receiving a token from the client device to establish the new session. (Radhakrishnan, [0076], When user 112 uses device 114 to request a resource 145 from resource provider 140, TBAC module 110 may intercept the request and determine if user 112 should be granted access to the resource 145. [0102], FIGS. 2 and 3 illustrate how system 100 may perform the container chaining function to prepare a device 114 to consume a resource 145. Prior to granting device 114 access to the resource 145, device 114 is provisioned with an appropriate container 210 that is capable of facilitating access to and consumption of the resource 145.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Fichtenholtz by incorporating the teachings of Radhakrishnan. The motivation/suggestion would have been because there is a need to grant or deny a user to access resource. (Radhakrishnan, [0003]).
Claim(s) 10 and 18 is/are substantially similar to claim 2, and is thus rejected under substantially the same rationale.
3. Claim(s) 3, 11 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Fichtenholtz in view of Zengerle further in view of Pintér (US 20200272712 A1).
Regarding claim(s) 3, the method of claim 1,
Fichtenholtz-Zengerle do not teach comprising writing an exit time and session identifier to a container file after the container is unloaded
Pintérhowever in the same field of computer networking teaches comprising writing an exit time and session identifier to a container file after the container is unloaded. (Pintér, [0053] FIG. 5 provides additional detail regarding how server 120 can record a user's session when accessing an application with privileged credentials. As shown, web services 121 can be configured to receive protocol communications from proxy 130 and information from container 142 (or from container manager 141). This information can include information about the container (e.g., an identifier of the container), an identifier of the user, an identifier of the application that is being accessed, the start and end time of the session, etc. [0063] The events can be stored with sufficient information (e.g., an identifier of the session in which the event occurred, a timestamp when the event occurred, etc.) to allow the reviewer to jump to the time within the session when the event occurred.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Fichtenholtz by incorporating the teachings of Pintér. The motivation/suggestion would have been because there is a need to enabling a user to access an application using privileged credentials without having access to the privileged credentials (Pintér, [0007]).
Claim(s) 11 and 19 is/are substantially similar to claim 3, and is thus rejected under substantially the same rationale.
4. Claim(s) 7 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Fichtenholtz in view of Zengerle further in view of Gaddehosur (US 20170170990 A1).
Regarding claim(s) 7, the method of claim 1,
Fichtenholtz-Zengerle do not teach wherein the container parent process maintains a firewall process, a port range of assigned ports assigned to the container, and a virtual network adapter.
Gaddehosur however in the same field of computer networking teaches wherein the container parent process maintains a firewall process, a port range of assigned ports assigned to the container, and a virtual network adapter. (Gaddehosur, [0021] Example configurable policy elements defined by the templates 126 include: [0022] 1. A pool of resources (e.g., IP addresses, Media Access Control (MAC) addresses, port numbers, and so forth) that may be allocated to containers 110 and 112, or other containers or nested virtual machines within any of the host nodes 102-106. [0026] 5. Security policies. Security policies include access control lists (ACLs), firewall rules, and so forth for enforcing security policies. The ACLs may specify a 5-tuple of source port, source address, protocol, destination port, and destination address that define packets that are allowed or denied entry into a network through a network device, such as a firewall. The firewall rules may include such things as whether packets are dropped, forwarded, redirected, subjected to stateful or stateless packet inspection, and so forth. The templates 126 may specify aspects of ACLs, firewall rules, and so forth that may be configured by the local controller 124, within certain constraints. A template 126 may specify a list of firewall rules, ACLs and so forth that may be used in a policy, a range of ports that may be permitted, and so forth. [0061], Containers have their own NIC, compartmentalized TCP/IP stack, and shared Kernel, thus appearing as conventional entities on the network. Containers are lightweight (relative to a VM), and thus can achieve densities of several orders of magnitude on a physical system. It would be obviously to communicate over a network and need those things for communication on a machine that hosts multiple containers.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Fichtenholtz by incorporating the teachings of Gaddehosur. The motivation/suggestion would have been because there is a need to create flexibility to manage this new hyperscale datacenter (Gaddehosur, [0002]).
Claim(s) 15 is/are substantially similar to claim 7, and is thus rejected under substantially the same rationale.
5. Claim(s) 8 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Fichtenholtz in view of Zengerle further in view of CHUGTU (US 20180270124 A1).
Regarding claim(s) 8, the method of claim 1,
Fichtenholtz-Zengerle do not teach wherein updating the container record to an available status after the session has ended comprises removing a TCP proxy process and a DNS server process from the container.
CHUGTU however in the same field of computer networking teaches wherein updating the container record to an available status after the session has ended comprises removing a TCP proxy process and a DNS server process from the container. (CHUGTU, [0087], or alternatively, server device 220 can communicate with a container, a proxy container, another server device 220, and/or network device 230, such as by using an application program interface (API). For example, server device 220 can communicate with a domain name system (DNS) server to dynamically configure DNS records for transparent outbound transmission control protocol (TCP) proxy. Continuing with the previous example, server device 220 can configure a DNS record to permit transparent outbound TCP proxy, and can deploy a container after configuring the DNS record. [examiner notes: It would be common and obvious to assign new IP address, TCP proxy process, DNS server process when assigned/deployed a container to a user.])
Therefore, it would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Fichtenholtz by incorporating the teachings of CHUGTU. The motivation/suggestion would have been because there is a need to increasing security of providing an application with external connectivity. In addition, this improves management of the application by permitting easy application of policies, load balancing of traffic, and/or the like among multiple back-end hosts, thereby increasing an efficiency and conserving processing resources (CHUGTU, [0009]).
Claim(s) 16 is/are substantially similar to claim 8, and is thus rejected under substantially the same rationale
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WUJI CHEN whose telephone number is (571)270-0365. The examiner can normally be reached on 9am-6pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, VIVEK SRIVASTAVA can be reached on (571) 272-7304. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/WUJI CHEN/
Examiner, Art Unit 2449
/VIVEK SRIVASTAVA/Supervisory Patent Examiner, Art Unit 2449
Prosecution Insights