DETAILED ACTION
1. This Office Action is taken in response to Applicants’ Amendments and Remarks filed on 7/15/2026 regarding application 18/897,840 filed on 9/26/2024.
Claims 1-20 are pending for consideration.
2. Response to Amendments and Remarks
Applicants’ amendments and remarks have been fully and carefully considered, with the Examiner’s response set forth below.
(1) In response to the amendments and remarks, an updated claim analysis has been made with additional, new reference(s). Refer to the corresponding sections of the following Office Action for details.
3. Examiner’s Note
(1) In the case of amending the Claimed invention, Applicant is respectfully requested to indicate the portion(s) of the specification which dictate(s) the structure relied on for proper interpretation and also to verify and ascertain the metes and bounds of the claimed invention. This will assist in expediting compact prosecution. MPEP 714.02 recites: “Applicant should also specifically point out the support for any amendments made to the disclosure. See MPEP § 2163.06. An amendment which does not comply with the provisions of 37 CFR 1.121(b), (c), (d), and (h) may be held not fully responsive. See MPEP § 714.” Amendments not pointing to specific support in the disclosure may be deemed as not complying with provisions of 37 C.F.R. 1.131(b), (c), (d), and (h) and therefore held not fully responsive. Generic statements such as “Applicants believe no new matter has been introduced” may be deemed insufficient.
(2) Examiner has cited particular columns/paragraph and line numbers in the references applied to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in 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.
4. Claims 1-3, 5-7, and 11-13, 15-17, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Yudanov et al. (US Patent Application Publication 2021/0103463, hereinafter Yudanov), and in view of Altenhofen et al. (US Patent Application Publication 2019/0303560, hereinafter Altenhofen).
As to claim 1, Yudanov teaches A method [A method, comprising: monitoring, in a mobile device, usage of a plurality of applications to determine memory access for each of the plurality of applications ... (claim 1)], comprising:
identifying access resolutions for a plurality of accessing agents [the corresponding “accessing agents” are “applications” running on a computing device accessing memory -- Customized root processes for groups of applications in a computing device. A computing device (e.g., a mobile device) can monitor usage of applications. The device can then store data related to the usage of the applications, and group the applications into groups according to the stored data. The device can customize and execute a root process for a group of applications according to usage common to each application in the group. The device can generate patterns of prior executions shared amongst the applications in the group based on the stored data common to each application in the group, and execute the root process of the group according to the patterns. The device can receive a request to start an application from the group from a user of the device, and start the application upon receiving the request and by using the root process of the group of applications (abstract); A method, comprising: monitoring, in a mobile device, usage of a plurality of applications to determine memory access for each of the plurality of applications; storing data related to the usage of the plurality of applications; grouping the plurality of applications into groups according to data related to usage of the plurality of applications; and customizing and executing a root process for a group of the groups of applications according to usage common to each application in the group (claim 1); The method of claim 1, wherein at least one of the monitoring, storing, grouping, or executing is performed by an operating system (OS) in the mobile device, and wherein determining memory access comprises measuring frequency or recency of reads from and writes to memory (claim 2)], the access resolutions including a first resolution associated with a first frequency at which a first accessing agent samples usage data for a memory resource and a second resolution associated with a second frequency at which a second access agent samples usage data for the memory resource [grouping applications into different groups according to their access frequencies – as shown in figure 1, where a plurality of applications (108a, 108b, ..., 108c) are grouped into multiple groups (106a-106c); figure 2, step 206, “group applications into groups according to the stored data;” Some embodiments disclosed herein relate to an OS or hypervisor or the like of one or more computing devices that is configured to monitor usage of one or more applications by a user in the one or more devices. For example, some embodiments can relate to an OS of a mobile device that is configured to monitor usage of multiple applications in the device by a user. The monitoring of applications can identify typical initial or historical or sampled reads or writes common to a group of applications that cause the OS, hypervisor, or the like to read from memory and write into memory for the group of applications. The monitoring can also include monitoring of usage patterns of related applications (e.g., data access patterns, typical day of week used by the user, time of day usually used, other applications used that correlate to use of the group of applications, etc.). The initial or historical or sampled reads and writes associated with a group of applications can be stored or cached in memory to be used via a respective root process particularly for the group of applications. The initial or historical or sampled reads and writes can be managed, maintained, prioritized etc., by the OS, hypervisor or the like, via the memory, according to frequency of use, recency of use, etc. In some embodiments, storing or caching can be done in faster memory for accelerating the initial reads and writes ... in anticipation of use of at least one application in the group of applications, the OS, hypervisor or the like can be configured to re-launch the root process of the group according to identified patterns in the monitoring of the group. Preference to patterns can be based on quantify, frequency and/or recency of the patterns, and any type of memory access patterns for the group of applications can be monitored and tracked ... Patterns can be based on metrics such as quantity, frequency and/or recency of reads from memory, writes to memory, address patterns in physical memory space, address patterns in virtual space, locality of data (spatially and/or temporally), bank conflicts, or CPU cycles per instruction. Patterns can also be based on metrics such as quantity, frequency and/or recency of translation lookaside buffer (TLB) metrics and other metrics available to an OS (¶ 0012-0014); In FIG. 2, the method 200 begins at step 202 with monitoring usage of a plurality of applications to determine memory access for each application. Step 202 can include monitoring usage of the applications to determine frequency or recency of reads from and writes to memory for the applications in a device such as a mobile device. In some embodiments, step 202 can include monitoring and/or tracking usage of the applications to determine quantity, frequency and/or recency of patterns of prior executions of the applications (¶ 0027); Some embodiments can include monitoring, by an OS in a mobile device, usage of a plurality of applications to determine frequency or recency of reads from and writes to memory for each of the plurality of applications—at step 202 ... (¶ 0075)], the plurality of accessing agents being implemented on a computing device [Customized root processes for groups of applications in a computing device. A computing device (e.g., a mobile device) can monitor usage of applications. The device can then store data related to the usage of the applications, and group the applications into groups according to the stored data. The device can customize and execute a root process for a group of applications according to usage common to each application in the group. The device can generate patterns of prior executions shared amongst the applications in the group based on the stored data common to each application in the group, and execute the root process of the group according to the patterns. The device can receive a request to start an application from the group from a user of the device, and start the application upon receiving the request and by using the root process of the group of applications (abstract)], the access resolutions including timing information associated with frequencies with which each of the first and second accessing agents are configured to access memory usage data for a memory resource [Some embodiments disclosed herein relate to an OS or hypervisor or the like of one or more computing devices that is configured to monitor usage of one or more applications by a user in the one or more devices. For example, some embodiments can relate to an OS of a mobile device that is configured to monitor usage of multiple applications in the device by a user. The monitoring of applications can identify typical initial or historical or sampled reads or writes common to a group of applications that cause the OS, hypervisor, or the like to read from memory and write into memory for the group of applications. The monitoring can also include monitoring of usage patterns of related applications (e.g., data access patterns, typical day of week used by the user, time of day usually used, other applications used that correlate to use of the group of applications, etc.). The initial or historical or sampled reads and writes associated with a group of applications can be stored or cached in memory to be used via a respective root process particularly for the group of applications. The initial or historical or sampled reads and writes can be managed, maintained, prioritized etc., by the OS, hypervisor or the like, via the memory, according to frequency of use, recency of use, etc. In some embodiments, storing or caching can be done in faster memory for accelerating the initial reads and writes ... in anticipation of use of at least one application in the group of applications, the OS, hypervisor or the like can be configured to re-launch the root process of the group according to identified patterns in the monitoring of the group. Preference to patterns can be based on quantify, frequency and/or recency of the patterns, and any type of memory access patterns for the group of applications can be monitored and tracked ... Patterns can be based on metrics such as quantity, frequency and/or recency of reads from memory, writes to memory, address patterns in physical memory space, address patterns in virtual space, locality of data (spatially and/or temporally), bank conflicts, or CPU cycles per instruction. Patterns can also be based on metrics such as quantity, frequency and/or recency of translation lookaside buffer (TLB) metrics and other metrics available to an OS (¶ 0012-0014); The method of claim 1, wherein at least one of the monitoring, storing, grouping, or executing is performed by an operating system (OS) in the mobile device, and wherein determining memory access comprises measuring frequency or recency of reads from and writes to memory (claim 2)];
determining a sample granularity including an access frequency based on a common factor of the access resolutions for the plurality of accessing agents [the corresponding “sample granularity” may be “typical day of week used by the user, time of day usually used” -- Customized root processes for groups of applications in a computing device. A computing device (e.g., a mobile device) can monitor usage of applications. The device can then store data related to the usage of the applications, and group the applications into groups according to the stored data. The device can customize and execute a root process for a group of applications according to usage common to each application in the group. The device can generate patterns of prior executions shared amongst the applications in the group based on the stored data common to each application in the group, and execute the root process of the group according to the patterns ... (abstract); Some embodiments disclosed herein relate to an OS or hypervisor or the like of one or more computing devices that is configured to monitor usage of one or more applications by a user in the one or more devices. For example, some embodiments can relate to an OS of a mobile device that is configured to monitor usage of multiple applications in the device by a user. The monitoring of applications can identify typical initial or historical or sampled reads or writes common to a group of applications that cause the OS, hypervisor, or the like to read from memory and write into memory for the group of applications. The monitoring can also include monitoring of usage patterns of related applications (e.g., data access patterns, typical day of week used by the user, time of day usually used, other applications used that correlate to use of the group of applications, etc.). The initial or historical or sampled reads and writes associated with a group of applications can be stored or cached in memory to be used via a respective root process particularly for the group of applications. The initial or historical or sampled reads and writes can be managed, maintained, prioritized etc., by the OS, hypervisor or the like, via the memory, according to frequency of use, recency of use, etc. In some embodiments, storing or caching can be done in faster memory for accelerating the initial reads and writes ... in anticipation of use of at least one application in the group of applications, the OS, hypervisor or the like can be configured to re-launch the root process of the group according to identified patterns in the monitoring of the group. Preference to patterns can be based on quantify, frequency and/or recency of the patterns, and any type of memory access patterns for the group of applications can be monitored and tracked ... (¶ 0012-0014); ... The root process of a group of applications (e.g., see root processes 110, 112, and 114) can also be customized and executed according to usage data common to each application in the group (e.g., see application usage data 116a, 116b, and 116c which can include common data that links applications 108a, 108b, and 108c). The commonality between usage data of applications in a group can be determined via logical connections (e.g., see logical connections 118) (¶ 0047); ... And, method 500 includes the step 208 of customizing and executing a root process for a group of the groups of applications according to usage common to each application in the group, as well as repeating step 208 for each group of the groups of applications at step 210 (¶ 0052);
Altenhofen more expressively teaches this limitation -- In some embodiments, detecting the pattern may be performed in various ways. For example, detecting the pattern may comprise determining, by the server computer, that the at least a portion of the set of the plurality of access requests involve a recurring access request indicator. In another example, detecting the pattern may comprise determining, by the server computer, one or more of (1) a common frequency between the at least a portion of the set of the plurality of access requests, (2) a common access request amount for the at least a portion of the set of the plurality of access requests, (3) a common day shared by the at least a portion of the set of the plurality of access requests, and (4) a common time shared by the at least a portion of the set of the plurality of access requests (¶ 0007)];
obtaining samples of memory usage data at the access frequency indicated by the sample granularity, wherein the samples of memory usage data for the memory resource include access metrics associated with access instances to the memory resource by the plurality of accessing agents on the computing device, and wherein the access metrics are tracked by one or more memory controllers that manage access to the memory resource [Some embodiments disclosed herein relate to an OS or hypervisor or the like of one or more computing devices that is configured to monitor usage of one or more applications by a user in the one or more devices. For example, some embodiments can relate to an OS of a mobile device that is configured to monitor usage of multiple applications in the device by a user. The monitoring of applications can identify typical initial or historical or sampled reads or writes common to a group of applications that cause the OS, hypervisor, or the like to read from memory and write into memory for the group of applications. The monitoring can also include monitoring of usage patterns of related applications (e.g., data access patterns, typical day of week used by the user, time of day usually used, other applications used that correlate to use of the group of applications, etc.). The initial or historical or sampled reads and writes associated with a group of applications can be stored or cached in memory to be used via a respective root process particularly for the group of applications. The initial or historical or sampled reads and writes can be managed, maintained, prioritized etc., by the OS, hypervisor or the like, via the memory, according to frequency of use, recency of use, etc. In some embodiments, storing or caching can be done in faster memory for accelerating the initial reads and writes ... in anticipation of use of at least one application in the group of applications, the OS, hypervisor or the like can be configured to re-launch the root process of the group according to identified patterns in the monitoring of the group. Preference to patterns can be based on quantify, frequency and/or recency of the patterns, and any type of memory access patterns for the group of applications can be monitored and tracked ... (¶ 0012-0014)];
compiling the samples of memory usage data within a memory record on the computing device [... For example, some embodiments can relate to an OS of a mobile device that is configured to monitor usage of multiple applications in the device by a user. The monitoring of applications can identify typical initial or historical or sampled reads or writes common to a group of applications that cause the OS, hypervisor, or the like to read from memory and write into memory for the group of applications ... The initial or historical or sampled reads and writes associated with a group of applications can be stored or cached in memory to be used via a respective root process particularly for the group of applications. The initial or historical or sampled reads and writes can be managed, maintained, prioritized etc., by the OS, hypervisor or the like, via the memory, according to frequency of use, recency of use, etc. In some embodiments, storing or caching can be done in faster memory for accelerating the initial reads and writes ... (¶ 0012-0014)]; and
causing information from the memory record to be shared with the plurality of accessing agents [In some embodiments disclosed herein, a group of applications can share a respective root process just for the group of applications. In such embodiments, the root process of the group of applications can pre-load a selected collection of libraries, objects, and/or pages suitable for a group of applications such that each of the applications of the group can be launched via forking of the root process of the group ... Captured data access and usage patterns can be used to identify a group of applications to share a root process, such that the root process becomes the respective root process for the group of applications ... (¶ 0010-0011); ... The root process of a group of applications (e.g., see root processes 110, 112, and 114) can also be customized and executed according to usage data common to each application in the group (e.g., see application usage data 116a, 116b, and 116c which can include common data that links applications 108a, 108b, and 108c) ... For instance, application 108a may be connected to application 108b because they share a common object (e.g., where they both read-write data related to capturing user voice during mobile phone calls) ... (¶ 0025)].
Regarding claim 1, Yudanov teaches determining a sample granularity including an access time/day based on a common factor of the access resolutions for the plurality of accessing agents [Some embodiments disclosed herein relate to an OS or hypervisor or the like of one or more computing devices that is configured to monitor usage of one or more applications by a user in the one or more devices. For example, some embodiments can relate to an OS of a mobile device that is configured to monitor usage of multiple applications in the device by a user. The monitoring of applications can identify typical initial or historical or sampled reads or writes common to a group of applications that cause the OS, hypervisor, or the like to read from memory and write into memory for the group of applications. The monitoring can also include monitoring of usage patterns of related applications (e.g., data access patterns, typical day of week used by the user, time of day usually used, other applications used that correlate to use of the group of applications, etc.) … (¶ 0012-0014)], but does not expressively teach the determined sample granularity includes an access frequency.
However, Altenhofen specifically teaches determining a sample granularity including an access frequency based on a common factor of the access resolutions for the plurality of accessing requests [In some embodiments, detecting the pattern may be performed in various ways. For example, detecting the pattern may comprise determining, by the server computer, that the at least a portion of the set of the plurality of access requests involve a recurring access request indicator. In another example, detecting the pattern may comprise determining, by the server computer, one or more of (1) a common frequency between the at least a portion of the set of the plurality of access requests, (2) a common access request amount for the at least a portion of the set of the plurality of access requests, (3) a common day shared by the at least a portion of the set of the plurality of access requests, and (4) a common time shared by the at least a portion of the set of the plurality of access requests (¶ 0007)].
Therefore, it would have been obvious for one of ordinary skills in the art before the effective filing date of the claimed invention to determine a sample granularity including an access frequency based on a common factor of the access resolutions for the plurality of accessing requests, as specifically disclosed by Altenhofen, and to incorporate it into the existing scheme disclosed by Yudanov, because Altenhofen teaches doing so allows the computing device to automatically detect changes of access patterns [… A processor server computer may determine whether resource provider computers store access data associated with the user in various ways, including detecting patterns in sets of a plurality of access requests conducted between the user and each of the plurality of resource provider computers. Upon detecting that access data has changed, the processor server computer may automatically send the updated access data to each of the identified resource provider computer (abstract)].
As to claim 2, Yudanov in view of Altenhofen teaches The method of claim 1, wherein determining the sample granularity includes determining the common factor for the first accessing agent and the second accessing agent and calculating a sampling frequency that is a factor of both the first frequency associated with the first accessing agent and the second frequency associated with the second accessing agent [Yudanov -- the corresponding “common factor” may be “typical day of week used by the user, time of day usually used” -- Some embodiments disclosed herein relate to an OS or hypervisor or the like of one or more computing devices that is configured to monitor usage of one or more applications by a user in the one or more devices. For example, some embodiments can relate to an OS of a mobile device that is configured to monitor usage of multiple applications in the device by a user. The monitoring of applications can identify typical initial or historical or sampled reads or writes common to a group of applications that cause the OS, hypervisor, or the like to read from memory and write into memory for the group of applications. The monitoring can also include monitoring of usage patterns of related applications (e.g., data access patterns, typical day of week used by the user, time of day usually used, other applications used that correlate to use of the group of applications, etc.). The initial or historical or sampled reads and writes associated with a group of applications can be stored or cached in memory to be used via a respective root process particularly for the group of applications. The initial or historical or sampled reads and writes can be managed, maintained, prioritized etc., by the OS, hypervisor or the like, via the memory, according to frequency of use, recency of use, etc. In some embodiments, storing or caching can be done in faster memory for accelerating the initial reads and writes ... in anticipation of use of at least one application in the group of applications, the OS, hypervisor or the like can be configured to re-launch the root process of the group according to identified patterns in the monitoring of the group. Preference to patterns can be based on quantify, frequency and/or recency of the patterns, and any type of memory access patterns for the group of applications can be monitored and tracked ... (¶ 0012-0014); ... The root process of a group of applications (e.g., see root processes 110, 112, and 114) can also be customized and executed according to usage data common to each application in the group (e.g., see application usage data 116a, 116b, and 116c which can include common data that links applications 108a, 108b, and 108c). The commonality between usage data of applications in a group can be determined via logical connections (e.g., see logical connections 118) (¶ 0047); ... And, method 500 includes the step 208 of customizing and executing a root process for a group of the groups of applications according to usage common to each application in the group, as well as repeating step 208 for each group of the groups of applications at step 210 (¶ 0052)].
As to claim 3, Yudanov in view of Altenhofen teaches The method of claim 1, further comprising generating a plurality of agent-specific memory usage records for the plurality of accessing agents based on associated access resolutions for the plurality of accessing agents [Yudanov -- Customized root processes for groups of applications in a computing device. A computing device (e.g., a mobile device) can monitor usage of applications. The device can then store data related to the usage of the applications, and group the applications into groups according to the stored data. The device can customize and execute a root process for a group of applications according to usage common to each application in the group. The device can generate patterns of prior executions shared amongst the applications in the group based on the stored data common to each application in the group, and execute the root process of the group according to the patterns. The device can receive a request to start an application from the group from a user of the device, and start the application upon receiving the request and by using the root process of the group of applications (abstract); A method, comprising: monitoring, in a mobile device, usage of a plurality of applications to determine memory access for each of the plurality of applications; storing data related to the usage of the plurality of applications; grouping the plurality of applications into groups according to data related to usage of the plurality of applications; and customizing and executing a root process for a group of the groups of applications according to usage common to each application in the group (claim 1); The method of claim 1, wherein at least one of the monitoring, storing, grouping, or executing is performed by an operating system (OS) in the mobile device, and wherein determining memory access comprises measuring frequency or recency of reads from and writes to memory (claim 2)
As to claim 5, Yudanov in view of Altenhofen teaches The method of claim 3, wherein generating the plurality of agent-specific memory usage records includes combining sets of samples of memory usage data to simulate a collection of memory usage data at the associated access resolutions as if the memory usage data was sampled at the frequencies of the associated access resolutions [Yudanov -- the corresponding “common factor” may be “typical day of week used by the user, time of day usually used” -- Some embodiments disclosed herein relate to an OS or hypervisor or the like of one or more computing devices that is configured to monitor usage of one or more applications by a user in the one or more devices. For example, some embodiments can relate to an OS of a mobile device that is configured to monitor usage of multiple applications in the device by a user. The monitoring of applications can identify typical initial or historical or sampled reads or writes common to a group of applications that cause the OS, hypervisor, or the like to read from memory and write into memory for the group of applications. The monitoring can also include monitoring of usage patterns of related applications (e.g., data access patterns, typical day of week used by the user, time of day usually used, other applications used that correlate to use of the group of applications, etc.). The initial or historical or sampled reads and writes associated with a group of applications can be stored or cached in memory to be used via a respective root process particularly for the group of applications. The initial or historical or sampled reads and writes can be managed, maintained, prioritized etc., by the OS, hypervisor or the like, via the memory, according to frequency of use, recency of use, etc. In some embodiments, storing or caching can be done in faster memory for accelerating the initial reads and writes ... in anticipation of use of at least one application in the group of applications, the OS, hypervisor or the like can be configured to re-launch the root process of the group according to identified patterns in the monitoring of the group. Preference to patterns can be based on quantify, frequency and/or recency of the patterns, and any type of memory access patterns for the group of applications can be monitored and tracked ... (¶ 0012-0014)].
As to claim 6, Yudanov in view of Altenhofen teaches The method of claim 3, wherein causing information from the memory record to be shared with the plurality of accessing agents comprises providing, for each accessing agent of the plurality of accessing agents, information from a respective agent-specific memory usage record from the plurality of agent-specific memory usage records [Yudanov -- In some embodiments disclosed herein, a group of applications can share a respective root process just for the group of applications. In such embodiments, the root process of the group of applications can pre-load a selected collection of libraries, objects, and/or pages suitable for a group of applications such that each of the applications of the group can be launched via forking of the root process of the group ... Captured data access and usage patterns can be used to identify a group of applications to share a root process, such that the root process becomes the respective root process for the group of applications ... (¶ 0010-0011); ... The root process of a group of applications (e.g., see root processes 110, 112, and 114) can also be customized and executed according to usage data common to each application in the group (e.g., see application usage data 116a, 116b, and 116c which can include common data that links applications 108a, 108b, and 108c) ... For instance, application 108a may be connected to application 108b because they share a common object (e.g., where they both read-write data related to capturing user voice during mobile phone calls) ... (¶ 0025)].
As to claim 7, Yudanov in view of Altenhofen teaches The method of claim 1, wherein the samples of memory usage data are obtained from multiple memory devices having the one or more memory controllers implemented thereon, and wherein the samples of memory usage data are compiled from each of the multiple memory devices within a common memory usage record stored on the computing device [Yudanov -- controller and memory, figure 1, 104; figure 7 shows a controller (706), memory (708). and storage system (712); Specifically, FIG. 1 Illustrates mobile device 102 that at least includes a controller and memory 104 ... In some embodiments, the memory can have different speeds, latencies, bandwidths and other parameters. For example, SRAM memory can be used as high-speed cache, DRAM as the main memory, and NVRAM as storage memory (¶ 0021-0022)].
As to claim 11, it recites substantially the same limitations as in claim 1, and is rejected for the same reasons set forth in the analysis of claim 1. Refer to “As to claim 1” presented earlier in this Office Action for details.
As to claim 12, it recites substantially the same limitations as in claim 2, and is rejected for the same reasons set forth in the analysis of claim 2. Refer to “As to claim 2” presented earlier in this Office Action for details.
As to claim 13, it recites substantially the same limitations as in claim 3, and is rejected for the same reasons set forth in the analysis of claim 3. Refer to “As to claim 3” presented earlier in this Office Action for details.
As to claim 14, it recites substantially the same limitations as in claim 4, and is rejected for the same reasons set forth in the analysis of claim 4. Refer to “As to claim 4” presented earlier in this Office Action for details.
As to claim 15, it recites substantially the same limitations as in claim 5, and is rejected for the same reasons set forth in the analysis of claim 5. Refer to “As to claim 5” presented earlier in this Office Action for details.
As to claim 16, it recites substantially the same limitations as in claim 6, and is rejected for the same reasons set forth in the analysis of claim 6. Refer to “As to claim 6” presented earlier in this Office Action for details.
As to claim 17, it recites substantially the same limitations as in claim 7, and is rejected for the same reasons set forth in the analysis of claim 7. Refer to “As to claim 7” presented earlier in this Office Action for details.
As to claim 19, it recites substantially the same limitations as in claim 1, and is rejected for the same reasons set forth in the analysis of claim 1. Refer to “As to claim 1” presented earlier in this Office Action for details.
As to claim 20, it recites substantially the same limitations as in claim 2, and is rejected for the same reasons set forth in the analysis of claim 2. Refer to “As to claim 2” presented earlier in this Office Action for details.
5. Claims 8-9, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Yudanov in view of Altenhofen, and further in view of Prohofsky (US Patent 10,176,212).
Regarding claim 8, Yudanov in view of Altenhofen does not teach obtaining the samples of memory usage data comprises reading one or more heatmaps on the one or more memory controllers, and reading the one or more heatmaps on the one or more memory controllers causes data from the one or more heatmaps to be cleared when read by the computing device.
However, heatmaps are well known and widely used in the art.
For example, Prohofsky specifically obtaining the samples of memory usage data comprises reading one or more heatmaps on the one or more memory controllers, and reading the one or more heatmaps on the one or more memory controllers causes data from the one or more heatmaps to be cleared when read by the computing device [The first tier memory controller 120 may maintain a heat map for data stored to the memory 118, which may store information on data accesses and can be used to determine which data is infrequently accessed “cold” data. For example, a heat map may include a data access log or mapping table with metadata related to a number or frequency of accesses to the mapped data. “Cold” data may refer to data that is infrequently accessed, based on number of accesses, recency of accesses, other statistics, or any combination thereof, or is otherwise categorized as less desirable to store in a high tier of a tiered storage system. Conversely, “hot” data may refer to data that is accessed often, has been accessed recently, or is otherwise characterized as important or useful to store for fast retrieval, e.g. by storing in a fast-access NAND flash memory (c5 L51-65); In some embodiments, the TMC 512 of the first tier DSD 502 may maintain a heat map 514 for data stored to the first tier DSD 502. When data access requests are received at the first tier DSD 502 over the host interface 506, the TMC may update the heat map 514 for the corresponding data ... (c11 L61-67)].
Therefore, it would have been obvious for one of ordinary skills in the art before the effective filing date of the claimed invention to obtain the samples of memory usage data comprises reading one or more heatmaps on the one or more memory controllers, and reading the one or more heatmaps on the one or more memory controllers causes data from the one or more heatmaps to be cleared when read by the computing device, as specifically disclosed by Prohofsky, and to incorporate it into the existing scheme disclosed by Yudanov in view of Altenhofen, because Prohofsky teaches doing so allows data to be stored in different tiers of storage devices based on the access frequency of the data [... In some embodiments, controller 124 may maintain a “heat map,” which may be a log of data requests or accesses for data stored to memory 122 and which can be used to monitor which data is frequently accessed “hot data,” and which data is infrequently accessed “cold” data. The access log may be used to determine data to be promoted to a higher storage tier (c4 L32-45)].
As to claim 9, Yudanov in view of Altenhofen & Prohofsky teaches The method of claim 8, wherein the one or more heatmaps are locally maintained on the one or more memory controllers [Prohofsky -- The first tier memory controller 120 may maintain a heat map for data stored to the memory 118, which may store information on data accesses and can be used to determine which data is infrequently accessed “cold” data. For example, a heat map may include a data access log or mapping table with metadata related to a number or frequency of accesses to the mapped data. “Cold” data may refer to data that is infrequently accessed, based on number of accesses, recency of accesses, other statistics, or any combination thereof, or is otherwise categorized as less desirable to store in a high tier of a tiered storage system. Conversely, “hot” data may refer to data that is accessed often, has been accessed recently, or is otherwise characterized as important or useful to store for fast retrieval, e.g. by storing in a fast-access NAND flash memory (c5 L51-65)].
As to claim 18, it recites substantially the same limitations as in claim 8, and is rejected for the same reasons set forth in the analysis of claim 8. Refer to “As to claim 8” presented earlier in this Office Action for details.
6. Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Yudanov in view of Altenhofen, and further in view of Nakajima (US Patent Application Publication 20100275205).
Regarding claim 10, Yudanov in view of Altenhofen does not teach the plurality of accessing agents comprises a plurality of virtual machines implemented on the computing device.
However, virtual machines are well known and widely used in the art.
For example, Nakajima specifically teaches a plurality of virtual machines implemented on the computing device [One embodiment of the invention relates to a computer having a plurality of virtual machines operated on a virtual machine monitor and a control method of access from the virtual machine to a file (¶ 0003); In the case of access to the PCI configuration space among the accesses to the I/O port, the virtual machine monitor 230 calls the device manager 220 and the device manager 220 acts as an agent to make access to the PCI configuration space. In a case wherein the device manager acts as an accessing agent, two accessing methods are provided … (¶ 0091)].
Therefore, it would have been obvious for one of ordinary skills in the art before the effective filing date of the claimed invention to have implemented a plurality of virtual machines on a computer, as specifically disclosed by Nakajima, and to incorporate it into the existing scheme disclosed by Yudanov in view of Altenhofen, because Nakajima teaches doing so allows parallel processing of multiple tasks simultaneously [ According to one embodiment, a computer machine includes a client virtual machine and a file server virtual machine configured to simultaneously run, a virtual machine manager configured to control booting of the client and file server virtual machines, a monitoring module configured to monitor whether a communication with an external file server is possible, an access control module configured to access to a duplicate file which is a duplicate of the file and is stored in a part of a local disk or a part of a memory which are managed by the monitoring module when the monitoring module determines that the communication is impossible after determining that the communication is possible, and a file deletion module configured to delete the duplicate file when the monitoring module detects the communication is impossible in a preset time (abstract)].
Allowable Subject Matter
7. Claims 4 and 14 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
8. Claims 1-3, 5-13, and 15-20 are rejected as explained above.
Claims 4 and 14 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
9. Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHENG JEN TSAI whose telephone number is 571-272-4244. The examiner can normally be reached on Monday-Friday, 9-6.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Reginald Bragdon can be reached on 571-272-4204. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/SHENG JEN TSAI/Primary Examiner, Art Unit 2139
Prosecution Insights