DETAILED ACTION
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 03/17/2026 has been entered.
Response to Amendment
Applicant's response with amendments filed on 03/17/2026 has been received and entered. Applicant has amended claims 1, 2, 11 and 20; canceled claims 8-10; and, added claims 21-23. Claims 1-7 and 11-23 have been examined on the merits.
Response to Arguments
Applicant's arguments filed on 03/17/2026 have been fully considered but they are not persuasive.
Regarding claim 2, as amended, Applicant argues that:
“[…] Bramley discloses tag mapping storage circuitry 64, which remaps guard tag values to produce remapped tags for comparison. Bramley, [0093]. This tag remapping mechanism is not a permission store as recited by claim 2. Specifically, Bramley's tag mapping storage does not comprise rows corresponding to tags with per-client permission vector fields. Rather, Bramley's tag mapping storage translates one tag value to another - a fundamentally different structure and function from a permission store that indexes permission vectors by tag and by client to determine whether a particular client is authorized to access a particular memory page.” (Applicant’s remarks, page 11, emphasis added)
Bramley teaches a tag mapping storage (64) indexing access rights (i.e., permissions such as read (R), write (W) and execute (X)) by guard tag value and address tag value (see [0093-95], FIG. 9). The same tag mapping storage (64) is illustrated in FIG. 11 to show an example tag check involving selecting a mapping to use based on a thread (i.e., client) being executed. The tag mapping storage circuitry (64) is arranged to store a plurality of sets of mapping information corresponding to different threads and the thread ID (46) of the thread executing on processing circuitry (4) is used to identify which set of mapping information to use. For instance, in FIG. 11, the thread ID (46) is 0x12A7 and so the set of mapping information associated with thread 0x12A7 is used to map the guard tag (32) to remapped tag (52) having a value of 0b1011. The tag mapping storage circuitry (64) is configured to store a plurality of sets of mapping information in a bank of mapping registers (68); each of these registers identified with a corresponding thread ID (i.e., client ID), as shown in FIG. 11, and tag values and permissions, as shown in FIG. 9. Mapping information corresponding to several threads may be stored in the tag mapping storage circuitry (64) at the same time. See [0096-97].
In addition, Bramley discloses, inter alia:
"The present technique provide support for remapping of at least one of the guard tag and address tag involved in a tag check, and basing the tag check on the at least one remapped tag. In this way, a different mapping between tags can be used for threads that are to be kept separate from each other. Even if a thread were to try to reuse a target address and address tag combination used by a different thread that led to a match between the address tag and the guard tag associated the target address, the at least one of the guard tag and address tag could be remapped differently so that the tag check detected a mismatch when the tag was reused (even though the two threads are accessing the same physical address in memory). Therefore, a thread attempting to access data belonging to another thread may be identified and an appropriate action taken (e.g. the two threads could correspond to browser tabs as in the example above).” (Bramley, [0036])
"This approach enables sandboxing of portions of code without the need to use a different process for each sandbox, and avoiding the overhead of having to rearrange the guard tags in memory or maintain a separate set of page tables for each sandbox. Such an approach also allows access rights to memory to be controlled on a thread-by-thread basis at a granularity finer than the page-level granularity used by the page tables, which typically refer to regions of 4 KB, 16 KB, or 64 KB for example, as different guard tag values could be assigned to different portions of a single page and subject to different mappings between guard/address tags for different threads." (Bramley, [0037], emphasis added)
“In addition to storing the remapped tag values in the plurality of remapped tag value fields of the mapping information, the fields of mapping information could also be used to store permissions information in association with the remapped tag values. Each field could therefore specify not only the remapped tag value that is to be used in the comparison but also an indication of the types of memory access allowed. For example, for each item of mapping information, one or more bits may be provided to indicate permissions information. This allows the tag checking circuitry to ensure not only that a portion of code executing should have access to a given block of memory locations, but that the portion of code has sufficient access rights for the type of access that is sought.” (Bramley, [0062], emphasis added)
In [0036-37] and [0062] above, Bramley teaches that the tag mapping mechanism not only ensures that a thread (i.e., client) should have access to a given memory location, but also that it has sufficient access rights to do so. In other words, Bramley’s mechanism not only checks and remaps tags to protect against certain memory usage errors (e.g., a thread attempting to access data belonging to another thread), but also controls access to memory using permissions (e.g. read/write/execute).
Accordingly, Bramley teaches a permission store that indexes permission vectors by tag and by client (e.g., thread) to determine whether a particular client is authorized to access a particular memory location and what type of access is allowed for that particular client (e.g., read/write/execute or a combination thereof).
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-7, 11-12, 15-18 and 20-23 are rejected under 35 U.S.C. 103 as being unpatentable over Bramley et al. (US20230236925A1), hereinafter Bramley, in view of Goss et al. (US20210240637A1), hereinafter Goss.
Regarding claim 1, Bramley discloses a device (“data processing apparatus 2”), comprising:
one or more processors, the one or more processors comprising a secure processor (processing circuitry 4 – see [0079], Fig. 1);
a set of instructions encoded on a non-transitory computer readable medium and executable by the secure processor, the set of instructions comprising (instructions decoded by an instruction decoder 6 – see [0079], Fig. 1):
instructions to store, with a secure client, a plurality of tags in tag store (tag storage locations (34), see FIG. 2, [0080]) [[memory]] in a secure environment of the device (the guard tag which is associated with a given block of memory locations can be stored at any other memory location within the memory system - see [0042]; the guard tags may be relatively small, for example, 4 or 8 bits, and so multiple guard tags each associated with a different block of memory locations may fit within the same memory location – see [0043]), each one of the plurality of tags being assigned to a different one of a plurality of memory pages in a [[memory of the data processing apparatus 2]], the plurality of tags comprising a first tag assigned to a first memory page, and the (the apparatus may provide permissions information at a level of granularity of the blocks of memory locations for which separate guard tags are defined; may allow more fine-grained permissions to be implemented by setting different guard tag values for different addresses in the same page and associating different permissions with those guard tag values, or by specifying different guard-tag/address-tag mappings for accesses of different types – see [0059]; each page table entry may provide an address translation mapping for a corresponding page of addresses and may also specify access control parameters (e.g., access permissions specifying access types and privilege levels) – see [0079]); and
a memory manager (MMU 20 and related circuitry – see Fig. 1), comprising:
circuitry to store the plurality of tags in the [[memory]] (the guard tag which is associated with a given block of memory locations can be stored at any other memory location within the memory system - see [0042]; the guard tags may be relatively small, for example, 4 or 8 bits, and so multiple guard tags each associated with a different block of memory locations may fit within the same memory location – see [0043]; see also Fig. 1);
circuitry to store, in a permission store within the [[memory]], a plurality of permission vectors, the permission store comprising a plurality of rows, each of the plurality of rows corresponding to one of the plurality of tags, the plurality of rows comprising a first row corresponding to the first tag, the first row comprising a plurality of fields storing one or more permission vectors foreach of a plurality of clients, the plurality of fields comprising a first field storing a first permission vector for the untrusted client (guard tag 32 is remapped to produce a remapped tag 52 using the mapping information stored by the tag mapping storage circuitry 64; tag mapping information specifies a plurality of remapped tag value fields made up of an address tag value that will match the associated guard tag value and permissions information - see [0093]; to generate the remapped tag 52, guard tag value, 0b0100, is looked up in the mapping information and it can be identified that the corresponding address tag value is 0b10101001 and the allowed types of access to blocks of memory locations associated with that guard tag 52 are read and write – see [0094]; FIGS. 8 and 9 show examples in which a field is used to store the permissions information for each item of mapping information – see [0095]; FIG. 11 shows an example tag check involving selecting a mapping to use based on the thread being executed; the tag mapping storage circuitry 64 is arranged to store a plurality of sets of mapping information corresponding to different threads and the thread ID 46 of the thread executing on the processing circuitry 4 is used to identify which set of mapping information to use; in FIG. 11, the thread ID 64 is 0x12A7 and so the set of mapping information associated with thread 0x12A7 is used to map the guard tag 32 to remapped tag 52 having a value of 0b1011 – see [0096-97]; examiner’s note: see “tag mapping storage 64”, in FIG. 9, wherein each row corresponds to a guard tag, and each row includes a field storing permissions (e.g., read, write, execute) for each guard tag; in FIG. 11 the tags and permissions correspond to a thread ID; in this case the thread, which is a software process executed by a processor, is the client);
circuitry to receive an access request, from an untrusted client, for access to the first memory page (memory access circuitry 15 receives a read access request as illustrated by access type 44 - see [0093], Figs. 2, 9 and 11);
circuitry to identify the first tag assigned to the first memory page (read access request 44 specifies a memory location comprised by a block of memory locations 30 associated with guard tag 32 [0093]; Figs. 2, 9 and 11; see also Fig. 1);
circuitry to receive a client identifier of the untrusted client; circuitry to identify the first row in the permission store corresponding to the first tag; circuitry to identify the first field storing the first permission vector for the untrusted client (the tag mapping storage circuitry 64 is arranged to store a plurality of sets of mapping information corresponding to different threads and the thread ID 46 of the thread executing on the processing circuitry 4 is used to identify which set of mapping information to use; the thread ID 64 is 0x12A7 and so the set of mapping information associated with thread 0x12A7 is used to map the guard tag 32 to remapped tag 52 having a value of 0b1011; this remapped tag value 52 is compared with the address tag 40 in the tag check – see [0096], FIG. 11; examiner’s note: in FIG. 11, the tag mapping storage 64 is the same as the one shown in FIG. 9 with the addition of the thread IDs for each register 68; as shown in FIG. 9, each register includes the permission information – read, write, execute - corresponding to each tag value/thread ID)
circuitry to determine whether the untrusted client is authorized to access the first memory page, based at least in part on the first permission vector (guard tag 32 is remapped to produce a remapped tag 52 using the mapping information stored by the tag mapping storage circuitry 64 in order to match the associated guard tag value with permissions information (e.g., read, write, execute) – see [0093], Figs. 9 and 11; see also Fig. 1); and
circuitry to provide the untrusted client with access to the first memory page based at least in part on a determination that the untrusted client is authorized to access the first memory page (the allowed types of access to blocks of memory locations associated with that guard tag 52 are read and write; remapped tag 52 and the address tag 40 are then compared in the tag check and allowed access types indicated by the permission information 54 and the requested access type 44 are compared in a permissions check; the address tag 40 and the remapped tag 52 match and the requested access type 44 is an allowed access type and so no error response action is performed; an error response action is carried out if tags do not match – see [0094], Fig. 9 and 11; see also Fig. 1).
Bramley does not explicitly disclose what type of memory is being used; that is, Bramley discloses a tag store within the memory, but not a tag store within a secure RAM. The disclosure refers to it as “memory system” [0042], but it is not specific about it being a secure RAM and/or a DRAM.
However, in the same field of endeavor, Goss discloses a system and method for secure demand paging and paging operations wherein the memory includes a tag store within a secure RAM, and a separate DRAM (security logic 1038 makes secure ROM space inaccessible, makes secure RAM and register space inaccessible and establishes any other appropriate protections to additionally foster security – see [0083]; as illustrated in Fig. 4, secure RAM 1034 is associated with secure swapper 2160, which is coupled to a non-secure DRAM holding encrypted/authenticated pages; PA2VA 2120 (which is provided in secure RAM space) containing page table entries (PTEs) identifying pages is maintained secure on-chip (i.e., in the secure RAM, see [0195]); PTEs identify which pages are stored in the secure RAM and the pages in the DRAM are mapped to pages in the secure RAM; that is, both the secure RAM and the DRAM are storing pages - see [0155-0156], [0160], [0167], [0195] and Fig. 4; see also “Response to Amendment/Arguments” section above).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the device in Bramley to include a tag store within a secure RAM, and a separate DRAM, as taught by Goss. One would have been motivated to make such a combination to provide advanced networking capability for services, software, content, and other services to accommodate and provide security for secure utilization and entertainment appropriate to these and other applications, and to provide security with much greater extensibility and flexibility that increases performance and security using a limited resource, as recognized by Goss ([0060] and [0194]).
Regarding claim 2, Bramley discloses a device, comprising:
logic to store, in a tag store (tag storage locations (34), see FIG. 2, [0080]) , a plurality of tags (the guard tag which is associated with a given block of memory locations can be stored at any other memory location within the memory system - see [0042]; the guard tags may be relatively small, for example, 4 or 8 bits, and so multiple guard tags each associated with a different block of memory locations may fit within the same memory location – see [0043]), each one of the plurality of tags being assigned to a different one of a plurality of memory pages in a [[memory]] the plurality of tags comprising a first tag assigned to a first memory page (the apparatus may provide permissions information at a level of granularity of the blocks of memory locations for which separate guard tags are defined; may allow more fine-grained permissions to be implemented by setting different guard tag values for different addresses in the same page and associating different permissions with those guard tag values, or by specifying different guard-tag/address-tag mappings for accesses of different types – see [0059]; each page table entry may provide an address translation mapping for a corresponding page of addresses and may also specify access control parameters (e.g., access permissions specifying access types and privilege levels) – see [0079]);
logic to store, in a permission store within the (guard tag 32 is remapped to produce a remapped tag 52 using the mapping information stored by the tag mapping storage circuitry 64; tag mapping information specifies a plurality of remapped tag value fields made up of an address tag value that will match the associated guard tag value and permissions information - see [0093]; to generate the remapped tag 52, guard tag value, 0b0100, is looked up in the mapping information and it can be identified that the corresponding address tag value is 0b10101001 and the allowed types of access to blocks of memory locations associated with that guard tag 52 are read and write – see [0094]; FIGS. 8 and 9 show examples in which a field is used to store the permissions information for each item of mapping information – see [0095]; FIG. 11 shows an example tag check involving selecting a mapping to use based on the thread being executed; the tag mapping storage circuitry 64 is arranged to store a plurality of sets of mapping information corresponding to different threads and the thread ID 46 of the thread executing on the processing circuitry 4 is used to identify which set of mapping information to use; in FIG. 11, the thread ID 64 is 0x12A7 and so the set of mapping information associated with thread 0x12A7 is used to map the guard tag 32 to remapped tag 52 having a value of 0b1011 – see [0096-97]; examiner’s note: see “tag mapping storage 64”, in FIG. 9, wherein each row corresponds to a guard tag, and each row includes a field storing permissions (e.g., read, write, execute) for each guard tag; in FIG. 11 the tags and permissions correspond to a thread ID; in this case the thread, which is a software process executed by a processor, is the client);
logic to receive an access request from a client for access to the first memory page (memory access circuitry 15 receives a read access request as illustrated by access type 44 - see [0093], Figs. 2, 9 and 11);
logic to identify the first tag assigned to the first memory page (read access request 44 specifies a memory location comprised by a block of memory locations 30 associated with guard tag 32 [0093]; Figs. 2, 9 and 11);
logic to receive a client identifier of the client; logic to identify the first row in the permission store corresponding to the first tag; logic to identify the first field storing the first permission vector for the client (the tag mapping storage circuitry 64 is arranged to store a plurality of sets of mapping information corresponding to different threads and the thread ID 46 of the thread executing on the processing circuitry 4 is used to identify which set of mapping information to use; the thread ID 64 is 0x12A7 and so the set of mapping information associated with thread 0x12A7 is used to map the guard tag 32 to remapped tag 52 having a value of 0b1011; this remapped tag value 52 is compared with the address tag 40 in the tag check – see [0096], FIG. 11; examiner’s note: in FIG. 11, the tag mapping storage 64 is the same as the one shown in FIG. 9 with the addition of the thread IDs for each register 68; as shown in FIG. 9, each register includes the permission information – read, write, execute - corresponding to each tag value/thread ID);
logic to determine whether the client is authorized to access the first memory page, based at least in part on the first permission vector (guard tag 32 is remapped to produce a remapped tag 52 using the mapping information stored by the tag mapping storage circuitry 64 in order to match the associated guard tag value with permissions information (e.g., read, write, execute) – see [0093], Fig. 9 and 11); and
logic to provide the client with access to the memory page based at least in part on a determination that the client is authorized to access the memory page (the allowed types of access to blocks of memory locations associated with that guard tag 52 are read and write; remapped tag 52 and the address tag 40 are then compared in the tag check and allowed access types indicated by the permission information 54 and the requested access type 44 are compared in a permissions check; the address tag 40 and the remapped tag 52 match and the requested access type 44 is an allowed access type and so no error response action is performed; an error response action is carried out if tags do not match – see [0094], Fig. 9 and 11).
Bramley does not explicitly disclose what type of memory is being used; that is, Bramley discloses a tag store within the memory, but not a tag store within a secure RAM. The disclosure refers to it as “memory system” [0042], but it is not specific about it being a secure RAM and/or a DRAM.
However, in the same field of endeavor, Goss discloses a system and method for secure demand paging and paging operations wherein the memory includes a tag store within a secure RAM, and a separate DRAM (security logic 1038 makes secure ROM space inaccessible, makes secure RAM and register space inaccessible and establishes any other appropriate protections to additionally foster security – see [0083]; as illustrated in Fig. 4, secure RAM 1034 is associated with secure swapper 2160, which is coupled to a non-secure DRAM holding encrypted/authenticated pages; PA2VA 2120 (which is provided in secure RAM space) containing page table entries (PTEs) identifying pages is maintained secure on-chip (i.e., in the secure RAM, see [0195]); PTEs identify which pages are stored in the secure RAM and the pages in the DRAM are mapped to pages in the secure RAM; that is, both the secure RAM and the DRAM are storing pages - see [0155-0156], [0160], [0167], [0195] and Fig. 4; see also “Response to Amendment/Arguments” section above).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the device in Bramley to include a tag store within a secure RAM, and a separate DRAM, as taught by Goss. One would have been motivated to make such a combination to provide security with much greater extensibility and flexibility that increases performance and security using a limited resource, as recognized by Goss ([0194]).
Regarding claim 3, Bramley and Goss disclose all the claimed subject matter of claim 2 above. Furthermore, Bramley discloses the device wherein the client is an untrusted processor executing an operating system or application of the device (software to be executed by a data processing apparatus may typically be written in a high-level programing language and then compiled into code according to the instruction set architecture supported by the apparatus on which the software is to be executed; the enduring prevalence of use of memory-unsafe languages means that in compiled code according to a given instruction set architecture, there may be a large number of memory related errors which may be vulnerable to exploitation by an attacker or other malicious party – see [0002]; apparatus 2 may be configured to support both approaches with software able to indicate a selected approach by setting configuration information in a control register to set the length of the remapped address tags to use; updates to any control information used to control how tag mapping is performed may be restricted to software at a certain privilege level or higher (e.g. restricted to operating system or hypervisor software, so that application-level code is not allowed to set the control information) – see [0101]; see also [0003-0008]; note that requests may originate from different threads of processes – see [0046]; see also [0036-37], [0065-67] and [0096-97]).
Regarding claim 4, Bramley and Goss disclose all the claimed subject matter of claim 2 above. Bramley does not disclose the device wherein the client is an audio or video decoder.
However, Goss discloses the device wherein the client is an audio or video decoder (Audio/voice block 1170 supports audio and voice functions and interfacing; speech/voice codec(s) are suitably provided in memory space in audio/voice block 1170 for processing by processor(s) 1110 – see [0073]; audio block 1220 has an analog-to-digital converter (ADC) coupled to the voice codec and a stereo DAC (digital to analog converter) for a signal path to the baseband block 1210 including audio/voice block 1170 – see [0075]; note that FIG. 2 illustrates inventive integrated circuit chips including chips 1100, 1200, 1300, 1400, 1500 for use in the blocks of the communications system 1000 of FIG. 1 – see [0068] – and FIG. 1 illustrates an improved communications system 1000 with system blocks suitably implemented in fixed, portable, mobile, automotive, seaborne, and airborne, communications, control, set top box, and other apparatus – see [0059-0061] ) .
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the device in Bramley to include the device wherein the client is an audio or video decoder, as taught by Goss. One would have been motivated to make such a combination in order to provide advanced networking capability for services, software, content, and other services to accommodate and provide security for secure utilization and entertainment appropriate to these and other applications, as recognized by Goss ([0060]).
Regarding claim 5, Bramley and Goss disclose all the claimed subject matter of claim 2 above. Furthermore, Bramley discloses the device wherein the client is a firmware or hardware client (requests may originate from different threads of processes – see [0046]; a simultaneous-multi-threaded (SMT) processor may store mapping information for each thread alongside architectural state stored for the threads; the SMT may also provide mapping registers for the different threads supported in hardware; the tag check may then be performed based on the mapping information stored in a register selected using the thread ID of the instructing triggering the tag check – see [0071], [0072]).
Regarding claim 6, Bramley and Goss disclose all the claimed subject matter of claim 2 above. Furthermore, Bramley discloses the device wherein the client is an untrusted client (software to be executed by a data processing apparatus may typically be written in a high-level programing language and then compiled into code according to the instruction set architecture supported by the apparatus on which the software is to be executed; the enduring prevalence of use of memory-unsafe languages means that in compiled code according to a given instruction set architecture, there may be a large number of memory related errors which may be vulnerable to exploitation by an attacker or other malicious party; errors may include bounds violations, use-after-free errors, use-after-return, use-out-of-scope errors, use-before-initialisation errors, and other memory-related errors which can result in unpredictable behaviour and potentially provide avenues for attackers to exploit – see [0002-0008]; note that requests may originate from different threads of processes – see [0046]).
Regarding claim 7, Bramley and Goss disclose all the claimed subject matter of claim 2 above. Furthermore, Bramley discloses the device further comprising logic to assign the first tag to the first memory page (the tag mapping information specifies a plurality of remapped tag value fields made up of an address tag value that will match the associated guard tag value and permissions information; the address tag value and permissions information may be easily associated with the appropriate guard tag value and this information easily updated or altered for individual items of mapping information - see [0093], Fig. 9).
Regarding claim 11, Bramley and Goss disclose all the claimed subject matter of claim 2 above. Furthermore, Bramley discloses the device wherein: the plurality of fields comprises a second field storing a second permission vector for the client; the first permission vector corresponds to a first transaction type; the second permission vector corresponds to a second transaction type; and the logic to determine whether the client is authorized to access the first memory page further comprises: logic to determine that a requested transaction related to the access request is of the first transaction type (guard tag 32 is remapped to produce a remapped tag 52 using the mapping information stored by the tag mapping storage circuitry 64; tag mapping information specifies a plurality of remapped tag value fields made up of an address tag value that will match the associated guard tag value and permissions information - see [0093]; to generate the remapped tag 52, guard tag value, 0b0100, is looked up in the mapping information and it can be identified that the corresponding address tag value is 0b10101001 and the allowed types of access to blocks of memory locations associated with that guard tag 52 are read and write; the remapped tag 52 and the address tag 40 are then compared in the tag check and allowed access types indicated by the permission information 54 and the requested access type 44 are compared in a permissions check; if they match, no error response action is performed and if they don’t, an error response action could be carried out – see [0094]; FIGS. 8 and 9 show examples in which a field is used to store the permissions information for each item of mapping information – see [0095]; examiner’s note: see “tag mapping storage 64”, in Fig. 9, wherein each row corresponds to a guard tag, and each row includes a field storing permissions (e.g., read, write, execute) for each guard tag; as illustrated in Fig. 9, permissions [i.e., permission vectors] may be for one or a combination of transaction types - that is – read, read and execute, read and write, etc. for a particular guard tag; see also [0096-97] and Fig. 11 wherein each register, including tag and permissions, in the tag mapping storage 64 correspond to a thread ID).
Regarding claim 12, Bramley and Goss disclose all the claimed subject matter of claim 2 above. Furthermore, Bramley discloses the device further comprising: logic to receive a requested tag from the client, the requested tag corresponding to the access request; and logic to determine whether the requested tag matches the first tag; wherein the logic to determine whether the client is authorized to access the first memory page comprises logic to determine whether the client is authorized to access the first memory page based on whether the requested tag matches the first tag (it is possible to create more complicated relations between guard tag values and their corresponding address tag values, e.g., varying the mapping based on the thread from which the request originated – see [0046; guard tag 32 is remapped to produce a remapped tag 52 using the mapping information stored by the tag mapping storage circuitry 64; tag mapping information specifies a plurality of remapped tag value fields made up of an address tag value that will match the associated guard tag value and permissions information - see [0093]; to generate the remapped tag 52, guard tag value, 0b0100, is looked up in the mapping information and it can be identified that the corresponding address tag value is 0b10101001 and the allowed types of access to blocks of memory locations associated with that guard tag 52 are read and write; the remapped tag 52 and the address tag 40 are then compared in the tag check and allowed access types indicated by the permission information 54 and the requested access type 44 are compared in a permissions check; if they match, no error response action is performed and if they don’t, an error response action could be carried out – see [0094]; the tag mapping storage circuitry 64 is arranged to store a plurality of sets of mapping information corresponding to different threads and the thread ID 46 of the thread executing on the processing circuitry 4 is used to identify which set of mapping information to use; the thread ID 64 is 0x12A7 and so the set of mapping information associated with thread 0x12A7 is used to map the guard tag 32 to remapped tag 52 having a value of 0b1011 - see [0096-97], Fig. 11).
Regarding claim 15, Bramley and Goss disclose all the claimed subject matter of claim 2 above. Furthermore, Bramley discloses the device, wherein the device is a memory manager (FIG. 1 schematically illustrates an example of a data processing apparatus 2; a memory management unit (MMU) 20 is provided for providing address translation functionality to support memory accesses triggered by the load/store unit 15 – see [0079], Fig. 1)
Regarding claim 16, Bramley and Goss disclose all the claimed subject matter of claim 2 above.
Bramley does not disclose the device, wherein the device is a system on a chip (SoC).
However, Goss discloses the device, wherein the device is a system on a chip (SoC) (SoC (System on a Chip) Secure static RAM – see [0128]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the device in Bramley to include the device, wherein the device is a system on a chip (SoC), as taught by Goss. One would have been motivated to make such a combination because use of independent on-chip hardware advantageously isolates operations from software-based attacks, as recognized by Goss ([0092]).
Regarding claim 17, Bramley and Goss disclose all the claimed subject matter of claim 15 above. Bramley does not disclose the device, wherein the SoC comprises the secure RAM.
However, Goss discloses the device, wherein the SoC comprises the secure RAM (SoC (System on a Chip) Secure static RAM – see [0128]; see also [0091-0093]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the device in Bramley to include the device, wherein the SoC comprises the secure RAM, as taught by Goss. One would have been motivated to make such a combination because use of independent on-chip hardware advantageously isolates operations from software-based attacks, as recognized by Goss ([0092-93]).
Regarding claim 18, Bramley and Goss disclose all the claimed subject matter of claim 2 above. Bramley does not disclose the device, wherein the device is a set-top box.
However, Goss discloses the device, wherein the device is a set-top box (FIG. 1 illustrates an improved communications system 1000 with system blocks suitably implemented in fixed, portable, mobile, automotive, seaborne, and airborne, communications, control, set top box, and other apparatus – see [0059-0061]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the device in Bramley to include the device, wherein the device is a set-top box, as taught by Goss. One would have been motivated to make such a combination in order to provide advanced networking capability for services, software, content, and other services to accommodate and provide security for secure utilization and entertainment appropriate to these and other applications, as recognized by Goss ([0060]).
Regarding claim 20, all limitations correspond to the method performed by the device of claim 2 above. Therefore, claim 20 is being rejected on the same basis as claim 2.
Regarding claim 21, all limitations correspond to the method performed by the device of claim 7 above. Therefore, claim 21 is being rejected on the same basis as claim 7.
Regarding claim 22, all limitations correspond to the method performed by the device of claim 11 above. Therefore, claim 22 is being rejected on the same basis as claim 11.
Regarding claim 23, all limitations correspond to the method performed by the device of claim 12 above. Therefore, claim 23 is being rejected on the same basis as claim 12.
Claims 13, 14 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Bramley and Goss as applied to claim 2 above, and further in view of Durham et al. (US20200125502A1), hereinafter Durham.
Regarding claim 13, Bramley and Goss disclose all the claimed subject matter of claim 2 above. Furthermore, Bramley discloses use-after-free errors, in which an access to a memory location is made after that memory location has already been deallocated or freed in [0004]; and, use-after-return, in which a memory access to an address associated with a variable used within a function (such as a value on a stack) is made after already returning from the function in [0005].
Goss discloses “page wiping” which includes various alternatives to overwrite, erase, or simply change the state of a page-bit that tags or earmarks a page, and other methods to free or make available a page space or slot for a new page.
Bramley and Goss do not explicitly disclose the device further comprising: logic to determine that the client has stopped using the first page; logic to mark the first page with a second tag; and logic to return the first page to a system memory heap.
However, in the same field of endeavor, Durham discloses a device and method for low memory overhead heap management for memory tagging (see abstract), wherein the device further compris[es]: logic to determine that the client has stopped using the first page; logic to mark the first page with a second tag; and logic to return the first page to a system memory heap (the heap manager may generate a tag for a data block during memory allocation and change the tag to a different value when the memory is released or reallocated; the heap manager may prevent tag reuse, e.g., assignment of the same tag to a particular data block across subsequent allocations of that data block – see [0017]; a heap manager may maintain a history of previous tags as part of the heap management metadata and take the history into account during a memory heap operation (e.g., memory allocation and/or release operation); this allows reuse of a data block immediately after it is released provided that it is possible to assign a tag value that differs from the previous tag values as indicated by the tag history – see [0019], see also [0018]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the device in Bramley and Goss to include the device further comprising: logic to determine that the client has stopped using the first page; logic to mark the first page with a second tag; and logic to return the first page to a system memory heap, as taught by Durham. One would have been motivated to make such a combination to significantly reduce the need for quarantining heap blocks and thus reduce the memory overhead of heap management for memory tagging solutions, as recognized by Durham ([0017-0019]).
Regarding claim 14, Bramley, Goss and Durham disclose all the claimed subject matter of claim 13 above.
Furthermore, Bramley discloses the device wherein the second tag is a shared tag applied to a plurality of (it can be more efficient to associate each guard tag with a block of multiple memory locations, that is, several adjacent memory locations may share the same guard tag, which can be enough for detecting common forms of memory-related error – see [0041]).
Bramley and Goss do not explicitly disclose the shared tag being applied specifically to unused memory pages.
However, Durham discloses a shared tag applied to unused memory pages (tags may then simply be used to prevent use-after-free attacks; if the tag values stored in memory are also encrypted as the data as shown herein, the memory tags themselves become dependent on the object's size and location in memory, allowing the heap manager 104 to freely assign the same tag values for different object sizes, over time (multiple allocations and frees), occupying the same locations in memory – emphasis added, see [0067]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the device in Bramley and Goss to include a shared tag applied to unused memory pages, as taught by Durham. One would have been motivated to make such a combination to prevent use-after-free attacks, as recognized by Durham ([0067]).
Regarding claim 19, Bramley and Goss disclose all the claimed subject matter of claim 2 above.
Bramley and Goss do not explicitly disclose the device wherein the first memory page is fragmented.
However, Durham discloses a device and method for low memory overhead heap management for memory tagging (see abstract), wherein the first memory page is fragmented (the block that is identified or generated to fulfill the request may be assigned a tag that is not a part of the tag history of the block; the tag may be assigned in response to the memory allocation request (e.g., when a new block is created due to fragmentation or defragmentation, when a block is allocated for the first time, or when a block is reallocated) – see [0040-0041]; see also [0050], Fig. 4).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the device in Bramley and Goss to include the device, wherein the first memory page is fragmented, as taught by Durham. One would have been motivated to make such a combination to provide flexible data allocation if an incoming memory request may request a large data block when only small data blocks are available, as recognized by Durham ([0045]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Patent Documents
Dinechin et al. (US 20060036830 A1) - Method for Monitoring Access to Virtual Memory Pages
Hildesheim et al. (US 20180060250 A1) - Enhance Memory Access Permission Based on Per-Page Current Privilege Level
Kikuta et al. (US 6260131 B1) - Method and apparatus for TLB memory Ordering
Kjos et al. (US 20040064668 A1) - Memory Addressing for A Virtual Machine Implementation on A Computer Processor Supporting Virtual Hash-page-table Searching
Koufaty et al. (US 20160350019 A1) - Access Control for Memory Protection Key Architecture
Sahita et al. (US 20150378633 A1) - Method and Apparatus for Fine Grain Memory Protection
Shanbhogue (US 20160092371 A1) - Method and Apparatus for Deterministic Translation Lookaside Buffer (TLB) Miss Handling
Tsirkin (US 20170249458 A1) - Application Memory Protection Using a Host Page Table Switching Virtual Machine Function
Non-Patent Literature
Elwell et al. (2014, February): A non-inclusive memory permissions architecture for protection against cross-layer attacks. Elwell discloses a hardware-supported page permission scheme for the physical pages that is based on the concept of non-inclusive sets of memory permissions for different layers of system software such as hypervisors, operating systems, and user-level applications.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DORIANNE ALVARADO DAVID whose telephone number is (571)272-4228. The examiner can normally be reached 9:00am-5:00pm ET.
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, Philip Chea can be reached at (571) 272-3951. 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.
/DORIANNE ALVARADO DAVID/Examiner, Art Unit 2499 /PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499
Prosecution Insights