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 .
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on July 16th, 2025 was filed. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 10 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 10 recites the limitation “receive … a command to flush a modified data value”, then proceeds to state “based on the command, flushing the data value”. It is unclear whether this flushing command is performed on the newly modified data value, or the previous data value as described in independent claim 1. The claim is also unclear on how or when the data value is modified. For the purposes of examination, the examiner is interpreting the claim as flushing the data value previously described in the independent claim.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless – (a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 3-6, 15-16 and 19 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Kajihara et al. (US Publication No. 2025/0298748 – “Kajihara”).
Regarding claim 1, Kajihara teaches A method, comprising: receiving, from a host, by a memory device, a prefetch command; (Kajihara paragraph [0048], The memory controller 20 will be described with reference to FIG. 1 again. The memory controller 20 includes, for example, an integrated circuit such as a system-on-a-chip (SoC). The memory controller 20 controls the nonvolatile memory 10 based on a request from the host 2. Specifically, upon receiving a write request WR from the host 2, the memory controller 20 writes data to be written (write data WD) to the nonvolatile memory 10. Upon receiving a read request RR from the host 2, the memory controller 20 reads data to be read (read data RD) from the nonvolatile memory 10 and transmits the read data to the host 2. Upon receiving a prefetch (pre-read) request PR from the host 2, the memory controller 20 executes a prefetch process. A prefetch command may be received by a memory controller controlling a memory device, from a host device) and based on receiving the prefetch command, reading a data value from a memory of the memory device into a cache of the memory device (Kajihara paragraph [0048], The prefetch process is a process of reading data in which the read request RR is expected to come from the host 2 or data in which the read request RR is likely to come therefrom, from the nonvolatile memory 10 in advance before the read request RR comes and storing the data in the cache memory. Hereinafter, the data read by the prefetch process is referred to as “data to be previously read (prefetch data PD)”. A prefetch command may read a data value(herein prefetch data PD) from memory to be stored into cache).
Claims 15 and 19 are the corresponding device and system claims to method claim 1. They are rejected with the same references and rationale.
Regarding claim 3, Kajihara teaches The method of claim 1, wherein the memory of the memory device comprises nonvolatile memory (Kajihara paragraph [0036], In general, according to one embodiment, a memory system includes a nonvolatile memory and a memory controller).
Claims 16 is the corresponding device claim to method claim 3. It is rejected with the same references and rationale.
Regarding claim 4, Kajihara teaches The method of claim 3, wherein the memory of the memory device comprises a solid-state drive (Kajihara paragraph [0042], The memory system 3 includes a nonvolatile memory, and has intermediate performance between a main memory mainly including a dynamic random access memory (DRAM) and a storage device (for example, a solid state drive (SSD) or the like) including a NAND flash memory).
Regarding claim 5, Kajihara teaches The method of claim 1, wherein the memory device comprises a controller, the controller comprising a processing circuit comprising a stored-program computer (Kajihara Fig. 3; Ref #20 and #22; paragraph [0050], Next, a hardware configuration of the memory controller 20 will be described with reference to FIG. 3. FIG. 3 is a block diagram illustrating an example of a hardware configuration of the memory controller 20. FIG. 3 also illustrates the nonvolatile memory 10. As illustrated in FIG. 3, the memory controller 20 includes a host interface circuit (host I/F) 21, a control circuit 22, a first cache 23, a second cache 24, a management memory 25, and a memory interface circuit (memory I/F) 26. The Function of each part of the memory controller 20 may be implemented by dedicated hardware, a processor which executes programs, or a combination of them. The memory controller 20 also performs communication with the host 2. The memory controller contains a processing circuit comprising processing execution for programs, see Kajihara paragraph [0052], The control circuit 22 is a circuit that controls the entire memory controller 20. The control circuit 22 includes, for example, a processor such as a central processing unit (CPU), a read only memory (ROM), and a random access memory (RAM). The processor controls the entire operation of the memory controller 20 by executing a program (firmware) stored in the ROM. The ROM is a nonvolatile memory. The ROM stores a program such as firmware. The RAM is a volatile memory. The RAM is used as a work area of the processor).
Regarding claim 6, Kajihara teaches The method of claim 5, wherein the memory device further comprises a controller memory connected to the controller (Kajihara Fig. 3; Ref #25, controller management memory; also see Kajihara paragraph [0050], Next, a hardware configuration of the memory controller 20 will be described with reference to FIG. 3. FIG. 3 is a block diagram illustrating an example of a hardware configuration of the memory controller 20. FIG. 3 also illustrates the nonvolatile memory 10. As illustrated in FIG. 3, the memory controller 20 includes a host interface circuit (host I/F) 21, a control circuit 22, a first cache 23, a second cache 24, a management memory 25, and a memory interface circuit (memory I/F) 26. The Function of each part of the memory controller 20 may be implemented by dedicated hardware, a processor which executes programs, or a combination of them. The memory controller 20 also performs communication with the host 2. A controller memory may be connected to the controller and used for managing controller operations).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kajihara as applied to claim 1 above, and further in view of Feng et al. (US Publication No. 2017/0293566 – “Feng”).
Regarding claim 2, Kajihara in view of Feng teaches The method of claim 1, wherein the memory of the memory device is larger than the cache of the memory device (Feng paragraph [0033], The cache 124 may be a small, fast memory that may be used to store frequently used, recently used, or soon to be used, blocks of data for rapid access. The cache 124 may mitigate sonic of the latency associated with accessing the non-volatile memory 130. In many examples, the size of the cache 124 may be smaller as compared to the size of the non-volatile memory 130. As discussed in more detail below, different cache replacement mechanisms may be used by the controller 120 to determine when to replace data within the cache 124 when one or more write requests are determined not to be associated with a NV write request sequence. The cache may be of smaller size than the memory).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kajihara with those of Feng. Feng explicitly teaches the concept of a cache being smaller than the memory, which is common in the art as the cache is designed to be a smaller section of memory designed with less storage space but faster access, improving access times for hot data (i.e., see Feng paragraph [0033], The cache 124 may be a small, fast memory that may be used to store frequently used, recently used, or soon to be used, blocks of data for rapid access. The cache 124 may mitigate sonic of the latency associated with accessing the non-volatile memory 130. In many examples, the size of the cache 124 may be smaller as compared to the size of the non-volatile memory 130. As discussed in more detail below, different cache replacement mechanisms may be used by the controller 120 to determine when to replace data within the cache 124 when one or more write requests are determined not to be associated with a NV write request sequence).
Claim(s) 7-9, 17-18 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kajihara as applied to claim 1 above, and further in view of Cave et al. (US Publication No. 2026/0086713 – “Cave”).
Regarding claim 7, Kajihara in view of Cave teaches The method of claim 1, further comprising: receiving, from the host, by the memory device, a command to place a lock on the data value; and based on the command, placing a lock on the data value (Cave paragraph [0077], In certain examples, if the field of the virtual address indicates a “cached” type of atomic memory access request, e.g., if the bits of the field (e.g., bits [58:57]) include same values (e.g., 00 or 11), then the atomic memory access request is to not bypass the ATMC 116(0) and not bypass the data cache 118(0). In certain examples, if the comparator 204 determines the field of the virtual address indicates a “cached” type of atomic memory access request, the opcode and data are sent to the ATMC 116(0), e.g., for it to send a read data request and a lock request for that data (e.g., cache line) to data cache 118(0). A particular data value of a cache line can be locked via request).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kajihara with those of Cave. Cave teaches the concept of locking/unlocking data in a cache, which can be used to ensure a particular data section of a cache is not overwritten until a desired command has been completed, allowing for more efficient and reliable caching, particularly for high demand caches (i.e., see Cave paragraph [0078], This section describes example behavior of a data cache when an atomic request is received from a pipeline, e.g., from the pipeline's LSU. In certain examples, the load-store unit 114(0) is to issue ‘read-lock’ requests to the data cache 118(0), e.g., which will trigger a lock on the cache line's entry until the entire read-modify-write operation has completed. Also see paragraph [0085], The operations 300 further include, at block 312, (when the request is a cache hit), the cache will lock (e.g., a read-response wait) the cache line that was the hit and/or return the data to the local ATMC (e.g., 116(0) in FIG. 2) for execution of the operation. The operations 300 further include, at block 314, the local ATMC issuing a “write unlock” request along with the modified data from the atomic operation, e.g., once the ATMC has completed performing the operation for the atomic request).
Claims 17 and 20 are the corresponding device and system claims to method claim 7. They are rejected with the same references and rationale.
Regarding claim 8, Kajihara in view of Cave teaches The method of claim 7, further comprising: receiving, from the host, by the memory device, a command to release the lock on the data value; and based on the command, releasing the lock (Cave paragraph [0085], The operations 300 further include, at block 312, (when the request is a cache hit), the cache will lock (e.g., a read-response wait) the cache line that was the hit and/or return the data to the local ATMC (e.g., 116(0) in FIG. 2) for execution of the operation. The operations 300 further include, at block 314, the local ATMC issuing a “write unlock” request along with the modified data from the atomic operation, e.g., once the ATMC has completed performing the operation for the atomic request. The operations 300 further include, at block 316, writing the modified data to the cache line block, and unlocking the cache line once the cache receives a “write-unlock” request from the local ATMC, e.g., with a request ID matching the original ID received from the LSU. In certain examples, the operations 300 also include, at block 316, sending a response from the cache to the local ATMC indicating the data cache operation is now complete. Cache data can be unlocked based on a received request).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kajihara with those of Cave. Cave teaches the concept of locking/unlocking data in a cache, which can be used to ensure a particular data section of a cache is not overwritten until a desired command has been completed, allowing for more efficient and reliable caching, particularly for high demand caches (i.e., see Cave paragraph [0078], This section describes example behavior of a data cache when an atomic request is received from a pipeline, e.g., from the pipeline's LSU. In certain examples, the load-store unit 114(0) is to issue ‘read-lock’ requests to the data cache 118(0), e.g., which will trigger a lock on the cache line's entry until the entire read-modify-write operation has completed. Also see paragraph [0085], The operations 300 further include, at block 312, (when the request is a cache hit), the cache will lock (e.g., a read-response wait) the cache line that was the hit and/or return the data to the local ATMC (e.g., 116(0) in FIG. 2) for execution of the operation. The operations 300 further include, at block 314, the local ATMC issuing a “write unlock” request along with the modified data from the atomic operation, e.g., once the ATMC has completed performing the operation for the atomic request).
Regarding claim 9, Kajihara in view of Cave teaches The method of claim 1, further comprising: receiving, from the host, by the memory device, a command to evict the data value from the cache of the memory device; and based on the command, evicting the data value from the cache of the memory device (Cave paragraph [0087], Such an approach to executing the atomic operations remotely on a cache miss and returning the updated cache line improve overall performance in the following ways. In certain examples, utilizing the remote atomic reduces the rate of cache line writebacks when the line is modified only once. In certain examples, by utilizing the remote atomic, the line is brought into the cache in a clean state. In certain examples, by utilizing the remote atomic, any evictions on the un-modified line will not require a writeback. In certain examples, by utilizing the remote atomic, if the remote atomic was not used on the cache miss, the line would need to be written back on eviction because the atomic would be executed at the cache and data would be modified immediately following the return of the cache line from memory. Cache data can be evicted based on a request from the cache).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kajihara with those of Cave. Cave teaches the concept of locking/unlocking data in a cache, which can be used to ensure a particular data section of a cache is not overwritten until a desired command has been completed, allowing for more efficient and reliable caching, particularly for high demand caches (i.e., see Cave paragraph [0078], This section describes example behavior of a data cache when an atomic request is received from a pipeline, e.g., from the pipeline's LSU. In certain examples, the load-store unit 114(0) is to issue ‘read-lock’ requests to the data cache 118(0), e.g., which will trigger a lock on the cache line's entry until the entire read-modify-write operation has completed. Also see paragraph [0085], The operations 300 further include, at block 312, (when the request is a cache hit), the cache will lock (e.g., a read-response wait) the cache line that was the hit and/or return the data to the local ATMC (e.g., 116(0) in FIG. 2) for execution of the operation. The operations 300 further include, at block 314, the local ATMC issuing a “write unlock” request along with the modified data from the atomic operation, e.g., once the ATMC has completed performing the operation for the atomic request).
Claims 18 is the corresponding device claim to method claim 9. It is rejected with the same references and rationale.
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kajihara as applied to claim 1 above, and further in view of Wang et al. (US Publication No. 2024/0045804 – “Wang”).
Regarding claim 10, Kajihara in view of Wang teaches The method of claim 1, further comprising: receiving, from the host, by the memory device, a command to flush a modified data value from the cache of the memory device to the memory of the memory device; and based on the command, flushing the data value (Wang paragraph [0030], In other words, an object in shared memory becomes immutable once the host device that created the object relinquishes its write-lock for the object. Immutable objects cannot be modified or rewritten. Any storage in shared memory that is allocated for an immutable object can be written to again only after the object is deleted. In some implementations, the SM manager may require each host device that has accessed an object in shared memory to flush or otherwise clear its cache before deleting the object. A flush command may be given to a specific data value/object in the cache).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kajihara with those of Wang. Wang teaches performing a flush operation for cache data, which is a common method of transmitting data from the cache to storage in order to free up cache space for new data to be cached (i.e., see Wang paragraph [0030], In other words, an object in shared memory becomes immutable once the host device that created the object relinquishes its write-lock for the object. Immutable objects cannot be modified or rewritten. Any storage in shared memory that is allocated for an immutable object can be written to again only after the object is deleted. In some implementations, the SM manager may require each host device that has accessed an object in shared memory to flush or otherwise clear its cache before deleting the object).
Claim(s) 11-13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kajihara as applied to claim 1 above, and further in view of Lee (US Publication No. 2018/0157729 – “Lee”).
Regarding claim 11, Kajihara in view of Lee teaches The method of claim 1, further comprising: receiving, from the host, by the memory device, a status check command; and based on the status check command, transmitting status information to the host (Lee paragraph [0058], Referring to FIG. 3, the distributed in-memory database system having a shared-nothing architecture (hereinafter, referred to as a “database system”) collects information by monitoring a partition and resource utilization status periodically or upon request (S302). For example, the database system may monitor access frequency of each partition, a access pattern of partitions (for example, information regarding partitions frequently simultaneously accessed), a cache hit/miss rate, usage of CPU/DRAM, and the like. A status check command may be issued to determine various status information, including access frequency for a given data section).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kajihara with those of Lee. Lee teaches obtaining status information through a command request from the user in order to determine the current status of a particular access request, which can allow for adjustments to the cache/memory to optimize performance based on status results, such as minimum threshold for access frequency before cache overwriting (I.e., see Lee paragraphs [0059-0060], The database system determines whether the collected monitoring information is outside a minimum threshold for a database service (S304), and only when the collected monitoring information is outside the minimum threshold, the database system readjusts resource allocation and partition allocation. For example, a relative high usage of CPU and cache miss rate indicates an overload, and thus, the minimum threshold may be set from experience point information regarding such information. The database system calculates a resource demand required for the overloaded database server instance outside the minimum threshold to resolve an overload (S306). The database system also calculates a resource demand of each partition in order to determine a partition candidate to be transferred, as well as a total resource demand of the overloaded database server instance. For example, the resource demand of the overloaded database server instance may be calculated on the basis of average resource usage of database server instances and resource usage of the overloaded database server instance. The resource demand of each partition may be calculated using overall CPU usage used by the overloaded database server instance, a generated memory miss rate and a size of each partition, an access frequency ratio of each partition, and the like).
Regarding claim 12, Kajihara in view of Lee teaches The method of claim 11, wherein the status information comprises a status of a command (Lee paragraph [0058], Referring to FIG. 3, the distributed in-memory database system having a shared-nothing architecture (hereinafter, referred to as a “database system”) collects information by monitoring a partition and resource utilization status periodically or upon request (S302). For example, the database system may monitor access frequency of each partition, a access pattern of partitions (for example, information regarding partitions frequently simultaneously accessed), a cache hit/miss rate, usage of CPU/DRAM, and the like. A status check command may be issued to determine various status information, including access frequency for a given data section).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kajihara with those of Lee. Lee teaches obtaining status information through a command request from the user in order to determine the current status of a particular access request, which can allow for adjustments to the cache/memory to optimize performance based on status results, such as minimum threshold for access frequency before cache overwriting (I.e., see Lee paragraphs [0059-0060], The database system determines whether the collected monitoring information is outside a minimum threshold for a database service (S304), and only when the collected monitoring information is outside the minimum threshold, the database system readjusts resource allocation and partition allocation. For example, a relative high usage of CPU and cache miss rate indicates an overload, and thus, the minimum threshold may be set from experience point information regarding such information. The database system calculates a resource demand required for the overloaded database server instance outside the minimum threshold to resolve an overload (S306). The database system also calculates a resource demand of each partition in order to determine a partition candidate to be transferred, as well as a total resource demand of the overloaded database server instance. For example, the resource demand of the overloaded database server instance may be calculated on the basis of average resource usage of database server instances and resource usage of the overloaded database server instance. The resource demand of each partition may be calculated using overall CPU usage used by the overloaded database server instance, a generated memory miss rate and a size of each partition, an access frequency ratio of each partition, and the like).
Regarding claim 13, Kajihara in view of Lee teaches The method of claim 11, wherein: the status information comprises an operating statistic of the memory device, and the operating statistic comprises an access frequency of a memory location (Lee paragraph [0058], Referring to FIG. 3, the distributed in-memory database system having a shared-nothing architecture (hereinafter, referred to as a “database system”) collects information by monitoring a partition and resource utilization status periodically or upon request (S302). For example, the database system may monitor access frequency of each partition, a access pattern of partitions (for example, information regarding partitions frequently simultaneously accessed), a cache hit/miss rate, usage of CPU/DRAM, and the like. A status check command may be issued to determine various status information, including access frequency for a given data section).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kajihara with those of Lee. Lee teaches obtaining status information through a command request from the user in order to determine the current status of a particular access request, which can allow for adjustments to the cache/memory to optimize performance based on status results, such as minimum threshold for access frequency before cache overwriting (I.e., see Lee paragraphs [0059-0060], The database system determines whether the collected monitoring information is outside a minimum threshold for a database service (S304), and only when the collected monitoring information is outside the minimum threshold, the database system readjusts resource allocation and partition allocation. For example, a relative high usage of CPU and cache miss rate indicates an overload, and thus, the minimum threshold may be set from experience point information regarding such information. The database system calculates a resource demand required for the overloaded database server instance outside the minimum threshold to resolve an overload (S306). The database system also calculates a resource demand of each partition in order to determine a partition candidate to be transferred, as well as a total resource demand of the overloaded database server instance. For example, the resource demand of the overloaded database server instance may be calculated on the basis of average resource usage of database server instances and resource usage of the overloaded database server instance. The resource demand of each partition may be calculated using overall CPU usage used by the overloaded database server instance, a generated memory miss rate and a size of each partition, an access frequency ratio of each partition, and the like).
Claim(s) 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kajihara as applied to claim 1 above, and further in view of Foo et al. (US Patent No. 11,947,462 – “Foo”).
Regarding claim 14, Kajihara in view of Foo teaches The method of claim 1, further comprising: determining that the cache of the memory device is full and that all data values in the cache are locked; and based on determining that the cache of the memory device is full and that all data values in the cache are locked, evicting a locked data value from the cache of the memory device (Foo column 7; lines 24-35, The occupancy metric may indicate the number of cache sets (in a set associative cache) that are fully locked or fully dirty. A miss allocation for these sets may immediately trigger an eviction, so this metric may be predictive of potential evictions (and this metric may exhibit smaller lag time relative to measuring evictions directly). The number of tag checks, hits, misses, or some combination thereof may be maintained over one or more windows. As discussed above, tracking circuitry 210 may maintain various metrics separately for different types of work. In response to occupancy metrics indicating a full cache is locked, an eviction request may be issued).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kajihara with those of Foo. Foo teaches the concept of checking a cache status for cache locks and upon determining a full cache is locked, may issue an eviction command to free up available space for new data/operations (Foo column 7; lines 24-35, The occupancy metric may indicate the number of cache sets (in a set associative cache) that are fully locked or fully dirty. A miss allocation for these sets may immediately trigger an eviction, so this metric may be predictive of potential evictions (and this metric may exhibit smaller lag time relative to measuring evictions directly). The number of tag checks, hits, misses, or some combination thereof may be maintained over one or more windows. As discussed above, tracking circuitry 210 may maintain various metrics separately for different types of work. In response to occupancy metrics indicating a full cache is locked, an eviction request may be issued).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JONAH C KRIEGER whose telephone number is (571)272-3627. The examiner can normally be reached Monday - Friday 8 AM - 5 PM.
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, Rocio Del Mar Perez-Velez can be reached at (571)-270-5935. 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.
/J.C.K./ Examiner, Art Unit 2133
/ROCIO DEL MAR PEREZ-VELEZ/ Supervisory Patent Examiner, Art Unit 2133
Prosecution Insights