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 .
Response to Arguments
Applicant's arguments filed 3/25/2026 have been fully considered but they are not persuasive. The applicant argues on pages 9-11 of the remarks that the amended claim language is not taught by the prior art. The examiner disagrees and the detailed mapping of the prior art to the amended claim language can be found below.
Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references.
Applicant's arguments do not comply with 37 CFR 1.111(c) because they do not clearly point out the patentable novelty which he or she thinks the claims present in view of the state of the art disclosed by the references cited or the objections made. Further, they do not show how the amendments avoid such references or objections.
In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
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.
Claim(s) 1 and 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Stabrawa (US 2016/0283127).
In regards to claims 1 and 8, taking claim 8 as exemplary,
memory in which at least one program is recorded; and a processor for executing the program, (fig. 1, ¶66 memory 108/130 can have code that can be executed by the processor(s) 112/138 to perform the features of the system.)
generate a child process in an event of a fork; (¶128-133, fig. 8 teaches a child process is started 822 in response to a fork system call 808)
in response to generating the child process, to copy a page table of a parent process for disaggregated memory to the child process and setting write protection on a page of the memory to form a write protected page (¶144-145 teaches that page table entries of the parent can be installed for the child (i.e. the page table is copied) and that parent memory area (i.e. pages) and/or the page table entries of the child can be configured as not writable (i.e. write protection has been set)
processing write access to the write-protected page by a write access process, the write access process being the parent process, the child process, or another child process of the parent process (¶145 teaches future writes to the pages (i.e. write protected pages shared by the parent/child process) will trigger the page fault handler and the writes can be from the parent process or the child process.)
wherein the processing of the write access uses at least one of a first handler corresponding to access to the write-protected page mapped to a page table of the write access process or a second handler corresponding to the write access to the write-protected page that is not mapped to the page table of the write access process, or a combination thereof. wherein the first handler and the second handler process the write access based on whether the write-protected page is mapped to another process. (fig. 10 and ¶146-148 shows that depending on which process (i.e. parent or child) is trying to write to the write protected data, and whether a page of the protected area had previously been written to by one of the processes (i.e. the protected page is mapped to the requesting processed or another process) determines how the write access is processed (i.e. handled). Different “handlers” (i.e. actions) are performed based on these variables that results in different outcomes.
For example, ¶81 teaches that attempts to write to locations within the parent’s virtual address space, can trigger a page fault handler to initialize another page with known data to allow the write to proceed to. ¶82 describes another version of a page fault handling where the child attempts to write to a page shared between two or more processes marked as read only, and a third page is allocated to the child, with the end result being the parent and child pages now differ. Variations of different fault handling can be seen in at least fig. 10, 12, 13, and 14. Note that the different “handler” process can depend on which process (i.e. parent or child) is trying to access the location/pages.)
Stabrawa doesn’t specifically state “disaggregated” memory,
However, ¶44-48 teaches that external memory allocation may be requested by a client, and that the primary memory can be used as a cache memory to store copies of data from frequency used memory locations of the externally allocated memory. It should be noted that ¶8 of the specification says that “disaggregated memory is an environment where local and remote memory are used together.
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to have modify the system of Stabrawa to incorporated the use of local and remote memory (i.e. disaggregated memory). The motivation for such is that external memory allocations can be requested by the client to scale the amount of memory available to the client (¶44), and that external memory allocations makes available memory capacity larger than what may be possible to fit into the request client (¶48)
Claim(s) 2-7 and 9-14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Stabrawa (US 2016/0283127) in view of Koutsovasilis (US 2022/0350518).
In regards to claims 2 and 9, Stabrawa further teaches
in ¶5-6 that pages associated with the current working set of processes (i.e. active process) can be stored in the primary (local) memory and when those processes become inactive those pages can be swapped out to secondary (remote or slower) memory.
Stabrawa may not explicitly teach
wherein the page of the disaggregated memory is set to an active state or an inactive state depending on whether the page is mapped to a process when the page is stored in local memory, and is set to a remote state when the page is stored in remote memory.
Koutsovasilis teaches in ¶102-105 that an active and inactive list can be kept for local memory, and that a “page referenced bit” can be used to determine if the page is kept on the active list or added to the inactive list. It further teaches that pages can be migrated/swapped to the “disaggregated” (remote) memory from the local memory and moving the page from the inactive list of the local memory to the active list of the “disaggregated” (remote) memory.
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to modify the system of Stabrawa such that the location (i.e. local and remote) and state (via list, flag, indicators, bitmaps, etc. of active/inactive and referenced/unreferenced) of pages can be tracked and monitored. The motivation for this modification is to balance the memory usage (¶105) and keep “hot memory pages” in the local memory and to bring frequently accessed pages from the remote memory back to the local memory; this improves the system by increasing the chance that required data will be kept in the faster local memory.
In regards to claims 3 and 10, the combination of Stabrawa and Koutsovasilis makes obvious
when the write-protected page is mapped to a write access process and other processes, setting a page copied from the write-protected page to the active state, and
assigning write permission on the copied page to the write access process. (at least ¶81-82 of Stabrawa teaches that when trying to write to a write-protected page, the page can be copied and write access given to the copy. ¶5 of Stabrawa teaches/suggests the pages for active process should be kept in the primary (local) memory. ¶102-105 of Koutsovasilis teaches/suggests keeping an active list for pages. As such, as the page is currently being written to (i.e. by an active process) the copied page should be in the local memory and added to the active list (set to the active state).
In regards to claims 4 and 11, the combination of Stabrawa and Koutsovasilis makes obvious
processing the write access using the first handler comprises when the write-protected page is mapped only to a write access process, changing the write-protected page to the active state, and assigning write permission on the write-protected page to the write access process, (Stabrawa fig. 10 and ¶146-148 shows that the parent can read/write to the mapped page and a copy assigned to the child (i.e. as parent is writing, the page is considered active, and parent is allowed to write (i.e. write permission is assigned) and since the page has been copied and assigned to the child, the page is now mapped only to the parent (write access process).
when the write-protected page is stored also in the remote memory, changing the write-protected page stored in the remote memory to the remote state, and when the write-protected page is stored only in the local memory, copying a page from the write-protected page and setting the copied page to the inactive state. (see claim 2-9 rejection reasoning. The location of the pages can be tracked/updated, and if the copies are made by the active process and assigned to the currently inactive process, then the copy as inactive)
In regards to claims 5 and 12, the combination of Stabrawa and Koutsovasilis makes obvious
wherein processing the write access using the second handler comprises when the write-protected page is mapped to a process other than a write access process, setting a page copied from the write-protected page to the active state, and assigning write permission on the copied page to the write access process. (Stabrawa in ¶81 teaches that attempts to write to locations within the parent’s virtual address space, can trigger a page fault handler to initialize another page with known data to allow the write to proceed to. ¶82 describes another version of a page fault handling where the child attempts to write to a page shared between two or more processes marked as read only, and a third page is allocated to the child. See also fig. 10 and ¶146-148. When the child tries to write to a write-protected page of the parent (i.e. process other than the write active process), the page can copied, assigned to child (i.e. set as active), and the child given write access to the copied page.
In regards to claims 6 and 13, the combination of Stabrawa and Koutsovasilis makes obvious
processing the write access using the second handler comprises when the write-protected page is not mapped to any process and is stored in the local memory (Stabrawa ¶116 teaches memory mapping can be unmapped, i.e. not mapped to any process)
changing the write-protected page to the active state, and assigning write permission on the write-protected page to a write access process, (Stabrawa, ¶116 teaches the child process can created one or more mapping, fig. 11 shows that if the page isn’t shared (step 1128), then the page can be set marked as writable.
when the write-protected page is stored also in the remote memory, changing the write-protected page stored in the remote memory to the remote state, and when the write-protected page is stored only in the local memory, copying a page from the write-protected page and setting the copied page to the inactive state. (see claim 2-9 rejection reasoning. The location of the pages can be tracked/updated, and if the copies are made by the active process and assigned to the currently inactive process, then the copy as inactive)
In regards to claims 7 and 14, the combination of Stabrawa and Koutsovasilis makes obvious
wherein processing the write access using the second handler comprises when the write-protected page is not mapped to any process (Stabrawa ¶116 teaches memory mapping can be unmapped, i.e. not mapped to any process)
and is stored in the remote memory, setting a page in the local memory that is copied from the write-protected page to the active state, (stabrawa, ¶ 44 teaches data can be stored in the external (remote memory) and copied into the primary (cache) memory (i.e. by an active process, and thereby marked as active)
assigning write permission on the copied page to a write access process (fig. 11 shows that if the page isn’t shared (step 1128), then the page can be set marked as writable.)
setting the write-protected page stored in the remote memory to the remote state and setting write protection thereon. (see claim 2-9 rejection reasoning. The location of the pages can be tracked/updated).
Conclusion
THIS ACTION IS MADE FINAL. 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 JASON W BLUST whose telephone number is (571)272-6302. The examiner can normally be reached 12-8:30 EST.
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, Hosain Alam can be reached at (571) 272-3978. 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.
/JASON W BLUST/ Primary Examiner, Art Unit 2132
Prosecution Insights