DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is responsive to the application filed 17 June 2024.
Claims 1-50 are pending and have been presented for examination.
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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(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-5, 12-14, 16, 19, 20, 22-29, 31 and 48-50 are is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by LEMAY-080 (U.S. Patent Application Publication #2024/0054080).
1. LEMAY-080 discloses A method, comprising: at a device (see [0038]: system 104) responsive to a memory access request having a pointer to an object in memory (see [0072]: generate memory access request): executing in hardware a first instruction to retrieve metadata associated with the object (see [0073]: processor core fetched color data for the cache line), wherein the first instruction is generated by software (see [0058]: software instructions can load and check tags, or dedicated hardware support and perform the check); and executing in the hardware a second instruction to perform a memory safety check using the metadata (see [0074]: pointer security circuitry performs memory safety check), wherein the second instruction is generated by the software (see [0058]: software instructions can load and check tags, or dedicated hardware support and perform the check); when the memory safety check indicates an unsafe memory condition, returning an indication of the unsafe memory condition (see [0075]: updating MSR bits; [0059]: exception raised using the MSR if there is a mismatch); and when the memory safety check indicates a safe memory condition, performing the memory access (see [0075]: core proceeds with the access based on the results of the security check).
2. The method of claim 1, wherein the pointer points to an arbitrary location in the object (see [0057]: pointer will point to a number of memory elements within an allocation of memory).
3. The method of claim 1, wherein the metadata is object-level metadata (see [0046]: color value is associated with a virtual address for data, this is considered an object).
4. The method of claim 1, wherein the metadata is an N-byte granular metadata (see [0048]: bits within the virtual address are used as the tag to enforce memory safety checks, this group of bits would be the granular metadata).
5. The method of claim 1, wherein the metadata includes at least one of: a size of the object (see [0050]: bounds), or a tag (see [0048]: tag based on bits of the virtual address).
12. The method of claim 1, wherein the first instruction includes as input a base address associated with the pointer (see [0072]: memory access request includes information from a pointer including a virtual address).
13. The method of claim 12, wherein the first instruction causes the hardware to use the base address associated with the pointer to retrieve the metadata (see [0073]: metadata associated with the virtual address in the pointer is retrieved) which includes at least one of: a size of the object (see [0050]: bounds), or a tag (see [0048]: tag based on bits of the virtual address).
14. The method of claim 13, wherein the first instruction causes the hardware to perform at least one verification of the metadata (see [0074]-[0075]: memory safety check using the pointer security circuitry).
16. The method of claim 14, wherein the at least one verification includes verifying that a tag of the base address associated with the pointer matches a tag indicated in the metadata (see [0061]: a base address stored in a register is used to locate metadata associated with a pointer).
19. The method of claim 1, wherein the second instruction includes as input a memory address corresponding to the pointer and a location of the metadata (see [0075]: the memory safety check accesses the location of the metadata in the cache line that is associated with the pointer).
20. The method of claim 19, wherein the second instruction causes the hardware to use the location of the metadata to retrieve from the metadata a size (see [0050]: metadata includes a bound distance, which is a size).
22. The method of claim 20, wherein a tag is further retrieved from the metadata, and wherein the second instruction causes the hardware to perform the memory safety check by: comparing a portion of the address corresponding to the pointer with the tag, and raising an exception when the portion of the address does not match the tag (see [0059]: raise an exception when there is a mismatch with the tag).
23. The method of claim 1, wherein the second instruction includes as input the metadata (see [0075]: the metadata the was fetched is used as input to perform the safety check).
24. The method of claim 1, wherein the hardware uses a finite state machine (FSM) to retrieve the metadata (see [0041]: the CPU moves data between the processor and memory, this would include the metadata that is fetched from memory, a CPU is a finite state machine).
25. The method of claim 1, wherein the first instruction causes the hardware to first search a metadata lookaside buffer (MLB) for the metadata, wherein the MLB stores metadata for recently access objects (see LEMAY-080 [0053]: pointer metadata table to retrieve memory tags).
26. The method of claim 1, wherein the hardware is a graphics processing unit (GPU) (see [0106]: processor can be a graphics processor).
27. LEMAY-080 discloses A system, comprising: computer hardware that is responsive to a memory access request having a pointer to an object in memory (see [0072]: generate memory access request) to: execute a first instruction to retrieve metadata associated with the object (see [0073]: processor core fetched color data for the cache line), wherein the first instruction is generated by software (see [0058]: software instructions can load and check tags, or dedicated hardware support and perform the check); and execute a second instruction to perform a memory safety check using the metadata (see [0074]: pointer security circuitry performs memory safety check), wherein the second instruction is generated by the software (see [0058]: software instructions can load and check tags, or dedicated hardware support and perform the check); when the memory safety check indicates an unsafe memory condition, returning an indication of the unsafe memory condition (see [0075]: updating MSR bits; [0059]: exception raised using the MSR if there is a mismatch); and when the memory safety check indicates a safe memory condition, performing the memory access (see [0075]: core proceeds with the access based on the results of the security check).
28. The system of claim 27, wherein the computer hardware is a graphics processing unit (GPU) (see [0106]: graphics processor).
29. The system of claim 27, wherein the system further comprises: a non-transitory memory storage comprising the software (see [0178]-[0179]: machine readable media with instructions stored thereon); and at least one processor that executes the software to generate the first instruction and the second instruction (see [0106]: processor).
31. The system of claim 29, wherein the at least one processor is a central processing unit (CPU) (see [0106]: CPU).
48. LEMAY-080 discloses A method, comprising: at a device, responsive to a memory access request having a pointer to an object in memory (see [0072]: generate memory access request): executing at least one instruction in hardware to: retrieve metadata associated with the object (see [0073]: processor core fetched color data for the cache line), perform a memory safety check using the metadata (see [0074]: pointer security circuitry performs memory safety check), and perform the memory access based on a result of the memory safety check (see [0075]: core proceeds with the access based on the results of the security check); wherein the at least one instruction is generated by software (see [0058]: software instructions can load and check tags, or dedicated hardware support and perform the check).
49. The method of claim 48, wherein the at least one instruction includes a single instruction that retrieves the metadata and performs the memory safety check using the metadata (see [0075]: metadata is retrieved from the cache line and used to perform the memory safety check).
50. The method of claim 48, wherein the at least one instruction includes a single instruction that performs the memory safety check using the metadata and performs the memory access based on the result of the memory safety check (see [0075]: metadata is retrieved from the cache line and used to perform the memory safety check, if the verification passes, the access proceeds).
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.
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) 6 and 30 is/are rejected under 35 U.S.C. 103 as being unpatentable over LEMAY-080 (U.S. Patent Application Publication #2024/0054080) in view of LEMAY-108 (U.S. Patent Application Publication #2024/0354108).
6. The method of claim 1 (see LEMAY-080 above), wherein the software is a compiler (see LEMAY-108 below).
LEMAY-108 discloses the following limitations that are not taught by LEMAY-080: wherein the software is a compiler (see [0166]: compiler can attach prefixes to memory access instructions). Allowing the compiler to attach prefixes to each instruction reduces overhead of memory safety checks by skipping checks for accesses that are always safe (see [0166]).
It would have been obvious, before the effective filing date of the claimed invention, to a person having ordinary skill in the art to which said subject matter pertains to modify LEMAY-080 to implement memory safety instructions in a compiler, as disclosed by LEMAY-108. One of ordinary skill in the art would have been motivated to make such a modification to reduce overhead of memory safety checks, as taught by LEMAY-108. LEMAY-080 and LEMAY-108 are analogous/in the same field of endeavor as both references are directed to memory safety.
30. The system of claim 29 (see LEMAY-080 above), wherein the software is a compiler (see LEMAY-108 below).
LEMAY-108 discloses the following limitations that are not taught by LEMAY-080: wherein the software is a compiler (see [0166]: compiler can attach prefixes to memory access instructions). Allowing the compiler to attach prefixes to each instruction reduces overhead of memory safety checks by skipping checks for accesses that are always safe (see [0166]).
It would have been obvious, before the effective filing date of the claimed invention, to a person having ordinary skill in the art to which said subject matter pertains to modify LEMAY-080 to implement memory safety instructions in a compiler, as disclosed by LEMAY-108. One of ordinary skill in the art would have been motivated to make such a modification to reduce overhead of memory safety checks, as taught by LEMAY-108. LEMAY-080 and LEMAY-108 are analogous/in the same field of endeavor as both references are directed to memory safety.
Claim(s) 7 and 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over LEMAY-080 (U.S. Patent Application Publication #2024/0054080) and LEMAY-108 (U.S. Patent Application Publication #2024/0354108) as applied to claims 1-6, 12-14, 16, 19, 20, 22-31 and 48-50 above, and further in view of LIU (U.S. Patent Application Publication #2023/0195599).
7. The method of claim 6 (see above), wherein the compiler inserts the first instruction and the second instruction in a control flow graph generated for a program having the memory access request (see LIU below).
LIU discloses the following limitations that are not taught by LEMAY-080: wherein the compiler inserts the first instruction and the second instruction in a control flow graph generated for a program having the memory access request (see [0027]: control flow graph with blocks for the instructions executed by the program). The use of a control flow graph allows for analyzing data dependence relationships between instructions (see [0003]-[0004]).
It would have been obvious, before the effective filing date of the claimed invention, to a person having ordinary skill in the art to which said subject matter pertains to modify LEMAY-080 to insert the instructions in a control flow graph, as disclosed by LIU. One of ordinary skill in the art would have been motivated to make such a modification to allow for analyzing data dependence relationships, as taught by LIU. LEMAY-080 and LIU are analogous/in the same field of endeavor as both references are directed to managing access to data in memory.
8. The method of claim 7, wherein the first instruction is inserted at a location in the control flow graph and with an input address both determined by a static-time or a compile-time analysis of the pointer (see LIU [0032]: static assignment of variable).
Claim(s) 9-11 is/are rejected under 35 U.S.C. 103 as being unpatentable over LEMAY-080 (U.S. Patent Application Publication #2024/0054080), LEMAY-108 (U.S. Patent Application Publication #2024/0354108) and LIU (U.S. Patent Application Publication #2023/0195599) as applied to claims 1-8, 12-14, 16, 19, 20, 22-31 and 48-50 above, and further in view of WANG (U.S. Patent Application Publication #2015/0242626).
9. The method of claim 8 (see above), wherein the analysis includes backward slicing from the memory access request through pointer arithmetic until a pointer creation instruction is reached (see WANG below).
WANG discloses the following limitations that are not taught by LEMAY-080: wherein the analysis includes backward slicing from the memory access request through pointer arithmetic until a pointer creation instruction is reached (see [0016]: backward slicing to determine the recorded initialized memory address). This allows the system to detect malware (see [0002]).
It would have been obvious, before the effective filing date of the claimed invention, to a person having ordinary skill in the art to which said subject matter pertains to modify LEMAY-080 to perform backward slicing, as disclosed by WANG. One of ordinary skill in the art would have been motivated to make such a modification to detect malware, as taught by WANG. LEMAY-080 and WANG are analogous/in the same field of endeavor as both references are protecting access to system resources.
10. The method of claim 9, wherein the first instruction is inserted in the control flow graph and corresponds to the memory access request (see LIU [0027]: control flow blocks include instructions executed by the program), and wherein the first instruction includes as the input address a compiler-identified base pointer created by the pointer creation instruction (see LEMAY-080 [0061]: the first instruction that retrieves the metadata uses a base physical address stored in a register).
11. The method of claim 10, wherein the compiler propagates the metadata retrieved by the first instruction to the second instruction (see LEMAY-080 [0074]-[0075]: the retrieved metadata is forwarded and used by the pointer security circuitry to perform the memory safety check).
Claim(s) 17 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over LEMAY-080 (U.S. Patent Application Publication #2024/0054080).
17. The method of claim 14, wherein the first instruction returns a zero when the at least one verification fails (see below).
LEMAY-080 discloses setting MSR bits based on the result of the memory safety check. It is well-know that digital computer systems operate using 1’s and 0’s. The decision to use a 1 or a 0 to represent a verification fail is a matter of design choice. “When there is a design need for market pressure to solve a problem and there are a finite number if identified, predictable solutions, a person of ordinary skill has good reason to pursue the known options within his or her technical grasp." KSR, 82 USPQ2d at 1397.
It would have been obvious, before the effective filing date of the claimed invention, to a person having ordinary skill in the art to which said subject matter pertains to modify LEMAY-080 to return a zero. One of ordinary skill in the art would have been motivated to make such a modification as this is a matter of design choice, and would have been obvious to try.
18. The method of claim 1, wherein the first instruction returns a zero when the metadata does not exist (see below).
LEMAY-080 discloses setting MSR bits based on the result of the memory safety check. It is well-know that digital computer systems operate using 1’s and 0’s. The decision to use a 1 or a 0 to represent missing metadata is a matter of design choice. “When there is a design need for market pressure to solve a problem and there are a finite number if identified, predictable solutions, a person of ordinary skill has good reason to pursue the known options within his or her technical grasp." KSR, 82 USPQ2d at 1397.
It would have been obvious, before the effective filing date of the claimed invention, to a person having ordinary skill in the art to which said subject matter pertains to modify LEMAY-080 to return a zero. One of ordinary skill in the art would have been motivated to make such a modification as this is a matter of design choice, and would have been obvious to try.
Allowable Subject Matter
Claims 32-47 are allowed.
Claims 15 and 21 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.
The following is a statement of reasons for the indication of allowable subject matter:
The state of the art fails to anticipate, or render obvious, “… wherein the at least one verification includes verifying that a difference between the base address associated with the pointer and a location of the metadata is smaller than a size indicated in the metadata.”
The state of the art fails to anticipate, or render obvious, “… computing a difference between the address corresponding to the pointer and the location of the metadata, and raising an exception when the difference is greater than the size.”
LEMAY-080 discloses obtaining the metadata using a base address (see [0061]-[0062]). LEMAY-080 fails to disclose checking a size between an address and a location of the metadata. The sizes that LEMAY-080 checks for memory safety include the address bounds that are access by the pointer (see [0050]-[0051]).
The state of the art fails to anticipate, or render obvious, “… backward slicing from the memory access request through pointer arithmetic until a pointer creation instruction is reached, and determining a candidate base pointer created by the pointer creation instruction, wherein the candidate base pointer is the input address for the first instruction to be generated; generate the first instruction that causes hardware of the device to retrieve metadata associated with the object; and generate a second instruction that causes the hardware of the device to perform a memory safety check using the metadata.”
LEMAY-080 uses a base address to locate metadata and WANG discloses backward slicing to detect malware. A combination of these references would not utilize the address obtained from backward slicing in the manner claimed.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
“Comprehensive Memory Safety Validation”: discloses comprehensive memory safety validation by checking pointers to the stack or heap. [Pages 42-44]
“Pointer Checker” discloses hardware assisted memory safety checking using tagged pointers. [Pages 97-99]
“Hardware-Enforced Comprehensive Memory Safety” discloses metadata checking to enforce and restrict the bounds of pointers. [Pages 40-44]
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDWARD J DUDEK JR whose telephone number is (571)270-1030. The examiner can normally be reached Monday - Friday, 8:00A-4:00P.
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 T 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.
/EDWARD J DUDEK JR/Primary Examiner, Art Unit 2132
Prosecution Insights