Prosecution Insights
Last updated: October 25, 2026
Application No. 18/697,887

PRIORITIZING ACCESS BY A CONTAINER INSTANCE TO A FILE IN A FILE SYSTEM RESOURCE

Non-Final OA §102
Filed
Apr 02, 2024
Priority
Oct 19, 2021 — EU 21203473.0 +1 more
Examiner
ZARRINEH, SHAHRIAR
Art Unit
2496
Tech Center
2400 — Computer Networks
Assignee
Siemens Aktiengesellschaft
OA Round
3 (Non-Final)
77%
Grant Probability
Favorable
3-4
OA Rounds
1m
Est. Remaining
84%
With Interview

Examiner Intelligence

Grants 77% — above average
77%
Career Allowance Rate
354 granted / 458 resolved
+19.3% vs TC avg
Moderate +7% lift
Without
With
+6.9%
Interview Lift
resolved cases with interview
Typical timeline
2y 8m
Avg Prosecution
24 currently pending
Career history
523
Total Applications
across all art units

Statute-Specific Performance

§101
9.5%
-30.5% vs TC avg
§103
56.0%
+16.0% vs TC avg
§102
12.7%
-27.3% vs TC avg
§112
16.3%
-23.7% vs TC avg
Black line = Tech Center average estimate • Based on career data from 458 resolved cases

Office Action

