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 .
CLAIM INTERPRETATION
Claims in this application are not interpreted under 35 U.S.C. §112(f).
Claim Rejections – 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
As an initial matter, under the Alice Framework Step 1 analysis, claims 1-20 fall within the four statutory categories of patentable subject matter: a process, machine, manufacture, and composition of matter as claims 1-11 claim a process, claims 12-19 claim a machine, and claim 20 claims an article of manufacture.
Regarding claim 1:
Under the Alice Framework Step 2A prong 1, the claim recites the abstract idea of “selecting a translation regime based on the ID; determining a physical address (PA) and a PA space (PAS) based on the selected translation regime and the VA”, because the broadest reasonable interpretation of the limitation includes a person selecting a translation regime, such as bypass, from a table, and then determining the VA as the PA and the PAS as the ID, which is a step that may be performed mentally (“mental processes include observations, evaluations, judgments, and opinions” [MPEP 2106.04(a)(2)(III) ¶2]). Accordingly, claim 1 recites a mental process type abstract idea.
Under the Alice Framework Step 2A prong 2, the claim is evaluated for additional elements that integrate the judicial exception into a practical application.
The claim recites the additional element of the method being “for processing a transaction, by a memory management unit (MMU)”. However, this limitation only amounts to limiting the field of use or technological environment by restricting the application of the abstract idea to memory management units, which are used to translate virtual to physical addresses and enforce memory protections as described by the specification in [0008]. Accordingly, the limitation fails to integrate the judicial exception into a practical application [MPEP 2106.05(h)].
The claim also recites the additional element of “obtaining a transaction indicating a virtual address (VA) and an identifier (ID) of an initiator of the transaction”. However, this limitation recites insignificant extra-solution activity as it amounts to necessary data gathering and data output for performing the judicial exception as it is analogous to other limitations found to be mere data gathering by the courts, such as: testing a system for a response, the response being used to determine system malfunction, In re Meyers, 688 F.2d 789, 794; 215 USPQ 193, 196-97 (CCPA 1982); obtaining information about transactions using the Internet to verify credit card transactions, CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375, 99 USPQ2d 1690, 1694 (Fed. Cir. 2011); and consulting and updating an activity log, Ultramercial, 772 F.3d at 715, 112 USPQ2d at 1754 and therefore only amounts to mere data gathering and does not integrate the judicial exception into a practical application [MPEP 2106.05(g)].
Finally, the claim also recites, “processing the transaction based on the PA and the PAS”. However, this limitation only recites the idea of a solution or outcome and therefore attempts to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result. For example, there is nothing recited in the claim which indicates what specific steps are taken to process the transaction other than to use the determined PA and PAS determined according to the abstract idea, as the processing is “based on” these determined parameters. Accordingly, it is equivalent to the words “apply it” and does not integrate the abstract idea into a practical application or provide significantly more. Electric Power Group, LLC v. Alstom, S.A., 830 F.3d 1350, 1356, 119 USPQ2d 1739, 1743-44 (Fed. Cir. 2016); Intellectual Ventures I v. Symantec, 838 F.3d 1307, 1327, 120 USPQ2d 1353, 1366 (Fed. Cir. 2016); Internet Patents Corp. v. Active Network, Inc., 790 F.3d 1343, 1348, 115 USPQ2d 1414, 1417 (Fed. Cir. 2015) [MPEP 2106.05(f)].
Under the Alice Framework Step 2B, for at least the reasons cited with respect to the Step 2A prong 2 analysis, the claim considered as a whole does not amount to significantly more than the abstract idea. As a whole, the claim merely recites the abstract idea with the additional requirement to “apply it” by reciting the idea of a solution or outcome by stating to process the transaction using the results of the abstract idea (the determined PA and PAS). Reciting the idea of a solution or outcome is mere instructions to apply the abstract idea and cannot provide an inventive concept. [See MPEP 2106.05(f)]. Furthermore, the additional step of obtaining the transaction is insignificant extra solution activity recited at a high level of generality and amounts to activity recognized by the courts as well understood, routine, and conventional. For example, the limitation is analogous to receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1984 (2014) (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log); or storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93. Accordingly, including the well understood, routine, and conventional activity recited at a high level of generality with the abstract idea does not provide an inventive concept or significantly more than the abstract idea by itself [MPEP 2106.05(d)]. Additionally, the additional limitation of the method for processing the transaction being “by a memory management unit (MMU)” does not provide an inventive concept or significantly more because it merely restricts the technological environment to MMUs, which are used to translate virtual addresses to physical addresses and enforce memory protections as disclosed in the specification [0008]. Limitations that amount to merely indicating a field of use or technological environment in which to apply a judicial exception do not amount to significantly more than the abstract idea itself [MPEP 2106.05(h)]. Therefore, the claim elements considered individually, in combination, and as a whole, do not provide significantly more than the abstract idea. For these reasons, claim 1 is not patent eligible.
Regarding claim 12 and analogous claim 20
Claims 12 and 20 are rejected according to a similar analysis to that performed for claim 1 without consideration for the field of use/technological environment restriction of the MMU and with the additional consideration that the memory comprising instructions and processor configured to execute the instructions and cause the apparatus to perform the method recited in claim 12 and the non-transitory computer-readable medium comprising instructions, that when executed by the processor, cause the processor to perform the method recited in claim 20 are both treated at step 2A prong 2 as mere instructions to apply the abstract idea with a computer by reciting computer elements at a high level of generality, and considered as a whole with the rest of the limitations at step 2B, still does not does not amount to significantly more than the abstract idea [See MPEP § 2106.05(f)].
Regarding claims 2-11 and analogous claim 13-19:
Claims 2-11 and 13-19 only further recite modifications to the mental process type abstract idea that do not prevent the limitations from being performed mentally. Accordingly, the claims are rejected according to a similar analysis to that performed to claims 1 and 12.
Additionally, 7 and 18 recite a small modification to the data gathering step in that the transaction additionally includes a stream ID (SID), which still recites mere data gathering or selecting a particular source or type of data to be manipulated, which are still analogous to the previously recited insignificant extra-solution activity identified by the courts as well as or court identified activity related to selecting a particular source or type of data to be manipulated such as limiting a database index to XML tags, Intellectual Ventures I LLC v. Erie Indem. Co., 850 F.3d at 1328-29, 121 USPQ2d at 1937; or selecting information, based on types of information and availability of information in a power-grid environment, for collection, analysis and display, Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 1354-55, 119 USPQ2d 1739, 1742 (Fed. Cir. 2016) under step 2A, and are analogous to the same well understood, routine, and conventional activity identified previously, and accordingly, still does not does not amount to significantly more than the abstract idea under step 2B and therefore do not render the claims patent eligible.
Insofar as any of claims 2-11 and 13-19 recite other modifications to the data gathering step by specifying a particular source or type of data to be manipulated (for example, by specifying what the ID for the security state indicates, or what translation regimes may be selected from, such as in a table), they are treated analogously to the limitations from claims 7 and 18 that also specify a particular source or type of data to be manipulated and accordingly do not render the claims patent eligible.
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent Application Publication No. US 2018/0136967 A1 (Asbe) in view of the “ARM System Memory Management Unit Architecture Specification: SMMU architecture version 3”, document number ARM IHI 0070, version F.b from 22 February 2024 (ArmSMMU) in further view of the “ARM Security Technology: Building a Secure System using TrustZone Technology”, document number PRD29-GENC-009492C, from April 2009 (ArmTrustZone).
Regarding claim 1 and analogous claims 12 and 20:
Asbe, a method for processing a transaction, by a memory management unit (MMU), comprising: obtaining a transaction indicating a virtual address (VA) and a security state of an initiator of the transaction (by disclosing that an input transaction (322) may be received by an SMMU (MMU) and may identify a security status of the transaction, such as a secure domain or a non-secure domain to which the transaction belongs [0042] [Fig. 3]. The secure domain may be a trusted execution environment, or a “TrustZone” [0025] [0031] [0052]. The SMMU may be implemented according to the Arm architecture [0069]. The SMMU may also include a TLB (320) [Fig. 3] [0041] [0044]. The system executes according to the application processor (202) or processing circuit (920) executing instructions (942-956) stored in a memory (940) [0031-0039] [0086-0098]); selecting a translation regime based on the security state (by disclosing that a translation context that should be used for processing the transaction is selected based on the identified security domain, as the identified security domain influences the selection of the context, which influences the selection of the translation scheme [0042] [Fig. 3]); determining a physical address (PA) and a security domain based on the selected translation regime and the VA (by disclosing that translation by the translation block (318) translates the virtual address of the input transaction into a physical address corresponding to the selected security domain (secure or non-secure) [0039] [0046]); and processing the transaction based on the PA and the security domain (by disclosing that the translation will then occur, which will either involve a page table walk, bypass, or fault translation context (306) (314) (308) (316) (310) (312) [Fig. 3]. To properly translate the addresses to the corresponding physical addresses, a particular translation context is based on the security state and stream ID of the transaction, which will load different contexts into the different stages of address translation. The different contexts support isolating the different transaction initiators from each other (i.e., mapping the virtual addresses to different physical address spaces [0042-0044] [0002-0003] [0040]).
Asbe does not explicitly disclose, but ArmSMMU teaches that the transaction indicates a an identifier (ID) for a security state of an initiator of the transaction (by teaching that incoming transactions have a Stream ID and a SEC_SID identifier, which identifies a security state of the initiator (SEC_ID 0 = non-secure) (SEC_ID 1 = secure), which corresponds to a physical address space of the initiator [¶3.2 – pg. 38] [§3.10 – pgs. 77-78]. A transaction that belongs to a stream that is under secure control may generate a transaction to the memory system that targets the secure (NS==0) and Non-secure (NS==1) physical address spaces, while a transaction that belongs to a Stream that is under Non-secure (NS==1) control can only generate transactions to the memory system that target the Non-secure (NS==1) physical address space [pg. 78]) and determining a physical address (PA) based on the selected translation regime and the VA and processing the transaction based on the PA and the PA space (PAS) (by teaching that the incoming transactions have a virtual address, which is translated according to a stage 1 and stage 2 translation or translation bypass according to a STE (stream table entry) and CD (context descriptor) as determined by the security state of the initiator (NS==1 or NS==0) and virtual address to obtain a physical address of the transaction in the physical address space of the transaction (according to the security state and stream ID) which is provided as the output address [§3.3.2 StreamIDs to Context Descriptors] [pgs. 41-45] [Figs. 3.3 - 3.6]).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the security state identified for the transaction as taught by Asbe to be included in the identifier SEC_SID within the transaction as taught by ArmSMMU.
One of ordinary skill in the art would have been motivated to make this modification because it would have only required the combination of known elements according to known methods to yield predictable results. Particularly, Asbe teaches that the security state is identified from the transaction and then used to select the appropriate stream entry tables and context descriptors for the translation of the transaction, but does not specifically identify how. Furthermore, Asbe teaches that the SMMU is implemented according to the Arm SMMU. Then, ArmSMMU specification teaches that the security state may be identified by the SEC_SID field within the transaction (which also identifies a PAS), which may be used to select the appropriate stream entry tables and context descriptors for the translation of the transaction. Accordingly, one of ordinary skill in the art could have combined the SEC_SID implemented in the transaction as taught by ArmSMMU to identify the security state of the transaction (and therefore PAS of the output transaction) as taught by Asbe according to known methods and the results would have been predictable.
Asbe in view of ArmSMMU does not explicitly disclose, but ArmTrustZone teaches and determining a physical PAS based on the selected translation regime and the VA (by teaching that the page table walk (i.e., such as the stage 1 and stage 2 translation using the selected stream entry tables and context descriptors as taught by Asbe) should yield the NS-bit associated with the VA and NSTID it was passed. The NS-bit indicates NS=1 (Non-secure) and NS=0 (secure) and the NSTID (Non-secure table identifier) similarly indicates NSTID=1 (Non-secure/Normal world) and NSTID=0 (Secure/Secure world). The NS-bit and NSTID are useful to add as tags to the TLB entries and cache entries so that the secure and non-secure entries can co-exist in the TLB without having to flush the cache when switching between secure and non-secure execution contexts and allows for faster context switching [§3.2.2 – pgs. 37-38])
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the address translation based on the address translation scheme based on the security state of the initiator of the transaction as taught by Asbe in view of ArmSMMU to include determining the NS-bit (indicative of the PAS) for the PA of the translation and adding it as a tag in the TLB and any caches along with the NSTID (analogous to the SEC_SID taught by ArmSMMU) as taught by ArmTrustZone.
One of ordinary skill in the art would have been motivated to make this modification because adding the NS-bit (i.e. determining the PAS based on the virtual address and the selected translation regime) as taught by ArmTrustZone would allow for faster context switching by allowing both secure and non-secure entries in the TLB and in any caches without having to perform flushes at context switches as taught by ArmTrustZone in [§3.2.2 – pgs. 37-38].
Regarding claim 2 and analogous claim 13:
The method of claim 1 is made obvious by Asbe in view of ArmSMMU in further view of ArmTrustZone (Asbe-ArmSMMU-ArmTrustZone).
Asbe further discloses wherein: a first translation regime is selected if the security state (ID for the security state as taught by ArmSMMU) indicates a system on a chip (SoC) security state (by teaching that the security state may indicate a secure processing environment (such as TrustZone) of an application processor (202) of a system-on-a-chip (SoC) device [0029-0031], and the translation selected (306) (314) (308) (316) (310) (312) is based on the security state of the transaction, which may be a secure or non-secure security state [0059-0031] [Fig. 3] [0038] [0042] [Fig. 5] [0050-0060]) or a second translation regime is selected if the ID for the security state indicates a central processing unit (CPU) security state (the security state of the application processor (202), which may only have one security state at a time, may also be a non-secure security state and may execute a rich OS (i.e., function as a CPU) and the translation selected (306) (314) (308) (316) (310) (312) is based on the security state of the transaction, which may be a secure or non-secure security state [0029-0031] [Fig. 3] [0038] [0042] [Fig. 5] [0050-0060]).
Regarding claim 3 and analogous claim 14:
The method of claim 2 is made obvious Asbe-ArmSMMU-ArmTrustZone.
Asbe further discloses wherein: the selected translation regime comprises a bypass translation regime that determines the PA from the VA independent of page tables (by teaching the bypass (310) translation scheme to translate the input virtual address (322) to the output physical address (342) (i.e., without the first or second stage page tables (314) (316) [Fig. 3] [0044])
Regarding claim 4 and analogous claim 15:
The method of claim 3 is made obvious Asbe-ArmSMMU-ArmTrustZone.
Asbe does not explicitly disclose, but ArmSMMU teaches wherein determining the PA comprises: setting a value of the PA to a value of the VA (by teaching that there may be bypass with the secure or non-secure transactions, and that translation may be selectively enabled for each interface (secure or non-secure), such that for one interface, there is no translation (setting a value of the PA to a value of the VA) [pg. 78] [pg. 79] [§3.11 Reset, Enable and initialization – pgs. 84-85] [§6.3.61 SMMU_S_GBPA, pg. 435] [§3.10.2.1, pg. 79] [§3.10.2 Support for Secure State, pg. 78] [Fig. 3.6, pg. 44]).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the security state identified for the transaction being used to select a translation method as taught by Asbe to include using the security state as indicated by SEC_SID to determine whether or not the SMMU is to be bypassed as taught by ArmSMMU.
One of ordinary skill in the art would have been motivated to make this modification because it would have only required the combination of known elements according to known methods to yield predictable results. Particularly, Asbe teaches that the security state is identified from the transaction and then used to select the appropriate translation scheme, which may be bypass, but does not specifically identify receiving a security state identifier and using that to determine whether the translation is bypassed. Furthermore, Asbe teaches that the SMMU is implemented according to the Arm SMMU. Then, ArmSMMU specification teaches that the security state may be identified by the SEC_SID field within the transaction, which may be used to select the bypass translation method according to the state of the SMMU_S_GBPA register. Accordingly, one of ordinary skill in the art could have combined the SEC_SID of ArmSMMU to identify the security state of the transaction (and therefore PAS of the output transaction) as taught by Asbe, and could have used the register SMMU_S_GBPA to determine whether the security state indicates that translation is bypassed as taught by ArmSMMU in order to determine to perform translation bypass as taught by Asbe according to known methods and the results would have been predictable.
ArmSMMU does not explicitly disclose, but ArmTrustZone teaches, wherein determining the PAS comprises: setting a value of the PAS to a value of the ID (by teaching that the page table walk (i.e., such as the stage 1 and stage 2 translation using the selected stream entry tables and context descriptors as taught by Asbe) should yield the NS-bit associated with the VA and NSTID it was passed (i.e., setting a value of the PAS to a value of the ID). The NS-bit indicates NS=1 (Non-secure) and NS=0 (secure) and the NSTID (Non-secure table identifier) similarly indicates NSTID=1 (Non-secure/Normal world) and NSTID=0 (Secure/Secure world). The NS-bit and NSTID are useful to add as tags to the TLB entries and cache entries so that the secure and non-secure entries can co-exist in the TLB without having to flush the cache when switching between secure and non-secure execution contexts and allows for faster context switching [§3.2.2 – pgs. 37-38])
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the address translation based on the address translation scheme based on the security state of the initiator of the transaction as taught by Asbe in view of ArmSMMU to include determining the NS-bit (indicative of the PAS) for the PA of the translation and adding it as a tag in the TLB and any caches along with the NSTID (analogous to the SEC_SID taught by ArmSMMU) as taught by ArmTrustZone.
One of ordinary skill in the art would have been motivated to make this modification because adding the NS-bit (i.e. determining the PAS based on the virtual address and the selected translation regime) as taught by ArmTrustZone would allow for faster context switching by allowing both secure and non-secure entries in the TLB and in any caches without having to perform flushes at context switches as taught by ArmTrustZone in [[§3.2.2 – pgs. 37-38.
Regarding claim 5 and analogous claim 16:
The method of claim 3 is made obvious by Asbe-ArmSMMU-ArmTrustZone.
Asbe does not explicitly disclose, but ARM-SMMU teaches, wherein: the selected translation regime comprises a non-secure (NS) translation regime or a self-translation regime (by teaching that the page table walk (i.e., such as the stage 1 and stage 2 translation using the selected stream entry tables and context descriptors as taught by Asbe) should yield the NS-bit associated with the VA and NSTID it was passed. The NS-bit indicates NS=1 (Non-secure) (non-secure (NS) translation regime) and NS=0 (secure) and the NSTID (Non-secure table identifier) similarly indicates NSTID=1 (Non-secure/Normal world) and NSTID=0 (Secure/Secure world). The NS-bit and NSTID are useful to add as tags to the TLB entries and cache entries so that the secure and non-secure entries can co-exist in the TLB without having to flush the cache when switching between secure and non-secure execution contexts and allows for faster context switching [§3.2.2 – pgs. 37-38])
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the address translation based on the address translation scheme based on the security state of the initiator of the transaction as taught by Asbe in view of ArmSMMU to include determining the NS-bit (indicative of the PAS) (for a secure or non-secure translation regime) for the PA of the translation and adding it as a tag in the TLB and any caches along with the NSTID (analogous to the SEC_SID taught by ArmSMMU) as taught by ArmTrustZone.
One of ordinary skill in the art would have been motivated to make this modification because adding the NS-bit for the secure and non-secure translation contexts as taught by ArmTrustZone would allow for faster context switching by allowing both secure and non-secure entries in the TLB and in any caches without having to perform flushes at context switches as taught by ArmTrustZone in [[§3.2.2 – pgs. 37-38.
Regarding claim 6 and analogous claim 17:
The method of claim 5 is made obvious by Asbe-ArmSMMU-ArmTrustZone.
Asbe further discloses, wherein determining the PA and the PAS comprises: translating the VA to the PA using one or more page tables (by disclosing that the translation will may occur through a page table walk (306) (314) (308) (316) [Fig. 3]. To properly translate the virtual addresses to the corresponding physical addresses, a particular translation context is based on the security state and stream ID of the transaction, which will load different stream tables and different contexts into the different stages of address translation for the page table walks [0042-0044] [0002-0003] [0040]).
Regarding claim 7 and analogous claim 18:
The method of claim 6 is made obvious by Asbe-ArmSMMU-ArmTrustZone.
Asbe further discloses, wherein: the transaction further indicates a stream ID (SID), and determining the PA and the PAS comprises selecting the one or more page tables based on the SID (by teaching that the transaction may include a stream ID, which may be used to select a specific context bank (i.e., page table) based on identifying a stream mapping to the context bank to be used for the initial translation context (i.e., selecting the one or more page tables based on the SID) [0038-0039] [0044-0046]).
Regarding claim 8 and analogous claim 19:
The method of claim 1 is made obvious by Asbe-ArmSMMU-ArmTrustZone,
Asbe further discloses, wherein selecting the translation regime comprises selecting a bypass translation regime, or a self-translation regime from a table (by teaching the bypass (310) translation scheme or the page table translation schemes (self-translation), which translate the address from a table (i.e., from the page table) [Fig. 3])
Regarding claim 9:
The method of claim 8 is made obvious by Asbe-ArmSMMU-ArmTrustZone.
Asbe further discloses, wherein the table is configurable to allow the MMU to select between translation for central processing unit (CPU) worlds and system-on-a-chip (SoC) worlds (by teaching that the security state may indicate a secure processing environment (such as TrustZone) of an application processor (202) of a system-on-a-chip (SoC) device [0029-0031], and the page tables selected (306) (314) (308) (316) for translating the addresses are based on the security state of the transaction, which may be a secure (SoC world) or non-secure (CPU world) security state [0059-0031] [Fig. 3] [0038] [0042] [Fig. 5] [0050-0060]
Regarding claim 10:
The method of claim 9 is made obvious by Asbe-ArmSMMU-ArmTrustZone.
Asbe does not explicitly disclose, but ARM-SMMU teaches, wherein selecting the translation regime comprises selecting the bypass translation regime when the ID indicates an SoC world (by teaching that when a stream is identified as being under secure control according to SEC_SID, its configuration may invoke a bypass translation according to the global bypass attributes determined by SMMU_S_GBPA [§6.3.61 SMMU_S_GBPA, pg. 435] [§3.10.2.1, pg. 79] [§3.10.2 Support for Secure State, pg. 78] [Fig. 3.6, pg. 44]).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the security state identified for the transaction being used to select a translation method as taught by Asbe to include using the security state as indicated by SEC_SID to determine whether or not the SMMU is to be bypassed as taught by ArmSMMU.
One of ordinary skill in the art would have been motivated to make this modification because it would have only required the combination of known elements according to known methods to yield predictable results. Particularly, Asbe teaches that the security state is identified from the transaction and then used to select the appropriate translation scheme, which may be bypass, but does not specifically identify receiving a security state identifier and using that to determine whether the translation is bypassed. Furthermore, Asbe teaches that the SMMU is implemented according to the Arm SMMU. Then, ArmSMMU specification teaches that the security state may be identified by the SEC_SID field within the transaction, which may be used to select the bypass translation method according to the state of the SMMU_S_GBPA register. Accordingly, one of ordinary skill in the art could have combined the SEC_SID of ArmSMMU to identify the security state of the transaction (and therefore PAS of the output transaction) as taught by Asbe, and could have used the register SMMU_S_GBPA to determine whether the security state indicates that translation is bypassed as taught by ArmSMMU in order to determine to perform translation bypass as taught by Asbe according to known methods and the results would have been predictable.
Regarding claim 11:
The method of claim 1 is made obvious by Asbe-ArmSMMU-ArmTrustZone.
Asbe further discloses, wherein the ID for the security state (i.e., the ID as taught by ArmSMMU in the rejection for claim 1) indicates a system on a chip (SoC) security state (by teaching that the security state may indicate a secure processing environment (such as TrustZone) of an application processor (202) of a system-on-a-chip (SoC) device (i.e., SoC security state) [0029-0031] [0059-0031] [Fig. 3] [0038] [0042] [Fig. 5] [0050-0060]).
Response to Arguments/Amendments
Applicant argues in the Remarks dated 20 August 2026 (Rem) that “such operations cannot practically be performed in the human mind” because a “person cannot mentally intercept a bus transaction, select a translation regime from hardware configuration translate a virtual address to physical address, and process the transaction to access memory” [Rem, pg. 6, ¶7]. The Examiner respectfully disagrees. The features that Applicant relies upon to allegedly make a process impossible to perform in the mind are absent from the claim. For example, nowhere do the claims require “intercepting a hardware bus transaction”, using hardware to select a translation regime, or processing a transaction to access memory. Instead, the claims recite, “selecting a translation regime based on the ID” and “determining a physical address (PA) and a PA space (PAS) based on the selected translation regime and the VA” for which the broadest reasonable interpretation includes a person mentally selecting a bypass translation mode (for example, a person can mentally determine that virtual addresses should be translated to physical addresses with an identity translation (selecting a bypass translation regime), where a given VA (0x100) is used as the PA (0x100) and the PAS (0x1) is also kept the same (input PAS (0x1) = output PAS (0x1)) [see 0098-0099]. The process of selecting a mode of translation (i.e., selecting between translation tables or bypassing translation) may be performed mentally, as can the actual performance of the translations themselves (a person can mentally perform an identity/bypass translation on a virtual address and can mentally perform keeping an input PAS the same as the output PAS). Accordingly, the broadest reasonable interpretation of the limitation includes the recitation of a mental process type abstract idea.
Applicant further argues that the additional elements integrate any such abstract idea into a practical application [Rem, pg. 7, ¶1]. The Examiner respectfully disagrees. Applicant points to the location in the specification where a problem in the prior art and a solution of the disclosed invention are discussed. However, "the claim must be evaluated to ensure that the claim itself reflects the disclosed improvement. That is, the claim includes the components or steps of the invention that provide the improvement described in the specification." [MPEP 2106.04(d)(1)]. In the present case, the claims do not reflect the components of the technology that reflect the disclosed improvement. For example, the claims do not set up or define what the different CPU/SoC worlds are or how they are used to issue transactions, they do not disclose how the address spaces are partitioned or containerized to require the use of the different translation modes, they do not disclose how the worlds are otherwise designed to protect processing of sensitive data, provide a separate security state, or partition the system into isolated execution environments that required the disclosed partitioned translation scheme or selection of different translation regimes [0024-0029] as discussed by Applicant in [Rem, pg. 7, ¶1]. Accordingly, the claims do not reflect the disclosed improvement as they do not reflect the components of the technology that reflect the disclosed improvement. Furthermore, “[i]t is important to note, the judicial exception alone cannot provide the improvement” [MPEP 2106.05(a) ¶6]. In this case, Applicant appears to argue that selection of a translation regime based on an identifier supplies improvement to the technology. However, an improved mental process (better selection of translation modes based on an ID and an address) cannot provide the improvement to technology as it is merely an improvement to the abstract mental process of selection of a translation scheme. For these reasons, for the claimed invention to be an improvement to the technology, it would have to reflect these components that require and enable Applicant’s disclosed solution, and not merely restrict the application of the abstract idea to the technological environment of an MMU. Therefore, Applicant’s arguments are not persuasive.
Applicant argues that “processing the transaction based on the PA and the PAS” is not merely an instruction to “apply it”. However, in so arguing, Applicant argues that it requires accessing the target memory location and the physical address space of the memory. However, “processing” a transaction is a much broader concept than accessing a memory at a definite location. For example, “processing” a transaction may only involve saving it, recording it, sending it, performing another identity translation, encoding it, decoding it, or performing any other number of undisclosed and unclaimed operations and therefore does not require “accessing memory” at the specified location within the specified PAS as Applicant argues. Therefore, Applicant’s argument is not persuasive.
Applicant argues that the feature of obtaining the VA and the ID is not mere data gathering because it is an integral part of the claimed operation. However, use of the gathered data in the claimed process is explicitly contemplated in identifying insignificant extra-solution activity. For example, “Extra-solution activity includes both pre-solution and post-solution activity. An example of pre-solution activity is a step of gathering data for use in a claimed process, e.g., a step of obtaining information about credit card transactions, which is recited as part of a claimed process of analyzing and manipulating the gathered information by a series of steps in order to detect whether the transactions were fraudulent” [MPEP 2106.05(g) ¶1]. Therefore, the fact that the claimed invention uses the gathered information is not dispositive in showing that it is not extra-solution activity. In the present case, analogously to the gathered transaction data found to be extra (pre) salutation activity, the gathered VA and ID are used in the performance of the abstract idea. Furthermore, Applicant argues that the examiner did not cite sufficient Berkheimer evidence because network transmission and recordkeeping decisions do not address obtaining, at an MMU, a bus transaction. However, the Examiner notes that Applicant again argues features which are outside the claimed invention. The claims do not recite intercepting “a bus transaction”. Instead, the merely recite “obtaining” data in a computer/MMU environment, without a disclosed mechanism (such that the broadest reasonable interpretation would include reading it from memory). Therefore, the Examiner finds that a transaction sent over a bus (although not claimed) or obtaining data is analogous to other well-understood routine and conventional activity recognized by the courts such as data sent and received over a network, or retrieving information in memory, as noted in the prior 35 USC §101 rejection, as they both involve the sending and reception of data signals over signal buses (i.e. a network) or obtaining data from a memory. Therefore, the insignificant extra-solution activity is also well-understood, routine, and conventional activity as identified by the courts and Applicant’s argument is not persuasive.
For the foregoing reasons, as Applicant’s arguments were not persuasive, the 35 USC §101 rejection is maintained.
Applicant argues that the combination of Asbe, ArmSMMU and ArmTrustZone does not teach selecting a translation regime [Rem, pg. 9, ¶2]. The Examiner respectfully disagrees.
As interpreted in light of the specification, the broadest reasonable interpretation of a “translation regime” appears to be a set of rules or policies for translating a logical to a physical address, a system or method of translating a logical to a physical address, a particular manner in which to translate a logical to a physical address, or a “mode” of translating a logical to a physical address [see at least 0089-0093, which when discussing a “translation regime”, refers to it in the alternative as a “translation mode” and references regimes such as “self-translation” and “bypass” translations, in which no translation occurs. Accordingly, for the purposes of Examining the claims, the Examiner interpreted a translation regime in accordance with the broadest reasonable interpretation laid out above.
Applicant argues that Asbe does not teach selecting a translation regime based on the ID because the “security status determines a set of candidate translation contexts, and the stream ID is used to resolve which specific context to apply” [Rem, pg. 10, ¶2]. However, the Examiner finds, in alignment with the broadest reasonable interpretation outlined above, that “determin[ing] a set of candidate translation contexts” fits within the broadest reasonable interpretation of “selecting a translation regime” because determining a set of candidate translation contexts is selecting a “mode”, or a “set of rules policies” or selecting “a system or method” for translating a logical to a physical address and accordingly fits within the broadest reasonable interpretation of the limitation. Furthermore, the Examiner rejected “selecting a translation regime based on the ID” with the combination of Asbe and ArmSMMU. Therefore, Applicant’s arguments against the references individually when the rejection was based upon what the combination of references would teach to one of ordinary skill in the art is not persuasive. Accordingly, the prior art rejection is maintained.
Applicant further argues that there is “no disclosure that the identified security status or any identifier of the initiator selects between the bypass block, the fault block, and the page table contexts” [Rem, pg. 10, ¶3]. The Examiner respectfully disagrees. The specification explicitly calls out that the context disambiguation block (304) may provide a signal (328) that indicates a context to be applied for the translation of the input signal (322) [0043]. As seen in [Fig. 3], this signal is received by bypass block (310) and fault block (312). Furthermore, this signal (328) is based upon the signal (326) that is provided to context disambiguation block (304) from security status determination block (302) that includes the security status [0042]. The signal from context disambiguation block (304) that selects the translation context is therefore based upon the signaled security status [see Fig. 3]. Therefore, [Fig. 3] alone refutes the characterization performed by Applicant as [Fig. 3] shows a process flow with signal (326) indicating the security state sent from security status determination block (302) to context disambiguation (304), which then selects a context with context signal (328) that provides inputs to stage 1 context (306), stage 2 context (308), bypass (310) and fault (312), such that the translation block (318) can output a transaction (342) based on one of the translations “based on” the security state (i.e., based on signal (326) indicating the security state) (i.e., selecting a translation regime based on the security state). Therefore, the cited references teach the limitations for which they were relied upon in the rejection above and Applicant’s arguments to the contrary are not persuasive.
Applicant also argues that ArmSMMU does not teach “selecting a translation regime” and that the SEC_SID is not used in ArmSMMU to select a translation regime [Rem, pg. 9, last ¶]. However, the Examiner rejected “selecting a translation regime based on the ID” with the combination of Asbe and ArmSMMU. Therefore, Applicant’s arguments against the references individually when the rejection was based upon what the combination of references would teach to one of ordinary skill in the art is not persuasive. Instead, the Examiner relied upon Asbe as teaching selecting the translation regime (“determine[ing] a set of candidate translation contexts”, as characterized by Applicant) based on the security state, and then relied upon ArmSMMU for teaching that the security state may be communicated with an ID, such as the SEC_SID. Therefore, the combination made obvious “selecting the translation regime based on the ID” and the combination teaches the limitations of the claim for which they were relied upon as performed in the rejection above and Applicant’s arguments to the contrary are not persuasive.
Applicant further argues that ArmSMMU uses “translation regime” as a distinct term of art [Rem, pg. 10, ¶1]. However, the fact that ArmSMMU uses the term as a distinct term of art does not prevent it from teaching the Stream ID Security state (SEC_SID) as a form of “ID” that fits within the broadest reasonable interpretation of ID as claimed in applicant’s claims. Furthermore, ArmSMMU was not relied upon to teach the “translation regime” as claimed (and instead Asbe was). Therefore, ArmSMMU in combination with Asbe render obvious the broadest reasonable interpretation of the limitations as claimed. If Applicant would instead prefer for “translation regime” in the claims to be interpreted as a term of art and interpreted in accordance with the ArmSMMU specification as a specific Stream World Exception Level translation scheme, applicant is free to amend the claims to require such an interpretation. However, as the specification indicates that the broadest reasonable interpretation may include a “translation mode” [0089] and other broader definitions of the term, such a narrow interpretation is not read into the claims.
Applicant further argues that ArmSMMU does not teach “selecting a translation regime based on the ID” in the global bypass configuration invoked for claims 4 and 10 [Rem, pg. 10, ¶2]. However, the Examiner did not rely upon ArmSMMU alone to teach “selecting a translation regime based on the ID” in the rejection of claims 4 and 10 and instead relied upon a combination of references to teach the limitation as claimed. Accordingly, Applicant’s arguments against the references individually are not persuasive.
Applicant argues that the deficiencies Applicant alleged above are not cured by ArmTrustZone [Rem, pg. 11, ¶1]. However, the arguments were not persuasive in establishing any deficiencies and accordingly, any alleged deficiency in ArmTrustZone in curing those alleged deficiencies is moot.
Applicant requests that the claims be indicated as allowable [Rem, pg. 11, ¶2]. However, Applicant’s arguments with respect to the 35 USC §101 and 35 USC §103 rejection are not persuasive. Therefore, the rejections are maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US Patent Application Publication No. US 2016/0283384 A1 (Podaima) – teaches to look up the context for a transaction of an SoC device, which includes an MMU, which may include bypassing address translations so the page tables are not consulted [0002] [0055].
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CURTIS JAMES KORTMAN whose telephone number is (303)297-4404. The examiner can normally be reached Monday through Friday 7:30 AM through 4:00 PM MT.
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, Reginald Bragdon can be reached at (571) 272-4204. 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.
/CURTIS JAMES KORTMAN/Primary Examiner, Art Unit 2139
Prosecution Insights