DETAILED ACTION
Claims 1-20 are presented for examination.
This office action is in response to amendment of application on 16-MARCH-2026.
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, see page 8, filed 16-MARCH-2026, with respect to the objection to the Abstract have been fully considered and are persuasive due to amendments. The objection to the Abstract has been withdrawn.
Applicant's arguments filed 16-MARCH-2026 have been fully considered but they are not persuasive.
1. With respect to Applicant’s traversal of the Specification objections as a whole, Examiner maintains one of the two objections from the previous office action. Examiner notes that Applicant’s reply appears to omit addressing one of the two objections made previously, specifically that the “dedicated memory 400” in lines 5-6 of [0049] uses a reference symbol “400” which is not found in the drawings. Instead, the dedicated memory element in Fig. 3A, which the paragraph describes, has reference symbol “310”.
2. With respect to Applicant’s argument that the prior art does not disclose or suggest the newly amended “an amount of dedicated memory is based on the configuration information” limitations, Examiner respectfully disagrees. As shown in the updated rejection below, Durham teaches multiple elements that determine an amount to dedicate to an application and to indicate how much is dedicated to an application, which could all be collectively understood as configuration information that performs the claimed functions.
Specification
The disclosure is objected to because of the following informalities:
In [0049], lines 5-6, “dedicated memory 400” should read “dedicated memory 310”.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3, 6-12, 14, 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over
Durham et al., U.S. Pub. No. 20200125502 (hereinafter “Durham”) in view of
Espy et al., U.S. Pub. No. 20210216320 (hereinafter “Espy”).
Regarding claim 1: Durham teaches A method comprising:
assigning, by a memory manager to a program, based on configuration information, one or more units of dedicated memory from a pool of dedicated memory, wherein the one or more assigned units of dedicated memory is reserved for the program… and wherein an amount of dedicated memory is based on the configuration information ([0034-0036], Durham teaches that a portion of a memory heap may be made available to applications requesting memory allocation, where the requests may include information of a particular size of block. The heap manager then fulfills the request accordingly and stores metadata including the information about the particular size of the requested block. The collection of the requested allocation size and metadata with information about the size is interpreted to be the claimed configuration information.).
setting, by the memory manager based on the configuration information, a memory protection key for each frame in the one or more units of dedicated memory assigned to the program ([0037], Durham teaches that a tag can be assigned to a block when it is allocated. Further, since Durham describes the tag assignment to protect against unauthorized access, the tag of Durham is interpreted to be the claimed memory protection key.).
While Durham teaches deallocation broadly, Durham does not appear to explicitly disclose dedicated memory is reserved for the program until program completion
However, Espy teaches dedicated memory is reserved for the program until program completion ([0064], Espy teaches that after an allocation is made, upon termination of the application, the memory that was previously allocated to the application can be returned to the memory pool, and made available.).
Durham and Espy are analogous art because they are from the same field of endeavor, memory allocation management.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Durham and Espy to achieve the result of a method which assigns units of memories to a program, which are reserved for the program until completion, which also sets a memory protection key for each assigned unit of memory.
One of ordinary skill in the art would have been motivated to make this modification in order to increase the amount of available space for further operation as discussed in Espy [0064].
Regarding claim 3: The combination of Durham and Espy teaches all limitations of claim 1, from which claim 3 depends.
Durham/Espy further teaches the pool of dedicated memory is physical memory ([0041], Durham describes the assigned blocks as being physically adjacent based on their physical addresses. While not explicit, the block allocation as discussed with respect to claim 1 are understood to be physical blocks, if they have physical addresses).
Regarding claim 6: The combination of Durham and Espy teaches all limitations of claim 1, from which claim 6 depends.
Durham/Espy further teaches the configuration information indicates at least one of a minimum amount of dedicated memory and a target amount of dedicated memory ([0034-0035], Durham teaches that a metadata can be stored, which contains an indication of the size of the block used in an allocation, which is interpreted as the target amount of dedicated memory.).
Regarding claim 7: The combination of Durham and Espy teaches all limitations of claim 1, from which claim 7 depends.
Durham/Espy further teaches the configuration information indicates the memory protection key ([0034-0037], Durham teaches that metadata contains a tag history, which includes the tags interpreted as the memory protection key.).
Regarding claim 8: The combination of Durham and Espy teaches all limitations of claim 1, from which claim 8 depends.
Durham/Espy further teaches the configuration information is stored in a parameter library that is read by the memory manager ([0035], Durham teaches that the collections of metadata can be stored together within a table, and that the metadata includes the tag history. Further, in [0022], Durham teaches a runtime tag checker that checks that a provided tag (part of an access) matches an assigned tag. Given that the metadata includes the tag histories, the runtime tag checker checking an assignment would obviously involve reading the metadata.).
Regarding claim 9: The combination of Durham and Espy teaches all limitations of claim 1, from which claim 9 depends.
Durham/Espy further teaches a program assignment and memory protection key for each frame of dedicated memory in the pool of dedicated memory is recorded in a page frame table ([0052-0053], Espy teaches a memory usage table that identifies the entities/applications to which memory is allocated to.).
One of ordinary skill in the art would have been motivated to make this modification in order to facilitate operations such as reallocation of memory after the entity is done using the memory as discussed in Espy [0052].
Regarding claim 10: The combination of Durham and Espy teaches all limitations of claim 1, from which claim 10 depends.
Durham/Espy further teaches receiving, by the memory manager from the program, a memory allocation request; and allocating, by the memory manager to the program, one or more frames of real memory from a unit of dedicated memory assigned to the program, wherein ([0034], Durham teaches that when an application requests memory allocation, the heap manager can service the request by allocating a data block of a particular size. Furthermore, in [0041], Durham describes the assigned blocks as being physically adjacent based on their physical addresses. While not explicit, the block allocation understood as allocating real memory if the allocations have physical addresses)
Durham/Espy further teaches the one or more frames are preset with the memory protection key of the program ([0034], Durham teaches that the setting of the tags is done at the time the allocation request is processed, which is interpreted to be the claimed frames preset with the memory protection key. Furthermore, while Durham does not teach keys of the program, [0052-0053], Espy teaches a memory usage table that identifies the entities/applications to which memory is allocated to, which is interpreted to be the keys of the program.)
One of ordinary skill in the art would have been motivated to make this modification in order to facilitate operations such as reallocation of memory after the entity is done using the memory as discussed in Espy [0052].
Regarding claim 11: The combination of Durham and Espy teaches all limitations of claim 10, from which claim 11 depends.
Durham/Espy further teaches receiving, from the program, a request to access data at a memory location corresponding to a frame of dedicated memory; and permitting the program to access data at the memory location in dependence upon determining that the program key associated with the program matches a memory protection key of the frame ([0022], Durham teaches that when an application attempts to access the allocated memory, it may provide a tag to a runtime tag checker (as discussed with respect to claim 10, the program key may be associated with the program), which verifies that the provided tag matches the assigned tag to allow service of the memory request if they match, or block the access if they do not match.)
Regarding claim 12: Durham teaches An apparatus comprising:
a processing device; and memory operatively coupled to the processing device, wherein the memory stores computer program instructions that, when executed, cause the processing device to: ([0027-0028], Durham teaches a processor and memory that is communicatively coupled to it, which stores data or instructions that are executed by the processor to perform the aspects of the disclosure of Durham.)
assign, to a program based on configuration information, one or more units of dedicated memory from a pool of dedicated memory, wherein the one or more units of dedicated memory is reserved for the program… and wherein an amount of dedicated memory is based on the configuration information ([0034-0036], Durham teaches that a portion of a memory heap may be made available to applications requesting memory allocation, where the requests may include information of a particular size of block. The heap manager then fulfills the request accordingly and stores metadata including the information about the particular size of the requested block. The collection of the requested allocation size and metadata with information about the size is interpreted to be the claimed configuration information.).
set, based on the configuration information, a memory protection key for each frame in the one or more units of dedicated memory assigned to the program ([0037], Durham teaches that a tag can be assigned to a block when it is allocated. Further, since Durham describes the tag assignment to protect against unauthorized access, the tag of Durham is interpreted to be the claimed memory protection key.).
While Durham teaches deallocation broadly, Durham does not appear to explicitly disclose dedicated memory is reserved for the program until program completion
However, Espy teaches dedicated memory is reserved for the program until program completion ([0064], Espy teaches that after an allocation is made, upon termination of the application, the memory that was previously allocated to the application can be returned to the memory pool, and made available.).
Durham and Espy are analogous art because they are from the same field of endeavor, memory allocation management.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Durham and Espy to achieve the result of a method which assigns units of memories to a program, which are reserved for the program until completion, which also sets a memory protection key for each assigned unit of memory.
One of ordinary skill in the art would have been motivated to make this modification in order to increase the amount of available space for further operation as discussed in Espy [0064].
Regarding claim 14: The combination of Durham and Espy teaches all limitations of claim 12, from which claim 14 depends.
Durham/Espy further teaches the pool of dedicated memory is physical memory ([0041], Durham describes the assigned blocks as being physically adjacent based on their physical addresses. While not explicit, the block allocation as discussed with respect to claim 12 are understood to be physical blocks, if they have physical addresses).
Regarding claim 16: The combination of Durham and Espy teaches all limitations of claim 12, from which claim 16 depends.
Durham/Espy further teaches the configuration information indicates at least one of a minimum amount of dedicated memory and a target amount of dedicated memory ([0034-0035], Durham teaches that a metadata can be stored, which contains an indication of the size of the block used in an allocation, which is interpreted as the target amount of dedicated memory.).
Regarding claim 17: The combination of Durham and Espy teaches all limitations of claim 12, from which claim 17 depends.
Durham/Espy further teaches the configuration information indicates the memory protection key ([0034-0037], Durham teaches that metadata contains a tag history, which includes the tags interpreted as the memory protection key.).
Regarding claim 18: The combination of Durham and Espy teaches all limitations of claim 12, from which claim 18 depends.
Durham/Espy further teaches the configuration information is stored in a parameter library that is read by the memory manager ([0035], Durham teaches that the collections of metadata can be stored together within a table, and that the metadata includes the tag history. Further, in [0022], Durham teaches a runtime tag checker that checks that a provided tag (part of an access) matches an assigned tag. Given that the metadata includes the tag histories, the runtime tag checker checking an assignment would obviously involve reading the metadata.).
Regarding claim 19: The combination of Durham and Espy teaches all limitations of claim 12, from which claim 19 depends.
Durham/Espy further teaches the memory stores computer program instructions that, when executed, cause the processing device to: (As discussed with respect to claim 12, Durham teaches a memory which stores instructions that are executed by the processor to perform the functions of the disclosure of Durham.)
Durham/Espy further teaches receive, from the program, a memory allocation request; and allocate, to the program, one or more frames of real memory from a unit of dedicated memory assigned to the program, wherein ([0034], Durham teaches that when an application requests memory allocation, the heap manager can service the request by allocating a data block of a particular size. Furthermore, in [0041], Durham describes the assigned blocks as being physically adjacent based on their physical addresses. While not explicit, the block allocation understood as allocating real memory if the allocations have physical addresses)
Durham/Espy further teaches the one or more frames are preset with the memory protection key of the program ([0034], Durham teaches that the setting of the tags is done at the time the allocation request is processed, which is interpreted to be the claimed frames preset with the memory protection key. Furthermore, while Durham does not teach keys of the program, [0052-0053], Espy teaches a memory usage table that identifies the entities/applications to which memory is allocated to, which is interpreted to be the keys of the program.)
One of ordinary skill in the art would have been motivated to make this modification in order to facilitate operations such as reallocation of memory after the entity is done using the memory as discussed in Espy [0052].
Regarding claim 20: Durham teaches:
A computer program product comprising a computer readable storage medium, wherein the computer readable storage medium comprises computer program instructions that, when executed: ([0105], Durham teaches that the techniques of the disclosure can be implemented by instructions on a machine-readable medium.)
assign, to a program based on configuration information, one or more units of dedicated memory from a pool of dedicated memory, wherein the one or more units of dedicated memory is reserved for the program… and wherein an amount of dedicated memory is based on the configuration information ([0034-0036], Durham teaches that a portion of a memory heap may be made available to applications requesting memory allocation, where the requests may include information of a particular size of block. The heap manager then fulfills the request accordingly and stores metadata including the information about the particular size of the requested block. The collection of the requested allocation size and metadata with information about the size is interpreted to be the claimed configuration information.).
set, based on the configuration information, a memory protection key for each frame in the one or more units of dedicated memory assigned to the program ([0037], Durham teaches that a tag can be assigned to a block when it is allocated. Further, since Durham describes the tag assignment to protect against unauthorized access, the tag of Durham is interpreted to be the claimed memory protection key.).
While Durham teaches deallocation broadly, Durham does not appear to explicitly disclose dedicated memory is reserved for the program until program completion
However, Espy teaches dedicated memory is reserved for the program until program completion ([0064], Espy teaches that after an allocation is made, upon termination of the application, the memory that was previously allocated to the application can be returned to the memory pool, and made available.).
Durham and Espy are analogous art because they are from the same field of endeavor, memory allocation management.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Durham and Espy to achieve the result of a method which assigns units of memories to a program, which are reserved for the program until completion, which also sets a memory protection key for each assigned unit of memory.
One of ordinary skill in the art would have been motivated to make this modification in order to increase the amount of available space for further operation as discussed in Espy [0064].
Claims 2, 13 are rejected under 35 U.S.C. 103 as being unpatentable over
Durham et al., U.S. Pub. No. 20200125502 (hereinafter “Durham”) in view of
Espy et al., U.S. Pub. No. 20210216320 (hereinafter “Espy”) further in view of
Foster et al., U.S. Patent No. 6240492 (hereinafter “Foster”).
Regarding claim 2: The combination of Durham and Espy teaches all limitations of claim 1, from which claim 2 depends.
Durham/Espy does not appear to explicitly disclose the pool of dedicated memory is located in system memory in an area that is separate from a shared memory area.
However, Foster teaches the pool of dedicated memory is located in system memory in an area that is separate from a shared memory area (Fig. 1 and 2 and Col. 5 Line 53 to Col. 6 line 18, Foster teaches a system which has a dedicated memory and shared memory as different units within a system, which are separated and reside in different locations.).
Durham/Espy are analogous art because they are from the same field of endeavor, memory allocation management.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Durham/Espy and Foster to achieve the combined result of the method of claim 1, which includes a pool of dedicated memory and a shared memory, which are located separately.
One of ordinary skill in the art would have been motivated to make this modification in order to take advantage of the flexibility and scalability of a shared memory, while providing the performance optimization and cost advantages of dedicated memory as discussed in Foster Col. 4, lines 13-29.
Regarding claim 13: The combination of Durham and Espy teaches all limitations of claim 12, from which claim 13 depends.
Durham/Espy does not appear to explicitly disclose the pool of dedicated memory is located in system memory in an area that is separate from a shared memory area.
However, Foster teaches the pool of dedicated memory is located in system memory in an area that is separate from a shared memory area (Fig. 1 and 2 and Col. 5 Line 53 to Col. 6 line 18, Foster teaches a system which has a dedicated memory and shared memory as different units within a system, which are separated and reside in different locations.).
Durham/Espy are analogous art because they are from the same field of endeavor, memory allocation management.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Durham/Espy and Foster to achieve the combined result of the apparatus of claim 12, which includes a pool of dedicated memory and a shared memory, which are located separately.
One of ordinary skill in the art would have been motivated to make this modification in order to take advantage of the flexibility and scalability of a shared memory, while providing the performance optimization and cost advantages of dedicated memory as discussed in Foster Col. 4, lines 13-29.
Claims 4, 15 are rejected under 35 U.S.C. 103 as being unpatentable over
Durham et al., U.S. Pub. No. 20200125502 (hereinafter “Durham”) in view of
Espy et al., U.S. Pub. No. 20210216320 (hereinafter “Espy”) further in view of
Pang, U.S. Patent No. 8892610 (hereinafter “Pang”).
Regarding claim 4: The combination of Durham and Espy teaches all limitations of claim 1, from which claim 4 depends.
While Durham teaches that allocations occur during program runtime, Durham/Espy does not appear to explicitly disclose the one or more units of dedicated memory is assigned and the memory protection key is set before receiving a memory allocation request from the program.
However, Pang teaches the one or more units of dedicated memory is assigned and the memory protection key is set before receiving a memory allocation request from the program. (Col. 1 lines 41-47, Pang teaches allocating an initial set of memory objects for a program during startup of the program, before additional objects are allocated during execution.).
Durham/Espy and Pang are analogous art because they are from the same field of endeavor, memory allocation management.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Durham/Espy and Pang to achieve the combined result of the method of claim 1, including the assigning blocks and setting a protection key, to also allocate memory during startup of the program, before further requests are made.
One of ordinary skill in the art would have been motivated to make this modification in order to facilitate initialization and still facilitate requests during program execution as discussed in Pang Col. 1 lines 16-40.
Regarding claim 15: The combination of Durham and Espy teaches all limitations of claim 12, from which claim 15 depends.
While Durham teaches that allocations occur during program runtime, Durham/Espy does not appear to explicitly disclose the one or more units of dedicated memory is assigned and the memory protection key is set before receiving a memory allocation request from the program.
However, Pang teaches the one or more units of dedicated memory is assigned and the memory protection key is set before receiving a memory allocation request from the program (Col. 1 lines 41-47, Pang teaches allocating an initial set of memory objects for a program during startup of the program, before additional objects are allocated during execution.).
Durham/Espy and Pang are analogous art because they are from the same field of endeavor, memory allocation management.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Durham/Espy and Pang to achieve the combined result of the apparatus of claim 12, including the assigning blocks and setting a protection key, to also allocate memory during startup of the program, before further requests are made.
One of ordinary skill in the art would have been motivated to make this modification in order to facilitate initialization and still facilitate requests during program execution as discussed in Pang Col. 1 lines 16-40.
Claims 5, 16 are rejected under 35 U.S.C. 103 as being unpatentable over
Durham et al., U.S. Pub. No. 20200125502 (hereinafter “Durham”) in view of
Espy et al., U.S. Pub. No. 20210216320 (hereinafter “Espy”) further in view of
THYAGATURU et al., U.S. Pub. No. 20230205594 (hereinafter “Thyagaturu”).
Regarding claim 5: The combination of Durham and Espy teaches all limitations of claim 1, from which claim 5 depends.
Durham/Espy does not appear to explicitly disclose the one or more units of dedicated memory is assigned and the memory protection key is set during system initialization
However, Thyagaturu teaches the one or more units of dedicated memory is assigned during system initialization ([0025], Thyagaturu teaches that allocation of hardware resources happens within boot firmware code, which is interpreted as the assigning memory during system initialization).
Durham/Espy and Thyagaturu are analogous art because they are from the same field of endeavor, memory allocation management.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Durham/Espy and Thyagaturu to achieve the combined result of the system which performs memory allocations by assigning memory to programs, to be performed during system initialization.
One of ordinary skill in the art would have been motivated to make this modification in order to provide proper memory resource allocations to operating systems as defined by the boot code as discussed in Thyagaturu [0025].
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KAITLYN HUNG PHAM whose telephone number is (571)272-6333. The examiner can normally be reached M/Tu/Th/F 8:00-6:00 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, 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.
/K.H.P./Examiner, Art Unit 2133
/ROCIO DEL MAR PEREZ-VELEZ/Supervisory Patent Examiner, Art Unit 2133
Prosecution Insights