§102
DETAILED ACTION Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . In communications filed on 04/23/2026. Claims 1 and 14 are amended. Claims 1-15 are pending in this examination. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. This examination is in response to US Patent Application No. 18/697,887. 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 has been entered. Examiner Note Applicant’s amendment to claim 14 obviates previously raised 35 USC 101 claim rejection. Response to Argument Applicant’s arguments with respect to independent claims 1, and 14 for newly added limitation have been considered but are moot because the arguments do not apply to any of the references being used in the current rejection. Examiner has withdrawn the 35 USC claim 102 rejections under references from HUI, Achyuth, Barton, Edwards, and Vrabec submitted in last office action. Claim Rejections - 35 USC § 102 The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention. Claims 1-15 are rejected under 35 U.S.C. 102(a) (1) as being anticipated by Chen et al. (US9,697,144). Regarding claim 1, Chen discloses a method for prioritizing access by a container instance to a file in a file system resource, comprising[Col. 10 lines 64-67, Col. 11 lines 11 1-3, At block 440, the processing device determines, in view of the QoS attributes, an order for sending the first I/O request and the second I/O request to the storage device. The processing device can make a determination of which I/O request to place first in the order for being sent to the storage device based on the I/O bandwidths and/or the priority levels of the virtual resources. [Col. 11 lines 55-61, The processing device may then determine that the first priority level for the container has a higher priority than the second priority level for the second virtual resource….]; and receiving, in a runtime environment of the container instance, from a process executed within the container instance, an access request for the container instance to access the file, wherein the access request contains an access identifier which indicates at least one property of the container instance [Col. 1 lines 25-36, Cloud computing utilizes server and storage virtualization to allocate/reallocate resources rapidly. The resources can include virtual resources, such as virtual machines and containers. The containers and virtual machines in the cloud can access and share storage devices in the cloud. The storage devices can include a file system for organizing data on the storage devices. Generally, when a container is provisioned on a host in a cloud, the container mounts the file system, which typically gives the container access to the contents of the entire file system], and [ see FIG. 3 and corresponding text for more detail]; and checking, by way of an access control unit in the runtime environment [ see FIG.1 device emulator 109, [Col. 5 lines 4-6, The device emulator 109 can emulate block devices (e.g., hard drives) for the virtual resource(s) (e.g., virtual machine 115, container 111) on the host machine 125], and [Col. 11 lines 13-20, A cluster management system (e.g., cluster management system 107 in FIG. 1) and/or a device emulator (e.g., device emulator 109 in FIG. 1) can set the throttling I/O rates, for example, based on user input, and assign the throttling I/O rates to the respective virtual resources]; and the at least one property in the access identifier against an access guideline that comprises a prioritization level that determines a processing order for the access request relative to other access requests from other container instances accessing the same file for accessing at least the one file on a basis of the at least one property of the access identifier, wherein the access control unit determines whether the process belongs to the container instance[Col. 2 lines 8-15, The containers and/or virtual machines can share backend storage devices. The storage devices can include a file system for organizing the data on the storage devices. Traditionally, the containers directly access the storage devices using a mount point to mount the file system], and [ Col. 4 lines 65-67, Col. 5 lines 1-2, The storage device 103 can store data and can be shared between any number of virtual resources (e.g., container 111, virtual machine 115) in the environment 150. The storage device 103 can include a file system for organizing the data on the storage device 103], and [Col.9 lines 23-30, In one implementation, the container can be a first virtual resource hosted on the host machine, and the storage device can be shared between the container and a second virtual resource. The second virtual resource can be another container, a virtual machine, another container within a virtual machine, or a virtual machine within another container. The second virtual resource can be hosted on the host machine or hosted on another host machine], and [ Col. 10 lines 41-58, The virtual resources can be assigned a respective priority level. A virtual resource may be assigned a priority based on, for example, the end-user(s) and/or end-user group(s) that are using the virtual resource, the application(s) being executed by the virtual resource, the jobs being performed by the virtual resource, etc. A cluster management system (e.g., cluster management system 107 in FIG. 1) can set the priorities for the various virtual resources, for example, based on user input, and can store the priorities in configuration data. The processing device can access the priorities and determine which virtual resource has a higher priority. For example, the container may be used by an end-user group that is developing an application for a company, and the second virtual resource may be backup source of data for the company. The cluster management system can set, based on user input from a system administrator of the company, the priority for the container to a higher priority than the priority for the second virtual resource], and [Col. 11 lines 45-67, Col. 12 lines 1-11, , If the I/O bandwidths for the virtual resources do not exceed the respective limits, the processing device can determine the order in which the I/O requests are to be sent to the storage device based on the priority levels of the virtual resources. The processing device can create the order such that the send I/O request associated with the virtual resource that has a higher priority is to be sent to the storage device first. For example, the processing device may determine that both the first I/O bandwidth for the container and the second I/O bandwidth for the second virtual resource do not exceed the respective limits. The processing device may then determine that the first priority level for the container has a higher priority than the second priority level for the second virtual resource, and can create an order such that first I/O request associated with the container is sent to the storage device before the second I/O request associated with the second virtual resource. If the I/O bandwidths for the virtual resources exceed the respective limits, the processing device can prevent the I/O requests from being sent to the storage device until a time when sending a respective I/O request to the storage device would not cause the corresponding virtual resource to exceed the respective limit. The processing device can store the I/O requests in the respective queues and remove the I/O requests from the respective queues based on the priority levels of the virtual resources. For example, the processing device may determine that both the first I/O bandwidth for the container and the second I/O bandwidth for the second virtual resource exceed the respective limits. The processing device can store the first I/O request in the queue that is assigned to the block device (e.g., pseudo device) that is being emulated for the container and can store the second I/O request in the queue that is assigned to the block device that is being emulated for the second virtual resource]; and and assigning an access authorization with the prioritization level corresponding to the at least one property of the container instance to the access request on a basis of the checking result [ Col. 10, lines 50-58, The processing device can access the priorities and determine which virtual resource has a higher priority. For example, the container may be used by an end-user group that is developing an application for a company, and the second virtual resource may be backup source of data for the company. The cluster management system can set, based on user input from a system administrator of the company, the priority for the container to a higher priority than the priority for the second virtual resource], and [Col. 11 lines 45-67, Col. 12 lines 1-11]; and and forwarding the access request to the file on a basis of the assigned prioritization level [Col. 12 lines 12-20, The processing device may then determine that the first priority level for the container has a higher priority than the second priority level for the second virtual resource, and can first remove the first I/O request in the queue for the container and send the first I/O request to the storage device, prior to removing the second I/O request in the queue for the second virtual resource. At block 450, the processing device sends the first I/O request and the second I/O request to the storage device in the determined order]. Regarding claim 2, Chen discloses wherein the file is a device file which receives control instructions from the container instance and forwards the control instruction execution to a hardware resource that can be controlled by the container instance [see FIG. 1-2, and corresponding text for more details, [ Col. 1 lines 24-37, Cloud computing utilizes server and storage virtualization to allocate/reallocate resources rapidly. The resources can include virtual resources, such as virtual machines and containers. The containers and virtual machines in the cloud can access and share storage devices in the cloud. The storage devices can include a file system for organizing data on the storage devices. Generally, when a container is provisioned on a host in a cloud, the container mounts the file system, which typically gives the container access to the contents of the entire file system. Generally, virtual machines are provisioned in the cloud via a hypervisor and a device emulator and have a data input/output (I/O) path that accesses the storage device via the device emulator]. Regarding claim 3, Chen discloses wherein the access identifier is created specifically for the container instance or the access identifier created specifically for container image and a container-image-specific access identifier is assigned to each container instance generated from the container image [ Col. 5 lines 50-61, (25) The container I/O component 203 can communicate with the container 201 and a device emulator 211 to create a data I/O path for the container 201 to access to one or more backend storage devices. For brevity and simplicity, one storage device 215 is illustrated in storage management system 200. The container I/O component 203 can be a component of an operating system being executed by the processing device 213. The container I/O component 203 can be a TCMU (Target Core Module in Userspace). The container I/O component 203 can include a request module 205, a translation module 207, and a communication module 209 for the container 201 to access the storage device 215], and [ Col. 10, 31-35, the processing device can determine, from identifiers in the I/O requests, which I/O requests are associated with the pseudo device being emulated for the container, and which I/O requests are associated with the block device being emulated for the second virtual resource Regarding claim 4, Chen discloses wherein the prioritization levels for accessing the hardware resource by the container instance are predefined by an operator of the hardware resource [ Col. 10, lines 41-53, (52) The virtual resources can be assigned a respective priority level. A virtual resource may be assigned a priority based on, for example, the end-user(s) and/or end-user group(s) that are using the virtual resource, the application(s) being executed by the virtual resource, the jobs being performed by the virtual resource, etc. A cluster management system (e.g., cluster management system 107 in FIG. 1) can set the priorities for the various virtual resources, for example, based on user input, and can store the priorities in configuration data. The processing device can access the priorities and determine which virtual resource has a higher priority. For example, the container may be used by an end-user group that is developing an application for a company, and the second virtual resource may be backup source of data for the company. The cluster management system can set, based on user input from a system administrator of the company, the priority for the container to a higher priority than the priority for the second virtual resource]. Regarding claim 5, Chen discloses wherein at least one property in the access identifier is at least one from a selection of: a name of the access identifier, a signature of the accessing container instance, a signature of container image, from which the container instance is generated, and a name of the container image [ Col. 5 lines 50-61, (25) The container I/O component 203 can communicate with the container 201 and a device emulator 211 to create a data I/O path for the container 201 to access to one or more backend storage devices. For brevity and simplicity, one storage device 215 is illustrated in storage management system 200. The container I/O component 203 can be a component of an operating system being executed by the processing device 213. The container I/O component 203 can be a TCMU (Target Core Module in Userspace). The container I/O component 203 can include a request module 205, a translation module 207, and a communication module 209 for the container 201 to access the storage device 215], and [ Col. 10, 31-35, the processing device can determine, from identifiers in the I/O requests, which I/O requests are associated with the pseudo device being emulated for the container, and which I/O requests are associated with the block device being emulated for the second virtual resource Regarding claim 6, Chen discloses wherein, if at least one network interface is assigned to the container instance, the access identifier contains an identifier for each of the at least one assigned network interface [ see FIG. 1 and corresponding text for more details, Col. 4 lines 53-67, The host machine 125 can be coupled to one or more storage devices (e.g., storage device 103) via one or more networks (e.g., network 105). The network 105 can be a private network (e.g., a local area network (LAN), a wide area network (WAN), intranet, or other similar private networks) or a public network (e.g., the Internet). For brevity and simplicity, one storage device 103 is illustrated in FIG. 1. The storage device 103 can be any computing hardware that is used for storing, porting, and extracting data files and objects. The storage device 103 can store information both temporarily and permanently, and can be internal or external to a computer, server or any similar computing device. The storage device 103 can store data and can be shared between any number of virtual resources (e.g., container 111, virtual machine 115) in the environment 150. The storage device 103 can include a file system for organizing the data on the storage device 103], and [ see FIG. 2, and corresponding text for more details]. Regarding claim 7, Chen discloses wherein the identifier of the assigned network interface is assigned to at least one a network interface by an operator of the runtime environment [ see Figs 1-2, and corresponding text for more details, Col. 4 lines 53-67], and [ Col. 10, lines 41-53, (52) The virtual resources can be assigned a respective priority level. A virtual resource may be assigned a priority based on, for example, the end-user(s) and/or end-user group(s) that are using the virtual resource, the application(s) being executed by the virtual resource, the jobs being performed by the virtual resource, etc. A cluster management system (e.g., cluster management system 107 in FIG. 1) can set the priorities for the various virtual resources, for example, based on user input, and can store the priorities in configuration data. The processing device can access the priorities and determine which virtual resource has a higher priority. For example, the container may be used by an end-user group that is developing an application for a company, and the second virtual resource may be backup source of data for the company. The cluster management system can set, based on user input from a system administrator of the company, the priority for the container to a higher priority than the priority for the second virtual resource]. Regarding claim 8, Chen discloses wherein the access guideline comprises a prioritization level for each of the identifiers of at least of network interfaces[ see Figs 1-2, and corresponding text for more details, Col. 4 lines 53-67], and [ Col. 10, lines 41-53, (52) The virtual resources can be assigned a respective priority level. A virtual resource may be assigned a priority based on, for example, the end-user(s) and/or end-user group(s) that are using the virtual resource, the application(s) being executed by the virtual resource, the jobs being performed by the virtual resource, etc. A cluster management system (e.g., cluster management system 107 in FIG. 1) can set the priorities for the various virtual resources, for example, based on user input, and can store the priorities in configuration data. The processing device can access the priorities and determine which virtual resource has a higher priority. For example, the container may be used by an end-user group that is developing an application for a company, and the second virtual resource may be backup source of data for the company. The cluster management system can set, based on user input from a system administrator of the company, the priority for the container to a higher priority than the priority for the second virtual resource], and [[Col. 2 lines 8-15, Col. 4 lines 65-67, Col. 5 lines 1-2, Col. 10 lines 41-58, Col. 11 lines 45-67, Col. 12 lines 1-11]. Regarding claim 9, Chen discloses wherein the prioritization level which is assigned to the first property contained in the access identifier is assigned to the access request [Col. 2 lines 8-15, The containers and/or virtual machines can share backend storage devices. The storage devices can include a file system for organizing the data on the storage devices. Traditionally, the containers directly access the storage devices using a mount point to mount the file system], and [ Col. 4 lines 65-67, Col. 5 lines 1-2, The storage device 103 can store data and can be shared between any number of virtual resources (e.g., container 111, virtual machine 115) in the environment 150. The storage device 103 can include a file system for organizing the data on the storage device 103], and [Col.9 lines 23-30, In one implementation, the container can be a first virtual resource hosted on the host machine, and the storage device can be shared between the container and a second virtual resource. The second virtual resource can be another container, a virtual machine, another container within a virtual machine, or a virtual machine within another container. The second virtual resource can be hosted on the host machine or hosted on another host machine], and [ Col. 10 lines 41-58, The virtual resources can be assigned a respective priority level. A virtual resource may be assigned a priority based on, for example, the end-user(s) and/or end-user group(s) that are using the virtual resource, the application(s) being executed by the virtual resource, the jobs being performed by the virtual resource, etc. A cluster management system (e.g., cluster management system 107 in FIG. 1) can set the priorities for the various virtual resources, for example, based on user input, and can store the priorities in configuration data. The processing device can access the priorities and determine which virtual resource has a higher priority. For example, the container may be used by an end-user group that is developing an application for a company, and the second virtual resource may be backup source of data for the company. The cluster management system can set, based on user input from a system administrator of the company, the priority for the container to a higher priority than the priority for the second virtual resource], and [Col. 11 lines 45-67, Col. 12 lines 1-11, , If the I/O bandwidths for the virtual resources do not exceed the respective limits, the processing device can determine the order in which the I/O requests are to be sent to the storage device based on the priority levels of the virtual resources. The processing device can create the order such that the send I/O request associated with the virtual resource that has a higher priority is to be sent to the storage device first. For example, the processing device may determine that both the first I/O bandwidth for the container and the second I/O bandwidth for the second virtual resource do not exceed the respective limits. The processing device may then determine that the first priority level for the container has a higher priority than the second priority level for the second virtual resource, and can create an order such that first I/O request associated with the container is sent to the storage device before the second I/O request associated with the second virtual resource. If the I/O bandwidths for the virtual resources exceed the respective limits, the processing device can prevent the I/O requests from being sent to the storage device until a time when sending a respective I/O request to the storage device would not cause the corresponding virtual resource to exceed the respective limit. The processing device can store the I/O requests in the respective queues and remove the I/O requests from the respective queues based on the priority levels of the virtual resources. For example, the processing device may determine that both the first I/O bandwidth for the container and the second I/O bandwidth for the second virtual resource exceed the respective limits. The processing device can store the first I/O request in the queue that is assigned to the block device (e.g., pseudo device) that is being emulated for the container and can store the second I/O request in the queue that is assigned to the block device that is being emulated for the second virtual resource]. Regarding claim 10, Chen discloses wherein the highest prioritization level of all prioritization levels assigned to the at least one property contained in the access identifier is assigned to the access request.[Col. 2 lines 8-15, The containers and/or virtual machines can share backend storage devices. The storage devices can include a file system for organizing the data on the storage devices. Traditionally, the containers directly access the storage devices using a mount point to mount the file system], and [ Col. 4 lines 65-67, Col. 5 lines 1-2, The storage device 103 can store data and can be shared between any number of virtual resources (e.g., container 111, virtual machine 115) in the environment 150. The storage device 103 can include a file system for organizing the data on the storage device 103], and [Col.9 lines 23-30, In one implementation, the container can be a first virtual resource hosted on the host machine, and the storage device can be shared between the container and a second virtual resource. The second virtual resource can be another container, a virtual machine, another container within a virtual machine, or a virtual machine within another container. The second virtual resource can be hosted on the host machine or hosted on another host machine], and [ Col. 10 lines 41-58, The virtual resources can be assigned a respective priority level. A virtual resource may be assigned a priority based on, for example, the end-user(s) and/or end-user group(s) that are using the virtual resource, the application(s) being executed by the virtual resource, the jobs being performed by the virtual resource, etc. A cluster management system (e.g., cluster management system 107 in FIG. 1) can set the priorities for the various virtual resources, for example, based on user input, and can store the priorities in configuration data. The processing device can access the priorities and determine which virtual resource has a higher priority. For example, the container may be used by an end-user group that is developing an application for a company, and the second virtual resource may be backup source of data for the company. The cluster management system can set, based on user input from a system administrator of the company, the priority for the container to a higher priority than the priority for the second virtual resource], and [Col. 11 lines 45-67, Col. 12 lines 1-11, , If the I/O bandwidths for the virtual resources do not exceed the respective limits, the processing device can determine the order in which the I/O requests are to be sent to the storage device based on the priority levels of the virtual resources. The processing device can create the order such that the send I/O request associated with the virtual resource that has a higher priority is to be sent to the storage device first. For example, the processing device may determine that both the first I/O bandwidth for the container and the second I/O bandwidth for the second virtual resource do not exceed the respective limits. The processing device may then determine that the first priority level for the container has a higher priority than the second priority level for the second virtual resource, and can create an order such that first I/O request associated with the container is sent to the storage device before the second I/O request associated with the second virtual resource. If the I/O bandwidths for the virtual resources exceed the respective limits, the processing device can prevent the I/O requests from being sent to the storage device until a time when sending a respective I/O request to the storage device would not cause the corresponding virtual resource to exceed the respective limit. The processing device can store the I/O requests in the respective queues and remove the I/O requests from the respective queues based on the priority levels of the virtual resources. For example, the processing device may determine that both the first I/O bandwidth for the container and the second I/O bandwidth for the second virtual resource exceed the respective limits. The processing device can store the first I/O request in the queue that is assigned to the block device (e.g., pseudo device) that is being emulated for the container and can store the second I/O request in the queue that is assigned to the block device that is being emulated for the second virtual resource]. Regarding claim 11, Chen discloses wherein the access guideline comprises, for each of the at least one file a name of the file and at least one property from a selection of the following properties: a name of the access identifier, a signature of the container instance, a signature of a container image, from which the accessing container instance is generated, a name of the container image or an identifier for a network interface, and a prioritization level is assigned to at least one of the properties from the selection[ see Figs 1-2, and corresponding text for more details, Col. 4 lines 53-67], and [ Col. 2 lines 8-15, Col. 4 lines 65-67, Col. 5 lines 1-2, Col. 10 lines 41-58, Col. 11 lines 45-67, Col. 12 lines 1-11]. Regarding claim 12, Chen discloses wherein the access guideline comprises, for each of the at least one file, at least one detail from a selection of a process name for a process requested via the access request, an access mode, a maximum access duration, on basis of the property of the access identifier [ Col. 10 , lines 13-40, At block 430, the processing device determines QoS attributes for the container and the second virtual resource. The QoS attributes can include, for example, a measurement of I/O bandwidth for a virtual resource (e.g., container, second virtual resource), a priority level assigned to the virtual resource, and a time that the processing device receives the I/O request of a virtual resource. The measurement for the I/O bandwidth can be represented as a number of I/O events (e.g., I/O read requests, I/O write requests) for a particular virtual resource for a period of time. The period of time can be configurable and/or user-defined. The period of time can be stored as part of configuration data. The processing device can determine the first I/O bandwidth for the container by counting the number of I/O events associated with the container during the period of time. The processing device can associate each I/O request with a block device that is being emulated for a virtual resource. For example, the processing device can determine, from identifiers in the I/O requests, which I/O requests are associated with the pseudo device being emulated for the container, and which I/O requests are associated with the block device being emulated for the second virtual resource. The processing device can count the number of I/O requests that occur for a particular time interval (e.g., one second) to determine the I/O bandwidth for a respective virtual resource. For example, the processing device may count 10 I/O requests per second for the container]. Regarding claim 13, Chen discloses, wherein the access control unit is an expansion module of the runtime environment or an independent unit that is separate from the runtime environment [ see FIG 1-2 and corresponding text for more details]. Regarding claims 14, and 15, these claims are interpreted and rejected for the same rational set forth in claim 1. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See submitted 892 for more relevant references. Kosaka (US2020/0218798) [ [0073] The policy interpreter 125 generates file system rules by scanning the dynamic running services information 110 for the application container as received from the manifest detector 115 to determine if the application container has opened any file handles or accessed any storage locations upon initiation or during a period following the initiation. In response to determining that the application container has accessed one or more files and/or storage locations, the policy interpreter 125 may create one or more file system rules allowing the application container to access these files. The policy interpreter 125 may also scan the application container deployment configuration information 105 to determine if the application container requests access to certain file locations, such as a database, etc. The policy interpreter 125 may also create one or more file system rules allowing the application container to access these file locations in response to determining that the application container has requested these file locations. Guo (US2020/02856609) [ 0011] During runtime, when a file of the container (e.g., “ntdll.dll”) is to be accessed, for instance, by a container process, a file manager on the host device can resolve the parent identifier, generate a complete file path for the file, and access the file at the complete file path, and serve the file to the container process. For instance, in the example above, the “GUID” of “ntdll.dll” can include a string that corresponds to a system directory/drive on the host device (e.g., “C:\windows”) as indicated in a path table maintained on the host device. As such, upon parsing the symbolic link above, the file manager can locate a path to the system directory on the host device by consulting the path table and construct a complete file path to the requested file as following: [0012] C:\windows\system32\ntdll.dll. Havewala (US2018/0129821) [ Abstract, an application running in a container is able to access files stored on disk via normal file system calls, but in a manner that remains isolated from applications and processes in other containers. In one aspect, a namespace virtualization component is coupled with a copy-on-write component. When an isolated application is accessing a file stored on disk in a read-only manner, the namespace virtualization component and copy-on-write component grant access to the file. But, if the application requests to modify the file, the copy-on-write component intercepts the I/O and effectively creates a copy of the file in a different storage location on disk. The namespace virtualization component is then responsible for hiding the true location of the copy of the file, via namespace mapping]. Gunda (US2018/0293394) [ Abstract, A method of providing security for containers executing on a physical host machine is provided. The method receives a notification of a file access request. The notification includes a path in a file system of the host machine being accessed by a process. From the path, the method determines whether the file access event is for accessing a location in the file system to which container file systems are mapped. The method identifies a namespace of the process using the identification of the process included in the file path. The method determines the process is a container when the namespace belongs to a service that is used to implement containers on the host machine. The method sends the identifier of the container, the identification of a VM executing the container, and the file path to a set of security applications to determine whether the file access request to be allowed]. Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5:30pm. 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, Jorge Ortiz-Criado can be reached at 571-272-7624. 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. /SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496
Read full office action

Prosecution Timeline

Apr 02, 2024
Application Filed
Jul 30, 2025
Non-Final Rejection mailed — §102
Nov 03, 2025
Response Filed
Dec 23, 2025
Final Rejection mailed — §102
Feb 26, 2026
Response after Non-Final Action
Apr 23, 2026
Request for Continued Examination
May 01, 2026
Response after Non-Final Action
Oct 07, 2026
Non-Final Rejection mailed — §102 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12748883
Systems and Methods for Providing Improved Account Management Services
3y 9m to grant Granted Sep 29, 2026
Patent 12739110
METHOD, ELECTRONIC DEVICE, AND COMPUTER PROGRAM PRODUCT FOR IDENTITY AUTHENTICATION
2y 9m to grant Granted Sep 15, 2026
Patent 12732378
IMPLEMENTING LOGIC GATE FUNCTIONALITY USING A BLOCKCHAIN
7y 10m to grant Granted Sep 08, 2026
Patent 12695598
SYSTEMS AND METHODS FOR STORAGE, GENERATION AND VERIFICATION OF TOKENS USED TO CONTROL ACCESS TO A RESOURCE
3y 1m to grant Granted Jul 28, 2026
Patent 12683782
MUTUAL MULTI-FACTOR AUTHENTICATION TECHNOLOGY
5y 7m to grant Granted Jul 14, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
77%
Grant Probability
84%
With Interview (+6.9%)
2y 8m (~1m remaining)
Median Time to Grant
High
PTA Risk
Based on 458 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month