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 .
This action is responsive to the Applicant’s amendments filed on 07/16/2026. Claims 1-15 remain pending in the application. Claims 1, 2, 5, and 8-15 have been amended. Any examiner’s note, objection, and rejection not repeated is withdrawn due to Applicant’s amendment.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
A copy of the patent application was electronically received, certified 01/22/2024.
Examiner’s Note
The Examiner cites particular columns, paragraphs, figures, and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may also apply. It is respectfully requested that, in preparing responses, the Applicant fully consider the references in its entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
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.
Claims 1 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Gutman et al. (US 20190220260 A1) hereafter Gutman in view of Pinto (US 20230259404 A1), further in view of Chong (US 12039339 B1).
Regarding claim 1, Gutman teaches:
A device resource management method of an electronic device,
wherein the electronic device comprises a memory (Paragraph 68; “The computing device 200 can also include at least one memory”) and executes a plurality of applications (Paragraph 96; “Registry 258, e.g., a WINDOWS registry, represents a database or other collection of data of low-level settings for the OS 220 and for applications 244 of computing device 200 that are configured to use the registry 258”, applications 224 is plural);
the memory stores a first store and a second list (Paragraphs 115, 121; “System 400 includes a configuration datastore 402”, corresponding to the first storage, and further contains “a list of active drivers.”, corresponding to the second list.);
the first store comprises at least one piece of application resource information (Paragraphs 115-118; “System 400 includes a configuration datastore 402, which can represent registry 258, the WINDOWS device metadata store that holds device-property values, or another datastore that can retain values, e.g., across system reboots”, which includes “writing at least one driver-configuration entry 404 to configuration datastore 402”. Entries written to the config datastore correspond to the at least one piece of application resource information, as evidenced by “The driver-configuration entry 404 can include, e.g., a registry key, device property, device interface property, or other entry. The driver-configuration entry 404 can include an interface version or other configuration used by application 244”.);
the second list comprises at least one device driver (Paragraph 121; “In response to flag 408, OS 220 can remove first driver 226 from display in, or refrain from adding first driver 226 to, a list of active drivers.”, list of active drivers corresponds to the second list);
the at least one piece of application resource information corresponds to the at least one device driver (Paragraph 118; “The driver-configuration entry 404 can include, e.g., a registry key, device property, device interface property, or other entry. The driver-configuration entry 404 can include an interface version or other configuration used by application 244”, each application has a corresponding driver config entry.);
each device driver corresponds to at least one piece of device resource information (Paragraph 118; “The driver-configuration entry 404 can include, e.g., a registry key, device property, device interface property, or other entry. The driver-configuration entry 404 can include an interface version or other configuration used by application 244”, each driver config entry having a corresponding device property, corresponding to device resource information.);
wherein the at least one piece of device resource information corresponding to each device driver is recorded in a device resource information store (Paragraph 118; in which the driver-configuration entry includes device property information/configuration information, corresponding to at least one piece of device resource information. The configuration is used for communication with drivers, thus corresponding to each device driver. Paragraph 117 further discloses that the driver writes the driver-configuration entry to configuration datastore 402.);
the device resource management method comprising:
searching the first store for a piece of target application resource information corresponding to a target application of the applications in response to an abnormal exit procedure of the target application, wherein the piece of target application resource information is one of the at least one piece of application resource information (Paragraphs 163-164; “Operation 718 can include, e.g., determining that the ERRORLEVEL or process exit code from an installation package is nonzero, that an HRESULT or other return value from an installation routine is an error (e.g., −1) or S_FALSE return, or that another system component has flagged an error”, the installation package associated with a target application, in which in response, “the control unit can roll back the installation operations 606. Operation 722 can be performed in response to, or after, operation 718. Operation 722 can include creating, removing, or modifying files or configuration entries, or performing other operations described herein with reference to installation operations 606 in order to reverse the effects of those operations”, the modification of configuration entries corresponding to a target application resource requiring the particular configuration entry be found prior to modification, thus corresponding to the first store being searched for target application resource information in response to an abnormal exit.)
Gutman does not teach that the first storage is a list; the first list being maintained during execution of the applications; each corresponding to a respective one of the applications being executed; searching the first list for a piece of target application resource information corresponding to a target application of the applications wherein the piece of target application resource information is one of the at least one piece of application resource information; wherein the abnormal exit procedure is triggered by a system exception that forcibly terminates the target application during execution of the target application; determining a target device driver according to the piece of target application resource information; and deleting a piece of target device resource information corresponding to the target device driver from the second list.
However, Pinto teaches:
A first list (Paragraph 76; “In some embodiments, a programming interface library 421 may maintain a list or other data structure to track resources any computational resources 406 across one or more computational devices 402.”);
the first list being maintained during execution of the applications (Paragraph 76; “For example, when one or more resources are allocated to an application, the programming interface library 421 may add a handle for the resources to the list, and when one or more resources are freed (e.g., by an application), the programming interface library 421 may remove the corresponding handle from the list.” The list exists before and after execution of the application, therefore being maintained during execution of the application.);
each corresponding to a respective one of the applications being executed (Paragraph 76; “For example, when one or more resources are allocated to an application, the programming interface library 421 may add a handle for the resources to the list, and when one or more resources are freed (e.g., by an application), the programming interface library 421 may remove the corresponding handle from the list.”, which discloses resources allocated to one or more applications, tracking resources allocated to applications, and a list that tracks compute resources across devices.);
determining a target device driver according to the piece of target application resource information (Paragraph 22; “trap mechanism may gain control of an application's operation based on an action such as an exit of an application (e.g., conditionally and/or unconditionally), a stopping of a container, a shutdown of a VM, and/or the like. As another example, in some embodiments, a debug hook may trigger the execution of profiling code to understand a flow of resources and/or determine a remedial action by a resource management scheme.”, in which the trap mechanism determines the target device driver associated with a given application upon exit, as further evidenced in Paragraph 70, “any portion of a computational resource manager 428 may be implemented (e.g., run) in any suitable location, for example, anywhere in kernel space 419 (e.g., as part of a device driver, a service, and/or the like), anywhere in user space 420 (e.g., as part of a library, an application, an application adapter, and/or the like)”);
and deleting a piece of target device resource information corresponding to the target device driver from the second list (Paragraph 92; “pseudocode illustrated in Table 2 may be called by a computational resource manager to free and/or remove one or more resources from a tracking list, for example, when an application such as a program terminates (e.g., crashes). In some embodiments, the pseudocode may also be called when an application exits normally. For example, operating system hooks may be installed to trap the exit which in turn may call unwind( ).”, the resources corresponding to the piece of target device resource information corresponding to the target device driver.).
Gutman and Pinto are considered to be analogous to the claimed invention because they are in the same field of software resource information allocation and deallocation. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gutman to incorporate the teachings of Pinto and have the first store be a list, have the first list be maintained during execution of the applications, have each application resource information correspond to a respective one of the applications being executed, and have determined a target device driver according to a piece of target application resource information, and delete a piece of target device resource information corresponding to the target device driver from the second list. A person of ordinary skill in the art would have recognized from the disclosure of Pinto that any other data structure may be used to track application resource information, evidenced by “a list or other data structure to track resources”, and would have found a list to be one such known alternative data structure yielding the predictable result of tracking resources. A person of ordinary skill in the art would have further recognized maintaining resource information during execution as a known technique in cloud computing for monitoring and managing resources utilized by the application, whose implementation would yield the predictable result of keeping the resource information available for use in managing the application’s resources during execution. A person of ordinary skill in the art would have found it obvious to associate each item of application resource information with a respective application being executed, because maintaining resource information associated with each consumer is a known method in cloud computing for tracking compute resources allocated among multiple consumers, whose implementation would yield the predictable result of identifying resources allocated to each respective consumer. A person of ordinary skill in the art before the effective filing date of the claimed invention would have found it obvious to organize Gutman’s driver resource information in a respective list associated with each device driver utilizing the list based resource tracking of Pinto because organizing resource information according to the entity is a known method for facilitating resource tracking and management, whose implementation would yield the predictable result of maintaining the resource information for each device driver in a corresponding list. Further, mapping resources to processes and releasing such resources upon process termination is a known method in resource management whose implementation yields the predictable result of preventing resource leakage and maintaining system stability.
Gutman in view of Pinto does not teach wherein the abnormal exit procedure is triggered by a system exception that forcibly terminates the target application during execution of the target application.
However, Chong teaches:
wherein the abnormal exit procedure is triggered by a system exception that forcibly terminates the target application during execution of the target application (Col. 13, lines 55-62; “Depending on how the exception handling routine is implemented, the computer system may permit the application that generated the second request to continue running or take some other action such as suspending/terminating the application or terminating processing for all applications until the computer system has been reset into an initial configuration state”, where the action such as termination of processing of the application during execution corresponds to an abnormal exit procedure triggered by a system exception that causes a forced termination of the application, the system exception implied by the exception handling routine.).
Gutman, Pinto, and Chong are considered to be analogous to the claimed invention because they are reasonably pertinent to system configuration control. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Gutman, Pinto, and Chong to have the abnormal exit procedure triggered by a system exception that forcibly terminates the target application during execution of the target application. A person of ordinary skill in the art before the effective filing date of the claimed invention would have recognized that detecting and handling application termination caused by system exceptions is a known technique in error handling for managing premature termination, whose implementation would yield the predictable result of initiating the abnormal exit procedure when the target application is forcibly terminated during execution.
Claim 8 recites similar limitations as those of claim 1, additionally reciting a memory, an application circuit, and a processing circuit. Gutman teaches:
A memory (Paragraph 68; “The computing device 200 can also include at least one memory”);
An application circuit (Paragraph 65; “For example, processing units 210 can be or include Field-programmable Gate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs)”);
And a processing circuit (Paragraph 65; “computing device 200 can include one or more processing units 210. Processing units 210 can be or include one or more single-core processors, multi-core processors”, the processors inherently include processing circuitry.).
Claim 8 is rejected for similar reasons as those of claim 1.
Claims 2-3 and 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over Gutman in view of Pinto, further in view of Chong, further in view of Raghavendran et al. (US 20240036914 A1) hereafter Raghavendran.
Regarding claim 2, Gutman in view of Pinto, further in view of Chong teach the method of claim 1. Gutman teaches:
A second list (Paragraph 121; “a list of active drivers.”, corresponding to the second list).
Gutman in view of Pinto further in view of Chong does not teach wherein the at least one piece of device resource information comprises a level; checking the level of the piece of target device resource information; and deleting the piece of target device resource information when the level is a target value.
However, Raghavendran teaches:
wherein the at least one piece of device resource information comprises a level (Paragraph 41; “when the resource request type is a resource deletion request type, at operation 440, the strength level determination unit 312 of validator engine 320 determines whether any levels in the zonal topology graph have been identified and marked as weak levels”, the graph corresponding to a storage for device resource information, the information including levels);
checking the level of the piece of target device resource information (Paragraph 41; “the strength level determination unit 312 of validator engine 320 determines whether any levels in the zonal topology graph have been identified and marked as weak levels”, the unit explicitly checks if the level is marked as weak);
and deleting the piece of target device resource information when the level is a target value (Paragraph 41; “when strength level determination unit 312 determines that levels in the zonal topology graph have been identified and marked as weak levels, at operation 445, zonal scaling unit 370 of zonal topology core 330 deletes the pods-to-be-deleted from the weak levels first”).
Gutman, Pinto, Chong, and Raghavendran are considered to be analogous to the claimed invention because they are in the same field of software resource information allocation and deallocation. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gutman in view of Pinto further in view of Chong to incorporate the teachings of Raghavendran and have the device resource information comprise a level; check the level of the piece of target device resource information; and delete the piece of target device resource information when the level is a target value. A person of ordinary skill in the art would have recognized a level as a known method to delineate which resources should be removed from the system in response to an abnormal exit, whose implementation would yield the predictable result of graceful error handling.
Claim 9 recites similar limitations as those of claim 2. Claim 9 is rejected for similar reasons as those of claim 2.
Regarding claim 3, Gutman in view of Pinto further in view of Chong teach the method of claim 1. Gutman teaches:
The first store and second list (Paragraphs 115, 121; “System 400 includes a configuration datastore 402”, corresponding to the first storage, and further contains “a list of active drivers.”, corresponding to the second list).
Pinto teaches:
A first list (Paragraph 76; “In some embodiments, a programming interface library 421 may maintain a list or other data structure to track resources any computational resources 406 across one or more computational devices 402.”);
deleting the piece of target application resource information (Paragraph 92; “pseudocode illustrated in Table 2 may be called by a computational resource manager to free and/or remove one or more resources from a tracking list, for example, when an application such as a program terminates (e.g., crashes). In some embodiments, the pseudocode may also be called when an application exits normally. For example, operating system hooks may be installed to trap the exit which in turn may call unwind( ).”, the removal from a tracking list corresponding to deleting the piece of target application resource information.);
target device resource information corresponds to the target device driver (Paragraph 22; “trap mechanism may gain control of an application's operation based on an action such as an exit of an application (e.g., conditionally and/or unconditionally), a stopping of a container, a shutdown of a VM, and/or the like. As another example, in some embodiments, a debug hook may trigger the execution of profiling code to understand a flow of resources and/or determine a remedial action by a resource management scheme.”, in which the trap mechanism determines the target device driver associated with a given application upon exit, as further evidenced in Paragraph 70, “any portion of a computational resource manager 428 may be implemented (e.g., run) in any suitable location, for example, anywhere in kernel space 419 (e.g., as part of a device driver, a service, and/or the like), anywhere in user space 420 (e.g., as part of a library, an application, an application adapter, and/or the like)”).
Gutman in view of Pinto further in view of Chong does not teach wherein the piece of target application resource information comprises a total number of device resource(s); changing the total number of device resource(s) after deleting the piece of target device resource information corresponding to the target device driver; and deleting the piece of target application resource information when the total number of device resource(s) is equal to a target value.
However, Raghavendran teaches:
wherein the piece of target application resource information comprises a total number of device resource(s) (Paragraph 39; “a result set may be, for example, a set of the resources (e.g., pods or replicas) that have been collected (e.g., added or deleted) from a level of the zonal topology and a result set size is the size of the result set”, the result set size corresponding to the total number of device resources);
changing the total number of device resource(s) after deleting the piece of target device resource information corresponding to the target device driver (Paragraph 42; “after zonal scaling unit 370 has deleted pods-to-be-deleted from the weak levels first at operation 445”, “resource allocation unit 313 determines whether there are additional pods-to-be-deleted by determining whether a result set size subtracted from a total number of resources (e.g., replicas or pods) is less than a target number of resources (e.g., replicas or pods). In some embodiments, when the result set size subtracted from a total number of resources (e.g., replicas or pods) is not less than a target number of resources”, where the check for the target number of resources implies that the total number of device resources is updated with every change, thus corresponding to changing the total number of device resources);
performing an action when the total number of device resource(s) is equal to a target value (Paragraph 50; “in approving a result set, zonal scaling unit 370 determines whether the size of the result set subtracted from the total number of pods is greater than or equals to the number of zones. In some embodiments, when the size of the result set subtracted from the total number of pods is not greater than or equal to the number of zones, an email may be triggered”, which discloses an action in response to the total number of zones, corresponding to device resources, not being equal to a target value. It would have been obvious to a person of ordinary skill in the art to instead perform the action when the total number of device resources is equal to a target value as the selection of a specific comparison condition represents a known method yielding the predictable result of controlling when actions are triggered.).
Gutman, Pinto, Chong, and Raghavendran are considered to be analogous to the claimed invention because they are in the same field of software resource information allocation and deallocation. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gutman in view of Pinto further in view of Chong to incorporate the teachings of Raghavendran and have the target application resource information comprise a total number of device resources; and change the total number of device resource(s) after deleting the piece of target device resource information corresponding to the target device driver. A person of ordinary skill in the art would have recognized that maintaining and updating resource counts in response to allocation or deallocation is a known resource management technique yielding the predictable result of accurately tracking resource usage.
Claim 10 recites similar limitations as those of claim 3. Claim 10 is rejected for similar reasons as those of claim 3.
Claims 4 and 6 are rejected under 35 U.S.C. 103 as being unpatentable over Gutman in view of Pinto, further in view of Chong, further in view of Mitra et al. (US 20210208944 A1) hereafter Mitra.
Regarding claim 4, Gutman in view of Pinto, further in view of Chong teaches the method of claim 1. Gutman teaches:
The first store (Paragraph 115; “System 400 includes a configuration datastore 402”, corresponding to the first storage.).
Pinto teaches:
A first list (Paragraph 76; “In some embodiments, a programming interface library 421 may maintain a list or other data structure to track resources any computational resources 406 across one or more computational devices 402.”);
a target device driver comprising a piece of target application resource information (Paragraph 22; “trap mechanism may gain control of an application's operation based on an action such as an exit of an application (e.g., conditionally and/or unconditionally), a stopping of a container, a shutdown of a VM, and/or the like. As another example, in some embodiments, a debug hook may trigger the execution of profiling code to understand a flow of resources and/or determine a remedial action by a resource management scheme.”, in which the trap mechanism determines the target device driver associated with a given application upon exit, as further evidenced in Paragraph 70, “any portion of a computational resource manager 428 may be implemented (e.g., run) in any suitable location, for example, anywhere in kernel space 419 (e.g., as part of a device driver, a service, and/or the like), anywhere in user space 420 (e.g., as part of a library, an application, an application adapter, and/or the like)”);
abnormal exit (Paragraph 62; “the application terminates after a computational device 302 to which the command was directed began processing the request but before the computational device 302 has finished processing the request (e.g., the request has been read from the submission queue, but a corresponding completion has not been placed in a completion queue), the computational resource manager 328 may complete the request (e.g. with an error status)”, where the termination before finishing processing corresponds to an abnormal exit.).
Gutman in view of Pinto further in view of Chong does not teach wherein the at least one piece of device resource information comprises a device resource usage count; creating the piece of target application resource information of the target application in the first list before the abnormal exit procedure of the target application; and changing the device resource usage count.
However, Mitra teaches:
wherein the at least one piece of device resource information comprises a device resource usage count (Paragraph 31; “request may further include a definition of the task list (work queue) upon which the relevant pooled threads operate and a count field that can be used by the generic service to compute the number of tasks currently waiting in the queue at any given time. Embodiments incorporating the count field as an attribute of the management request can save the generic service from having to enumerate over the tasks in the work queue to get the count for itself.”, the count field corresponding to the device resource usage count.);
creating the piece of target application resource information of the target before the exit procedure of the target application (Paragraph 22; “exit lambda may cause a thread which executes it to create a state representation of itself before it terminates. Specifically, the exit routine executed by the thread may cause the creation of an object representing the state information of the thread immediately prior to its exit sequence”, the state representation corresponding to the piece of target application resource information of the target application, occurring before the exit sequence corresponding to before the abnormal exit procedure of the target application.);
and changing the device resource usage count (Paragraph 31; “request may further include a definition of the task list (work queue) upon which the relevant pooled threads operate and a count field that can be used by the generic service to compute the number of tasks currently waiting in the queue at any given time. Embodiments incorporating the count field as an attribute of the management request can save the generic service from having to enumerate over the tasks in the work queue to get the count for itself.”, the number of tasks in the task list associated with the device corresponds to the device resource usage count.).
Gutman, Pinto, Chong, and Mitra are considered to be analogous to the claimed invention because they are in the same field of software resource information allocation and deallocation. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gutman in view of Pinto further in view of Chong to incorporate the teachings of Mitra and have the at least one piece of device resource information comprise a device resource usage count; create the piece of target application resource information of the target before the abnormal exit procedure of the target application; and change the device resource usage count. A person of ordinary skill in the art would have recognized that reference counting and pre-allocation tracking are known techniques whose implementation would yield the predictable result of enabling accurate resource management and cleanup.
Regarding claim 6, Gutman in view of Pinto, further in view of Chong teach the method of claim 1. Gutman in view of Pinto, further in view of Chong does not teach determining the piece of target device resource information from the target device driver in response to a normal exit procedure of the target application; and changing the device resource usage count.
However, Mitra teaches:
determining the piece of target device resource information from the target device driver in response to a normal exit procedure of the target application (Paragraph 22; “exit lambda may cause a thread which executes it to create a state representation of itself before it terminates. Specifically, the exit routine executed by the thread may cause the creation of an object representing the state information of the thread immediately prior to its exit sequence”, the state representation corresponding to the piece of target application resource information of the target application, occurring before the exit sequence corresponding to before the normal exit procedure of the target application, of which the searched system is the driver running the application.);
and changing the device resource usage count (Paragraph 31; “request may further include a definition of the task list (work queue) upon which the relevant pooled threads operate and a count field that can be used by the generic service to compute the number of tasks currently waiting in the queue at any given time. Embodiments incorporating the count field as an attribute of the management request can save the generic service from having to enumerate over the tasks in the work queue to get the count for itself.”, the number of tasks in the task list associated with the device corresponds to the device resource usage count).
Gutman, Pinto, Chong, and Mitra are considered to be analogous to the claimed invention because they are in the same field of software resource information allocation and deallocation. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gutman in view of Pinto further in view of Chong to incorporate the teachings of Mitra and have the at least one piece of device resource information comprise a device resource usage count; create the piece of target application resource information of the target before the normal exit procedure of the target application; and change the device resource usage count. A person of ordinary skill in the art would have recognized that reference counting and pre-allocation tracking are known techniques whose implementation would yield the predictable result of enabling accurate resource management and cleanup.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Gutman in view of Pinto, further in view of Chong, further in view of Mitra, further in view of Kubis et al. (US 20200319934 A1) hereafter Kubis.
Regarding claim 5, Gutman in view of Pinto, further in view of Chong teach the method of claim 1. Gutman teaches:
The first store (Paragraph 115; “System 400 includes a configuration datastore 402”, corresponding to the first storage.).
Pinto teaches:
A first list (Paragraph 76; “In some embodiments, a programming interface library 421 may maintain a list or other data structure to track resources any computational resources 406 across one or more computational devices 402.”);
A target device driver (Paragraph 22; “trap mechanism may gain control of an application's operation based on an action such as an exit of an application (e.g., conditionally and/or unconditionally), a stopping of a container, a shutdown of a VM, and/or the like. As another example, in some embodiments, a debug hook may trigger the execution of profiling code to understand a flow of resources and/or determine a remedial action by a resource management scheme.”, in which the trap mechanism determines the target device driver associated with a given application upon exit, as further evidenced in Paragraph 70, “any portion of a computational resource manager 428 may be implemented (e.g., run) in any suitable location, for example, anywhere in kernel space 419 (e.g., as part of a device driver, a service, and/or the like), anywhere in user space 420 (e.g., as part of a library, an application, an application adapter, and/or the like)”).
Gutman in view of Pinto further in view of Chong does not teach creating the piece of target application resource information of the target application before the abnormal exit procedure of the target application; or creating the piece of target device resource information when the target device driver does not comprise the piece of target device resource information.
However, Mitra teaches:
creating the piece of target application resource information of the target before the abnormal exit procedure of the target application (Paragraph 22; “exit lambda may cause a thread which executes it to create a state representation of itself before it terminates. Specifically, the exit routine executed by the thread may cause the creation of an object representing the state information of the thread immediately prior to its exit sequence”, the state representation corresponding to the piece of target application resource information of the target application, occurring before the exit sequence corresponding to before the abnormal exit procedure of the target application.).
Gutman, Pinto, Chong and Mitra are considered to be analogous to the claimed invention because they are in the same field of software resource information allocation and deallocation. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gutman in view of Pinto further in view of Chong to incorporate the teachings of Mitra and create the piece of target application resource information of the target before the abnormal exit procedure of the target application. A person of ordinary skill in the art would have recognized that reference counting and pre-allocation tracking are known techniques whose implementation would yield the predictable result of enabling accurate resource management and cleanup.
Gutman in view of Pinto, further in view of Chong, further in view of Mitra does not teach creating the piece of target device resource information when the target does not comprise the piece of target device resource information.
However, Kubis teaches:
creating the piece of target device resource information when the target does not comprises the piece of target device resource information (Paragraph 20; “communicating the respective secondary program status information and/or the new data to the primary program via the agent includes writing the respective secondary program status information and/or the new data into a file”, where the writing of new data implies that the target did not comprise the target device resource information beforehand.).
Gutman, Pinto, Chong, Mitra, and Kubis are considered to be analogous to the claimed invention because they are in the same field of software resource information allocation and deallocation. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gutman in view of Pinto, further in view of Mitra to incorporate the teachings of Kubis and have created the piece of target device resource information when the target does not comprise the piece of target device resource information. A person of ordinary skill in the art would have recognized that initializing missing resource tracking entries is a known technique whose implementation would yield the predictable result of ensuring proper tracking and management of resources.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Gutman in view of Pinto, further in view of Chong, further in view of Mitra, further in view of Hepworth et al. (US 20040163051 A1) hereafter Hepworth, further in view of Raghavendran.
Regarding claim 7, Gutman in view of Pinto, further in view of Chong, further in view of Mitra teach the method of claim 6. Pinto teaches:
freeing a device resource corresponding to the at least one piece of device resource information (Paragraph 88; “The computational resource manager may also track some or all allocations of computational resources for some or all applications and/or computational devices and free resources that may have been allocated to an application and/or clear requests submitted by an application, for example, when an application terminates.”, the freeing of resources upon notification of application termination corresponding to freeing a device resource corresponding to the at least one piece of device resource information).
Gutman in view of Pinto, further in view of Chong, further in view of Mitra does not teach removing the at least one piece of device resource information from the at least one device driver when the device resource usage count is equal to a target value.
However, Hepworth teaches:
removing the at least one piece of device resource information from the at least one device driver (Paragraph 222; “the filter driver 1330 may be configured to delete the object identifier data 1310 by sending it 1310 to an internal sink 1340.”).
Gutman, Pinto, Chong, Mitra, and Hepworth are considered to be analogous to the claimed invention because they are in the same field of software resource information allocation and deallocation. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gutman in view of Pinto, further in view of Chong, further in view of Mitra to incorporate the teachings of Hepworth and remove device resource information from the device driver. A person of ordinary skill in the art would have recognized that the removal of unnecessary information from the device driver in response to an application exit is a known method in the art yielding the predictable result of lowering overhead.
Gutman in view of Pinto, further in view of Chong, further in view of Mitra, further in view of Hepworth does not teach performing an action when the device resource usage count is equal to a target value.
However, Raghavendran teaches:
performing an action when the device resource usage count is equal to a target value (Paragraph 50; “in approving a result set, zonal scaling unit 370 determines whether the size of the result set subtracted from the total number of pods is greater than or equals to the number of zones. In some embodiments, when the size of the result set subtracted from the total number of pods is not greater than or equal to the number of zones, an email may be triggered”, which discloses an action in response to the total number of zones, corresponding to device resources, not being equal to a target value.).
Gutman, Pinto, Chong, Mitra, Hepworth, and Raghavendran are considered to be analogous to the claimed invention because they are in the same field of software resource information allocation and deallocation. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gutman in view of Pinto, further in view of Chong, further in view of Mitra, further in view of Hepworth to incorporate the teachings of Raghavendran and have performed an action when the device resource usage count is equal to a target value It would have been obvious to a person of ordinary skill in the art to instead perform the action when the total number of device resources is equal to a target value as the selection of a specific comparison condition represents a known method yielding the predictable result of controlling when actions are triggered.
Claims 11-13 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Gutman in view of Pinto, further in view of Mitra, further in view of Kubis.
Regarding claim 11, Gutman teaches:
An electronic device executing a plurality of applications (Paragraph 96; “Registry 258, e.g., a WINDOWS registry, represents a database or other collection of data of low-level settings for the OS 220 and for applications 244 of computing device 200 that are configured to use the registry 258”, applications 224 is plural), comprising:
a memory (Paragraph 68; “The computing device 200 can also include at least one memory”) configured to store a first store and a second list (Paragraphs 115, 121; “System 400 includes a configuration datastore 402”, corresponding to the first storage, and further contains “a list of active drivers.”, corresponding to the second list.);
wherein the first store comprises at least one piece of application resource information (Paragraphs 115-118; “System 400 includes a configuration datastore 402, which can represent registry 258, the WINDOWS device metadata store that holds device-property values, or another datastore that can retain values, e.g., across system reboots”, which includes “writing at least one driver-configuration entry 404 to configuration datastore 402”. Entries written to the config datastore correspond to the at least one piece of application resource information, as evidenced by “The driver-configuration entry 404 can include, e.g., a registry key, device property, device interface property, or other entry. The driver-configuration entry 404 can include an interface version or other configuration used by application 244”);
the second list comprises at least one device driver (Paragraph 121; “In response to flag 408, OS 220 can remove first driver 226 from display in, or refrain from adding first driver 226 to, a list of active drivers.”, list of active drivers corresponds to the second list);
the at least one piece of application resource information corresponds to the at least one device driver (Paragraph 118; “The driver-configuration entry 404 can include, e.g., a registry key, device property, device interface property, or other entry. The driver-configuration entry 404 can include an interface version or other configuration used by application 244”, each application has a corresponding driver config entry);
each device driver corresponds to at least one piece of device resource information (Paragraph 118; “The driver-configuration entry 404 can include, e.g., a registry key, device property, device interface property, or other entry. The driver-configuration entry 404 can include an interface version or other configuration used by application 244”, each driver config entry having a corresponding device property, corresponding to device resource information);
an application circuit (Paragraph 65; “For example, processing units 210 can be or include Field-programmable Gate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs)”);
and a processing circuit coupled to the memory and the application circuit (Paragraphs 68-69; “Processing units 210 can include or be operably coupled to memory 214, 216.”; “a “control unit” as described herein includes processing units 210. A control unit can also include, if required, memory 214, 216. For example, a control unit can include a CPU or DSP and a computer storage medium or other tangible, non-transitory computer-readable medium storing instructions executable by that CPU or DSP to cause that CPU or DSP to perform functions described herein. Additionally or alternatively, a control unit can include an ASIC, FPGA, or other logic device(s)”) and configured to perform following steps:
executing a target application corresponding to the application circuit, wherein the target application is one of the applications (Paragraph 87; “an application 244, e.g., a user program or system-service application, is loaded into user space 240. Application 244 communicates with first driver 226 loaded into kernel space 242 to access enumerable-bus devices.”, which runs on a processing unit, and corresponds to an ASIC as disclosed in Paragraph 65; “processing units 210 can be or include Field-programmable Gate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs)”.);
searching for a target device driver associated with the target application according to the piece of target application resource information (Paragraphs 163-164; “Operation 718 can include, e.g., determining that the ERRORLEVEL or process exit code from an installation package is nonzero, that an HRESULT or other return value from an installation routine is an error (e.g., −1) or S_FALSE return, or that another system component has flagged an error”, the installation package associated with a target application, in which in response, “the control unit can roll back the installation operations 606. Operation 722 can be performed in response to, or after, operation 718. Operation 722 can include creating, removing, or modifying files or configuration entries, or performing other operations described herein with reference to installation operations 606 in order to reverse the effects of those operations”, the modification of configuration entries corresponding to a target application resource requiring the particular configuration entry be found prior to modification, thus corresponding to the first store being searched for target application resource information).
Gutman does not teach a first list; the first list being maintained during execution of the applications; each corresponding to a respective one of the applications being executed; creating a piece of target application resource information of the target application in the first store; and creating a piece of target device resource information when the target device driver does not comprise the piece of target device resource information; or wherein the piece of target device resource information corresponds to the target device driver and is recorded in a device resource information list used by the target device driver.
However, Pinto teaches:
A first list (Paragraph 76; “In some embodiments, a programming interface library 421 may maintain a list or other data structure to track resources any computational resources 406 across one or more computational devices 402.”);
the first list being maintained during execution of the applications (Paragraph 76; “For example, when one or more resources are allocated to an application, the programming interface library 421 may add a handle for the resources to the list, and when one or more resources are freed (e.g., by an application), the programming interface library 421 may remove the corresponding handle from the list.” The list exists before and after execution of the application, therefore being maintained during execution of the application.);
each corresponding to a respective one of the applications being executed (Paragraph 76; “For example, when one or more resources are allocated to an application, the programming interface library 421 may add a handle for the resources to the list, and when one or more resources are freed (e.g., by an application), the programming interface library 421 may remove the corresponding handle from the list.”, which discloses resources allocated to one or more applications, tracking resources allocated to applications, and a list that tracks compute resources across devices.);
wherein the piece of target device resource information corresponds to the target device driver and is recorded in a device resource information list used by the target device driver (Paragraph 92; “pseudocode illustrated in Table 2 may be called by a computational resource manager to free and/or remove one or more resources from a tracking list, for example, when an application such as a program terminates (e.g., crashes). In some embodiments, the pseudocode may also be called when an application exits normally. For example, operating system hooks may be installed to trap the exit which in turn may call unwind( )”, where the resources, corresponding to target device resource information, in the tracking list, correspond to the device resource information list, is used by the computational resource manager which may be implemented as part of a driver, as evidenced by Paragraph 70; “computational resource manager 428 may be implemented (e.g., run) in any suitable location, for example, anywhere in kernel space 419 (e.g., as part of a device driver, a service, and/or the like)”).
Gutman and Pinto are considered to be analogous to the claimed invention because they are in the same field of software resource information allocation and deallocation. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gutman to incorporate the teachings of Pinto and have the first store be a list. A person of ordinary skill in the art would have recognized from the disclosure of Pinto that any other data structure may be used to track application resource information, evidenced by “a list or other data structure to track resources”, and would have found a list to be one such known alternative data structure yielding the predictable result of tracking resources. Further, a person of ordinary skill in the art would have further recognized maintaining resource information during execution as a known technique in cloud computing for monitoring and managing resources utilized by the application, whose implementation would yield the predictable result of keeping the resource information available for use in managing the application’s resources during execution. A person of ordinary skill in the art would have found it obvious to associate each item of application resource information with a respective application being executed, because maintaining resource information associated with each consumer is a known method in cloud computing for tracking compute resources allocated among multiple consumers, whose implementation would yield the predictable result of identifying resources allocated to each respective consumer. A person of ordinary skill in the art would have recognized a mapping between device resource information and device drivers recorded in a list to be used by the target device driver to be a known method for tracking resource state, whose implementation would yield the predictable result of proper monitoring of device resources during execution.
Gutman in view of Pinto does not teach creating a piece of target application resource information of the target application in the first store; and creating a piece of target device resource information when the target device driver does not comprise the piece of target device resource information.
However, Mitra teaches:
creating a piece of target application resource information of the target application in the first store (Paragraph 22; “exit lambda may cause a thread which executes it to create a state representation of itself before it terminates. Specifically, the exit routine executed by the thread may cause the creation of an object representing the state information of the thread immediately prior to its exit sequence”, the state representation corresponding to the piece of target application resource information of the target application, occurring before the exit sequence corresponding to before the abnormal exit procedure of the target application.).
Gutman, Pinto, and Mitra are considered to be analogous to the claimed invention because they are in the same field of software resource information allocation and deallocation. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gutman in view of Pinto to incorporate the teachings of Mitra and create the piece of target application resource information of the target within the first storage of Gutman in view of Pinto. A person of ordinary skill in the art would have recognized that reference counting and pre-allocation tracking are known techniques whose implementation would yield the predictable result of enabling accurate resource management and cleanup.
Gutman in view of Pinto, further in view of Mitra does not teach creating a piece of target device resource information when the target device driver does not comprise the piece of target device resource information.
However, Kubis teaches:
creating a piece of resource information when the device does not comprise the piece of resource information (Paragraph 20; “communicating the respective secondary program status information and/or the new data to the primary program via the agent includes writing the respective secondary program status information and/or the new data into a file”, where the writing of new data implies that the target did not comprise the resource information beforehand.).
Gutman, Pinto, Mitra, and Kubis are considered to be analogous to the claimed invention because they are in the same field of software resource information allocation and deallocation. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gutman in view of Pinto, further in view of Mitra to incorporate the teachings of Kubis and have created the piece of target device resource information when the target does not comprise the piece of target device resource information. A person of ordinary skill in the art would have been motivated to incorporate such a conditional writing operation to avoid redundant creation of information already present. Because the purpose of a tracking list, such as that in Pinto (Paragraph 92) is to maintain a representation of tracked resources, a person of ordinary skill in the art would recognize that creation of an additional entry for resource information already represented in the tracker would result in redundant resource information and could result in inaccurate tracking. Further, the list is utilized to free/remove resources upon application termination, and duplicate entries would be recognized as requiring redundant processing or could cause inaccurate representations. Therefore, when applying Kubis’s technique of writing new data to the resource tracking arrangement, a person of ordinary skill in the art would have had reason to check whether the corresponding resource information was already present and perform the write when absent. Implementing the known write operation of Kubis conditionally based on whether the information is already present would have yielded the predictable result of creating the resource information when absent and avoiding redundant creation otherwise.
Regarding claim 12, Gutman in view of Pinto, further in view of Mitra, further in view of Kubis teach the electronic device of claim 11. Pinto teaches:
a target device driver comprising a piece of target application resource information (Paragraph 22; “trap mechanism may gain control of an application's operation based on an action such as an exit of an application (e.g., conditionally and/or unconditionally), a stopping of a container, a shutdown of a VM, and/or the like. As another example, in some embodiments, a debug hook may trigger the execution of profiling code to understand a flow of resources and/or determine a remedial action by a resource management scheme.”, in which the trap mechanism determines the target device driver associated with a given application upon exit, as further evidenced in Paragraph 70, “any portion of a computational resource manager 428 may be implemented (e.g., run) in any suitable location, for example, anywhere in kernel space 419 (e.g., as part of a device driver, a service, and/or the like), anywhere in user space 420 (e.g., as part of a library, an application, an application adapter, and/or the like)”).
Mitra teaches:
wherein the at least one piece of device resource information comprises a device resource usage count (Paragraph 31; “request may further include a definition of the task list (work queue) upon which the relevant pooled threads operate and a count field that can be used by the generic service to compute the number of tasks currently waiting in the queue at any given time. Embodiments incorporating the count field as an attribute of the management request can save the generic service from having to enumerate over the tasks in the work queue to get the count for itself.”, the count field corresponding to the device resource usage count.);
and changing the device resource usage count (Paragraph 31; “request may further include a definition of the task list (work queue) upon which the relevant pooled threads operate and a count field that can be used by the generic service to compute the number of tasks currently waiting in the queue at any given time. Embodiments incorporating the count field as an attribute of the management request can save the generic service from having to enumerate over the tasks in the work queue to get the count for itself.”, the number of tasks in the task list associated with the device corresponds to the device resource usage count.).
Regarding claim 13, Gutman in view of Pinto, further in view of Mitra, further in view of Kubis teach the device of claim 11. Mitra teaches:
searching the target device driver for the piece of target device resource information in response to a normal exit procedure of the target application (Paragraph 22; “exit lambda may cause a thread which executes it to create a state representation of itself before it terminates. Specifically, the exit routine executed by the thread may cause the creation of an object representing the state information of the thread immediately prior to its exit sequence”, the state representation corresponding to the piece of target application resource information of the target application, occurring before the exit sequence corresponding to before the normal exit procedure of the target application, of which the searched system is the driver running the application.);
and changing the device resource usage count (Paragraph 31; “request may further include a definition of the task list (work queue) upon which the relevant pooled threads operate and a count field that can be used by the generic service to compute the number of tasks currently waiting in the queue at any given time. Embodiments incorporating the count field as an attribute of the management request can save the generic service from having to enumerate over the tasks in the work queue to get the count for itself.”, the number of tasks in the task list associated with the device corresponds to the device resource usage count).
Regarding claim 15, Gutman in view of Pinto, further in view of Mitra, further in view of Kubis teaches the device of claim 13. Gutman teaches:
A second list (Paragraph 121; “a list of active drivers.”, corresponds to the second list).
searching the first list for the piece of target application resource information corresponding to the target application in response to an abnormal exit procedure of the target application (Paragraphs 163-164; “Operation 718 can include, e.g., determining that the ERRORLEVEL or process exit code from an installation package is nonzero, that an HRESULT or other return value from an installation routine is an error (e.g., −1) or S_FALSE return, or that another system component has flagged an error”, the installation package associated with a target application, in which in response, “the control unit can roll back the installation operations 606. Operation 722 can be performed in response to, or after, operation 718. Operation 722 can include creating, removing, or modifying files or configuration entries, or performing other operations described herein with reference to installation operations 606 in order to reverse the effects of those operations”, the modification of configuration entries corresponding to a target application resource requiring the particular configuration entry be found prior to modification, thus corresponding to the first store being searched for target application resource information in response to an abnormal exit).
Pinto teaches:
determining the target device driver according to the piece of target application resource information (Paragraph 22; “trap mechanism may gain control of an application's operation based on an action such as an exit of an application (e.g., conditionally and/or unconditionally), a stopping of a container, a shutdown of a VM, and/or the like. As another example, in some embodiments, a debug hook may trigger the execution of profiling code to understand a flow of resources and/or determine a remedial action by a resource management scheme.”, in which the trap mechanism determines the target device driver associated with a given application upon exit, as further evidenced in Paragraph 70, “any portion of a computational resource manager 428 may be implemented (e.g., run) in any suitable location, for example, anywhere in kernel space 419 (e.g., as part of a device driver, a service, and/or the like), anywhere in user space 420 (e.g., as part of a library, an application, an application adapter, and/or the like)”);
and deleting the piece of target device resource information (Paragraph 92; “pseudocode illustrated in Table 2 may be called by a computational resource manager to free and/or remove one or more resources from a tracking list, for example, when an application such as a program terminates (e.g., crashes). In some embodiments, the pseudocode may also be called when an application exits normally. For example, operating system hooks may be installed to trap the exit which in turn may call unwind( ).”, the resources corresponding to the piece of target device resource information corresponding to the target device driver.).
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Gutman in view of Pinto, further in view of Mitra, further in view of Kubis, further in view of Hepworth, further in view of Raghavendran.
Regarding claim 14, Gutman in view of Pinto, further in view of Mitra, further in view of Kubis teach the device of claim 13. Pinto teaches:
freeing a device resource corresponding to the at least one piece of device resource information (Paragraph 88; “The computational resource manager may also track some or all allocations of computational resources for some or all applications and/or computational devices and free resources that may have been allocated to an application and/or clear requests submitted by an application, for example, when an application terminates.”, the freeing of resources upon notification of application termination corresponding to freeing a device resource corresponding to the at least one piece of device resource information).
Gutman in view of Pinto, further in view of Mitra, further in view of Kubis does not teach removing the at least one piece of device resource information from the at least one device driver when the device resource usage count is equal to a target value.
However, Hepworth teaches:
removing the at least one piece of device resource information from the at least one device driver (Paragraph 222; “the filter driver 1330 may be configured to delete the object identifier data 1310 by sending it 1310 to an internal sink 1340.”).
Gutman, Pinto, Mitra, Kubis, and Hepworth are considered to be analogous to the claimed invention because they are in the same field of software resource information allocation and deallocation. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gutman in view of Pinto, further in view of Mitra, further in view of Kubis to incorporate the teachings of Hepworth and remove device resource information from the device driver. A person of ordinary skill in the art would have recognized that the removal of unnecessary information from the device driver in response to an application exit is a known method in the art yielding the predictable result of lowering overhead.
Gutman in view of Pinto, further in view of Mitra, further in view of Kubis, further in view of Hepworth does not teach performing an action when the device resource usage count is equal to a target value.
However, Raghavendran teaches:
performing an action when the device resource usage count is equal to a target value (Paragraph 50; “in approving a result set, zonal scaling unit 370 determines whether the size of the result set subtracted from the total number of pods is greater than or equals to the number of zones. In some embodiments, when the size of the result set subtracted from the total number of pods is not greater than or equal to the number of zones, an email may be triggered”, which discloses an action in response to the total number of zones, corresponding to device resources, not being equal to a target value.).
Gutman, Pinto, Mitra, Kubis, Hepworth, and Raghavendran are considered to be analogous to the claimed invention because they are in the same field of software resource information allocation and deallocation. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gutman in view of Pinto, further in view of Mitra, further in view of Kubis, further in view of Hepworth to incorporate the teachings of Raghavendran and have performed an action when the device resource usage count is equal to a target value It would have been obvious to a person of ordinary skill in the art to instead perform the action when the total number of device resources is equal to a target value as the selection of a specific comparison condition represents a known method yielding the predictable result of controlling when actions are triggered.
Response to Arguments
Applicant's arguments filed 07/16/2026 have been fully considered. Applicant’s arguments are summarized below:
Gutman in view of Pinto does not teach the limitations recited by amended claims 1 and 8.
Gutman does not teach the claimed first list/second list correspondence, nor a per-driver device resource information list. Pinto fails to cure these deficiencies, and the combination would destroy the fundamental operational principle of Pinto.
Raghavendran does not teach “deleting the piece of target device resource information from the second list when the level is a target value” because the two schemes are logically different.
Raghavendran solves a different technical problem with different technical effects and is non-analogous art.
Gutman in view of Pinto fail to teach the base architecture of claim 11.
Mitra does not teach creating application resource information during execution as claimed.
Kubis does not teach the create-if-absent condition as claimed.
Dependent claims ae submitted as allowable for at least the above reasons.
Examiner’s response:
The Examiner agrees that Gutman fails to teach an abnormal exit triggered by a system exception during application execution as recited by amended claims 1 and 8. Accordingly, the previous rejection of claims 1 and 8 under 35 U.S.C. 103 are withdrawn. However, upon further consideration, a new ground(s) of rejection is made under 35 U.S.C. 103 in view of Gutman, Pinto, and Chong.
The Examiner respectfully disagrees. The rejection does not rely on Gutman in isolation to disclose the claimed correspondence and list arrangement. Gutman is relied upon for driver configuration information (Paragraph 118) whereas Pinto is relied upon for the recording and maintaining information identifying resources allocated to applications in a list structure (Paragraph 76), the combination of which would have been obvious to a person of ordinary skill in the art due to tracking and managing resources being a known concept in cloud computing yielding the predictable result of identifying resources associated with particular applications. With regard to the fundamental operational principle argument, the rejection does not propose modification of Pinto’s centralized resource manager. The reliance on Pinto is for its teaching of resource information maintained in a list to track resources allocated to applications, and applies that known list-based resource-tracking technique to the device resource information of Gutman. A person of ordinary skill in the art would have found obvious that the identification of a target resource of Pinto would therefore also identify a target device driver that contains the information according to the resource. The proposed combination therefore does not require eliminating, disabling, or otherwise altering the centralized resource manager of Pinto. Accordingly, contrary to Applicant’s arguments, the proposed modification does not destroy the fundamental operating principle of Pinto because Pinto itself is not being modified.
The Examiner respectfully disagrees. Raghavendran (Paragraph 41) discloses that, in response to a deletion request, a strength level determination unit determines whether levels in the zonal topology have been identified and marked as weak. That is, when such levels are identified, the zonal scaling unit deletes pods from the weak levels. Thus, the identified level condition is evaluated in connection with the deletion operation and satisfaction of the condition results in deletion of the corresponding resources. Accordingly, contrary to Applicant’s arguments, the characterization of the level as merely a selector of a deletion path does not distinguish the claimed checking of the level and deletion of the resource information based on the checked level.
With regard to the argument that the two references solve different technical problems, Raghavendran (Paragraph 41) discloses receiving a deletion request, determining whether levels have been identified and marked as weak, and after identification, performing the associated deletion. Raghavendran’s deletion request in the context of managing “weak levels” and system stability does not negate the disclosed resource deletion mechanism upon a condition being met, the abnormal exit condition mapped in claim 1, and the methodology for performing the deletion mapped in claims 2 and 9. Therefore, the technical problem to be solved, a deletion of resource information if a particular level is met, is analogous between the inventions. With regard to the analogous art test, Raghavendran is reasonable pertinent to the problem addressed by the claimed invention because Raghavendran expressly concerns the management, allocation, and deletion of computational resources during operation of a computing system. Paragraph 41 receives a deletion request, determines resource levels associated with the resources, and deletes resources from identified levels. Thus, Raghavendran addresses the same type of technical consideration implicated by the claimed resource release operation by determining which computational resources to delete based on information associated with those resources. Raghavendran’s disclosure provides a pertinent teaching concerning resource deletion and management and is therefore reasonably pertinent to the claimed resource release problem.
The portion explained for claim 1 is explained in argument B. With regard to the “searching” limitation, the Examiner respectfully disagrees. Gutman (Paragraphs 163-164) discloses that, upon detecting failure of an operation, the control unit performs a rollback that may include creating, removing, or modifying configuration entries. In order to perform the disclosed modification of the configuration entries associated with the target application resources, a person of ordinary skill in the art would recognize as obvious that they must first be located. The act of locating the configuration information corresponding to the target application resource constitutes searching for the corresponding device driver information. Pinto further teaches managing resources associated with an application and determining a remedial action in response to application termination. Accordingly, the combination of Gutman and Pinto renders obvious searching for a target device driver associated with the target application according to the piece of target application resource information. With regard to the “piece of target device resource information” argument, the Examiner respectfully disagrees. Gutman (Paragraph 121) establishes the device-driver environment while Pinto (Paragraph 92) supplies the resource tracking list arrangement, disclosing a tracking list for computational resources used to free and/or remove resources when an application terminates. Pinto (Paragraph 70) additionally discloses that a computational resource manager may be implemented as part of a device driver. Thus, it would have been obvious to implement resource tracking functionality of Pinto, including its tracking list, into the device driver environment of Gutman such that the resource information associated with a respective device driver is maintained by the corresponding device driver.
The Examiner agrees that Mitra teaches creation of a state representation during execution. Paragraph 22 discloses the use of an exit routine in which a thread creates a state representation of a thread prior to termination and store it for subsequent use, thus teaching creating information associated with an executing computational entity during execution, which contains information associated with the application resource. However, the proposed combination is for Mitra’s creation of application resource information in combination with the list-entry organization and the application resource information of Gutman motivated by the need to maintain resource tracking information for processing associated with termination of applications.
Applicant’s argument against the mapping of Kubus is considered but moot as the mapping is updated in view of the amended claim language to clarify the respective disclosures relied upon for the claimed application resource information.
Independent claims 1, 8, and 11 remain rejected for the reasons stated above. Therefore, contrary to Applicant's arguments, because the dependent claims depend from an unpatentable claim and does not add limitations that overcome the rejection, it likewise remains rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Lee et al. (US 20090158297 A1) discusses searching the module device in the device driver list of the kernel; invoking a module device release function from the kernel; and deleting the module device searched from the device driver list by using the module device release function.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KENNETH P TRAN whose telephone number is (571)272-6926. The examiner can normally be reached M-TH 4:30 a.m. - 12:30 p.m. PT, F 4:30 a.m. - 8:30 a.m. PT, or at Kenneth.Tran@uspto.gov.
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, April Blair can be reached at (571) 270-1014. 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.
/KENNETH P TRAN/Examiner, Art Unit 2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights