DETAILED ACTION
Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax (not Examiner's Fax), Regular postal mail, or EFS Web using PTO/SB/439.
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 .
Priority
Should applicant desire to obtain the benefit of foreign priority under 35 U.S.C. 119(a)-(d) prior to declaration of an interference, a certified English translation of the foreign application must be submitted in reply to this action. 37 CFR 41.154(b) and 41.202(e).
Failure to provide a certified translation may result in no benefit being accorded for the non-English application.
Information Disclosure Statement
The information disclosure statement filed 09/18/2024 fails to comply with 37 CFR 1.98(a)(3)(i) because it does not include a concise explanation of the relevance, as it is presently understood by the individual designated in 37 CFR 1.56(c) most knowledgeable about the content of the information, of each reference listed that is not in the English language. It has been placed in the application file, but the information referred to therein has not been considered.
Claim Objections
Claims 1 – 10 are objected to because of the following informalities:
Regarding claims 1, 9 and 10; there appear to be a typographical error “generated at at least one node” in (line 15, claim 1), (line 16, claim 9) and (line 18, claim 10).
Claims 2 – 8 are dependent claims and thus also objected.
Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: an authentication memory encryption engine configured to perform a cryptographic process and an authentication process…in claim 1.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1 – 3 and 7 – 10 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Ramrakhyani et al., (US 2019/0251275 A1) (hereinafter “Ramrakhyani”).
Ramrakhyani discloses
Regarding claim 1, an information processing device [i.e., a data processing system (see ref. 2 of figure 1), (page 7, para 0067)] comprising:
a memory [i.e., memory (see figure 2)];
an authentication tree cache in which some of counters, identifiers, and tags generated by using the counters and the identifiers, are temporarily stored [i.e., a 32 KB Dedicated Counter Cache that caches encryption and integrity-tree counters (page 15, para 0132)], the counters and the identifiers being included in the authentication tree including a plurality of nodes connected with one another in a tree shape in which a pair of a counter and an identifier is assigned to each of the nodes [i.e., the memory security circuitry may maintain a counter integrity tree which comprises a number of nodes. Each node specifies multiple counter which are associated with respective data blocks of the protected memory region (page 2, para 0034)];
a data cache [i.e., multiple levels of cache (e.g., cache level L1 and L2) (see figure 1) (page 7, para 0067)] in which some of a plurality of data respectively assigned to a plurality of leaf nodes [i.e., at least one leaf node corresponding to memory data block (page 2, para 0034)] are temporarily stored [i.e., a processor system including multiple levels of caches used to temporarily stores data accessed by the processor (page 7, para 0067), (see figure 1) Note; the data blocks corresponds to integrity-tree leaf nodes], the plurality of leaf nodes being nodes located in a lowest layer [i.e., lower levels (closer to the leaves) (page 9, para 0085)] of the authentication tree among the plurality of nodes constituting the authentication tree [i.e., an integrity tree having multiple levels including lower levels closer to the leaves (page 9, para 0085), (see figure 5)]; and
an authenticated memory encryption engine [i.e., memory security unit (see ref. 20 of figure 1), (page 7, para 0070)] configured to perform a cryptographic process [i.e., the memory security unit includes encrypt/decrypt circuitry (see ref. 32 of figure 1), (page 7, para 0069)] and an authentication process using the authentication tree for data to be exchanged between the data cache and the memory [i.e., the memory unit includes integrity tree verification circuitry to verify memory blocks (see ref. 36 of figure 1), (page 7, para 0070)], and perform an authentication process for at least one tag [i.e., MAC verification (page 7, para 0070)] respectively generated at at least one node present on a path from a leaf node to which the data is assigned to a root node [i.e., when data is accessed, the system verifies MAC values associated with the target block and ancestor nodes in the counter integrity tree (page 10, para 0090), (see figure 8)], wherein a counter assigned to each node in the authentication tree is formed of a major counter [i.e., split (major-minor) counter (page 3, para 0040)] of which a value is represented by, among a plurality of bits representing a value of the counter, a high-order bit, and a minor counter [i.e., split (major-minor) counter (page 3, para 0040)] of which a value is represented by a low-order bit [i.e., the minor counter can be specified with fewer bits (page 3, para 0040)], the major counter is shared by a plurality of nodes having a common parent node [i.e., split counters including a major count value shared among multiple nodes and minor counters associated with individual nodes, where the minor counters may user fewer bits than the major counter (page 3, para 0040) Note; this reads on the claimed counter in which high-order bits represent the major counter and low-order bits represent the minor counter], and the authenticated memory encryption engine is configured, for the major counter and the minor counter assigned to each node, to be able to wait for a process for updating a value of the major counter which occurs as a result of a process for updating a value of the minor counter [i.e., at step 274 the integrity tree generation circuitry 36 increments the minor counter which has been selected corresponding to the target block…at step 276 it is determined whether the minor counter has overflown due to this increment…if at step 276, an overflow of the minor counter occurs, then at step 280, the shared major counter is in the parent node of the target block is incremented (page 11, para 0095 – 0096), (see refs. 274 – 280 of figure 9) Note; since the major counter is only updated after the minor counter update causes overflow, it is necessarily completes the minor counter update and then wait to perform the major counter update].
Regarding claim 2, the information processing device according to claim 1, wherein when the authenticated memory encryption engine has updated a value of the major counter shared by the plurality of nodes having the common parent node, the authenticated memory encryption engine initializes a value of a minor counter of each of the plurality of nodes having the common parent node [i.e., each block uses a different one the minor counters but the same incremented major counter. If the node having the overflowed minor counter is a leaf node of the integrity tree, then the data associated with each of the other blocks whose MACs were recalculated is re-encrypted with a new counter before recalculating the MACs (page 11, pare 0096)].
Regarding claim 3, the information processing device according to claim 1, wherein the authenticated memory encryption engine is further configured to be able to update a value of the major counter shared by the plurality of nodes having the common parent node without updating a value of a minor counter of each of the plurality of nodes having the common parent node [i.e., at step 280, the shared major counter is in the parent node of the target block is incremented (page 11, para 0095 – 0096), (see refs. 274 – 280 of figure 9)].
Regarding claim 7, the information processing device according to claim 1, wherein the authenticated memory encryption engine is further configured to: update, when deleting any of the plurality of the nodes constituting the authentication tree, a value of the major counter assigned to a parent node of the node to be deleted based on a value of the major counter assigned to the parent node of the node to be deleted [i.e., at step 274 the integrity tree generation circuitry 36 increments the minor counter which has been selected corresponding to the target block…at step 276 it is determined whether the minor counter has overflown due to this increment…if at step 276, an overflow of the minor counter occurs, then at step 280, the shared major counter is in the parent node of the target block is incremented (page 11, para 0095 – 0096), (see refs. 274 – 280 of figure 9)]; and set, when adding a new node at a position where the deleted node was originally located in the authentication tree, a value of the major counter assigned to the added node based on the major counter assigned to a parent node of the added node [i.e., the memory security circuitry may maintain a counter integrity tree which comprises a number of nodes. Each node specifies multiple counter which are associated with respective data blocks of the protected memory region (page 2, para 0034)].
Regarding claim 8, the information processing device according to claim 7, wherein the authenticated memory encryption engine is further configured to: update, when deleting any of the plurality of the nodes constituting the authentication tree [i.e., an integrity tree having multiple levels including lower levels closer to the leaves (page 9, para 0085), (see figure 5)], a value of a major counter assigned to the parent node of the node to be deleted to a value larger than a larger one of the value of the major counter assigned to the parent node of the node to be deleted and a value of a major counter assigned to the node to be deleted [i.e., at step 274 the integrity tree generation circuitry 36 increments the minor counter which has been selected corresponding to the target block…at step 276 it is determined whether the minor counter has overflown due to this increment…if at step 276, an overflow of the minor counter occurs, then at step 280, the shared major counter is in the parent node of the target block is incremented (page 11, para 0095 – 0096), (see refs. 274 – 280 of figure 9)]; and set, when adding a new node at the position where the deleted node was originally located in the authentication tree, a value of the major counter assigned to the added node to a value equal to or larger than the value of the major counter assigned to the parent node of the added node [i.e., the memory security circuitry may maintain a counter integrity tree which comprises a number of nodes. Each node specifies multiple counter which are associated with respective data blocks of the protected memory region (page 2, para 0034)].
Regarding claim 9, a method for controlling an information processing device [i.e., a flow diagram showing a method of controlling write access to an off-chip memory by a memory security unit (page 10, para 0092), (see figure 9)],
the information processing device [i.e., a data processing system (see ref. 2 of figure 1), (page 7, para 0067)] comprising:
a memory [i.e., memory (see figure 2)];
an authentication tree cache in which some of counters, identifiers, and tags generated by using the counters and the identifiers, are temporarily stored [i.e., a 32 KB Dedicated Counter Cache that caches encryption and integrity-tree counters (page 15, para 0132)], the counters and the identifiers being included in the authentication tree including a plurality of nodes connected with one another in a tree shape in which a pair of a counter and an identifier is assigned to each of the nodes [i.e., the memory security circuitry may maintain a counter integrity tree which comprises a number of nodes. Each node specifies multiple counter which are associated with respective data blocks of the protected memory region (page 2, para 0034)];
a data cache [i.e., multiple levels of cache (e.g., cache level L1 and L2) (see figure 1) (page 7, para 0067)] in which some of a plurality of data respectively assigned to a plurality of leaf nodes [i.e., at least one leaf node corresponding to memory data block (page 2, para 0034)] are temporarily stored [i.e., a processor system including multiple levels of caches used to temporarily stores data accessed by the processor (page 7, para 0067), (see figure 1) Note; the data blocks corresponds to integrity-tree leaf nodes], the plurality of leaf nodes being nodes located in a lowest layer [i.e., lower levels (closer to the leaves) (page 9, para 0085)] of the authentication tree among the plurality of nodes constituting the authentication tree [i.e., an integrity tree having multiple levels including lower levels closer to the leaves (page 9, para 0085), (see figure 5)]; and
an authenticated memory encryption engine [i.e., memory security unit (see ref. 20 of figure 1), (page 7, para 0070)] configured to perform a cryptographic process [i.e., the memory security unit includes encrypt/decrypt circuitry (see ref. 32 of figure 1), (page 7, para 0069)] and an authentication process using the authentication tree for data to be exchanged between the data cache and the memory [i.e., the memory unit includes integrity tree verification circuitry to verify memory blocks (see ref. 36 of figure 1), (page 7, para 0070)], and perform an authentication process for at least one tag [i.e., MAC verification (page 7, para 0070)] respectively generated at at least one node present on a path from a leaf node to which the data is assigned to a root node [i.e., when data is accessed, the system verifies MAC values associated with the target block and ancestor nodes in the counter integrity tree (page 10, para 0090), (see figure 8)], wherein a counter assigned to each node in the authentication tree is formed of a major counter [i.e., split (major-minor) counter (page 3, para 0040)] of which a value is represented by, among a plurality of bits representing a value of the counter, a high-order bit, and a minor counter [i.e., split (major-minor) counter (page 3, para 0040)] of which a value is represented by a low-order bit [i.e., the minor counter can be specified with fewer bits (page 3, para 0040)], the major counter is shared by a plurality of nodes having a common parent node [i.e., split counters including a major count value shared among multiple nodes and minor counters associated with individual nodes, where the minor counters may user fewer bits than the major counter (page 3, para 0040) Note; this reads on the claimed counter in which high-order bits represent the major counter and low-order bits represent the minor counter], the method comprising:
delaying, for the major counter and the minor counter assigned to each node, a process for updating a value of the major counter which occurs as a result of a process for updating a value of the minor counter [i.e., at step 274 the integrity tree generation circuitry 36 increments the minor counter which has been selected corresponding to the target block…at step 276 it is determined whether the minor counter has overflown due to this increment…if at step 276, an overflow of the minor counter occurs, then at step 280, the shared major counter is in the parent node of the target block is incremented (page 11, para 0095 – 0096), (see refs. 274 – 280 of figure 9) Note; since the major counter is only updated after the minor counter update causes overflow, it is necessarily completes the minor counter update and then wait to perform the major counter update],
performing a process for updating a value of another minor counter assigned to another node of which a parent node is the same as that of the node to which the minor counter is assigned [i.e., each block uses a different one the minor counters but the same incremented major counter. If the node having the overflowed minor counter is a leaf node of the integrity tree, then the data associated with each of the other blocks whose MACs were recalculated is re-encrypted with a new counter before recalculating the MACs (page 11, pare 0096) Note; a minor counter of a first block overflows. The shared major counter (parent node) is incremented. Other blocks that share that same major counter must have their authentication values recomputed i.e., the incremented major counter, and the minor counter specific to each other block], and
performing a process for updating the value of the major counter [i.e., at step 280, the shared major counter is in the parent node of the target block is incremented (page 11, para 0095 – 0096), (see refs. 274 – 280 of figure 9)].
Regarding claim 10, a non-transitory computer readable medium storing a control program [i.e., memory (see figure 2)] for causing a computer to perform a process for controlling an information processing device [i.e., a flow diagram showing a method of controlling write access to an off-chip memory by a memory security unit (page 10, para 0092), (see figure 9)], the information processing device comprising [i.e., a data processing system (see ref. 2 of figure 1), (page 7, para 0067)] comprising:
a memory [i.e., memory (see figure 2)];
an authentication tree cache in which some of counters, identifiers, and tags generated by using the counters and the identifiers, are temporarily stored [i.e., a 32 KB Dedicated Counter Cache that caches encryption and integrity-tree counters (page 15, para 0132)], the counters and the identifiers being included in the authentication tree including a plurality of nodes connected with one another in a tree shape in which a pair of a counter and an identifier is assigned to each of the nodes [i.e., the memory security circuitry may maintain a counter integrity tree which comprises a number of nodes. Each node specifies multiple counter which are associated with respective data blocks of the protected memory region (page 2, para 0034)];
a data cache [i.e., multiple levels of cache (e.g., cache level L1 and L2) (see figure 1) (page 7, para 0067)] in which some of a plurality of data respectively assigned to a plurality of leaf nodes [i.e., at least one leaf node corresponding to memory data block (page 2, para 0034)] are temporarily stored [i.e., a processor system including multiple levels of caches used to temporarily stores data accessed by the processor (page 7, para 0067), (see figure 1) Note; the data blocks corresponds to integrity-tree leaf nodes], the plurality of leaf nodes being nodes located in a lowest layer [i.e., lower levels (closer to the leaves) (page 9, para 0085)] of the authentication tree among the plurality of nodes constituting the authentication tree [i.e., an integrity tree having multiple levels including lower levels closer to the leaves (page 9, para 0085), (see figure 5)]; and
an authenticated memory encryption engine [i.e., memory security unit (see ref. 20 of figure 1), (page 7, para 0070)] configured to perform a cryptographic process [i.e., the memory security unit includes encrypt/decrypt circuitry (see ref. 32 of figure 1), (page 7, para 0069)] and an authentication process using the authentication tree for data to be exchanged between the data cache and the memory [i.e., the memory unit includes integrity tree verification circuitry to verify memory blocks (see ref. 36 of figure 1), (page 7, para 0070)], and perform an authentication process for at least one tag [i.e., MAC verification (page 7, para 0070)] respectively generated at at least one node present on a path from a leaf node to which the data is assigned to a root node [i.e., when data is accessed, the system verifies MAC values associated with the target block and ancestor nodes in the counter integrity tree (page 10, para 0090), (see figure 8)], wherein a counter assigned to each node in the authentication tree is formed of a major counter [i.e., split (major-minor) counter (page 3, para 0040)] of which a value is represented by, among a plurality of bits representing a value of the counter, a high-order bit, and a minor counter [i.e., split (major-minor) counter (page 3, para 0040)] of which a value is represented by a low-order bit [i.e., the minor counter can be specified with fewer bits (page 3, para 0040)], the major counter is shared by a plurality of nodes having a common parent node [i.e., split counters including a major count value shared among multiple nodes and minor counters associated with individual nodes, where the minor counters may user fewer bits than the major counter (page 3, para 0040) Note; this reads on the claimed counter in which high-order bits represent the major counter and low-order bits represent the minor counter], the program being configured to further cause the computer to perform:
a process for delaying, for the major counter and the minor counter assigned to each node, a process for updating a value of the major counter which occurs as a result of a process for updating a value of the minor counter [i.e., at step 274 the integrity tree generation circuitry 36 increments the minor counter which has been selected corresponding to the target block…at step 276 it is determined whether the minor counter has overflown due to this increment…if at step 276, an overflow of the minor counter occurs, then at step 280, the shared major counter is in the parent node of the target block is incremented (page 11, para 0095 – 0096), (see refs. 274 – 280 of figure 9) Note; since the major counter is only updated after the minor counter update causes overflow, it is necessarily completes the minor counter update and then wait to perform the major counter update],
a process for performing a process for updating a value of another minor counter assigned to another node of which a parent node is the same as that of the node to which the minor counter is assigned [i.e., each block uses a different one the minor counters but the same incremented major counter. If the node having the overflowed minor counter is a leaf node of the integrity tree, then the data associated with each of the other blocks whose MACs were recalculated is re-encrypted with a new counter before recalculating the MACs (page 11, pare 0096) Note; a minor counter of a first block overflows. The shared major counter (parent node) is incremented. Other blocks that share that same major counter must have their authentication values recomputed i.e., the incremented major counter, and the minor counter specific to each other block], and
a process for performing a process for updating the value of the major counter [i.e., at step 280, the shared major counter is in the parent node of the target block is incremented (page 11, para 0095 – 0096), (see refs. 274 – 280 of figure 9)].
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 4 - 6 are rejected under 35 U.S.C. 103 as being unpatentable over Ramrakhyani in view of Frey et al., (US 2012/0110336 A1) (hereinafter “Frey”) in view of Joshi (5,414,839) (hereinafter “Joshi”).
Regarding claim 4, Ramrakhyani discloses; the information processing device according to claim 1 [i.e., (see claim 1 above)].
Ramrakhyani does not disclose;
wherein the authenticated memory encryption engine is further configured to: lock, when updating a first node among the plurality of the nodes constituting the authentication tree by first access, all nodes present on a path from the first node to a node at which a cache line is stored in the authentication tree cache and which is closest to the first node among nodes present on a path from the first node to the root node, and then update the locked nodes; and lock, when updating a second node among the plurality of the nodes constituting the authentication tree by second access following the first access, and when a third node, which is a node already locked due to the first access, is present on a path from the second node to the root node, all nodes present on a path from the second node to a node immediately before the third node, and after all the nodes locked due to the first access are unlocked, lock remaining nodes present on a path from the third node to a node at which a cache line is stored in the authentication tree cache and which is closest to the first node among nodes present on the path from the third node to the root node, and then update the locked nodes.
However, Frey discloses;
lock, when updating a first node among the plurality of the nodes constituting the authentication tree by first access, all nodes present on a path from the first node to a node at which a cache line is stored in the authentication tree cache and which is closest to the first node among nodes present on a path from the first node to the root node, and then update the locked nodes [i.e., a verification tree used to organize blocks of data, where nodes are arranged in a hierarchical tree structure and accessed through ancestor-descendant relationship (page 3, para 0057 – 0060), (see figure 2) i.e., storing blocks of the verification tree in a trusted cache memory, where a node or digest already stored in cache can serve as the starting ancestor for traversal (page 1, para 0018 – 0020) i.e., modifying blocks and updating corresponding digest values in parent nodes along the tree structure when data blocks are changed (page 1, page 0021 – 0027)].
Before the effective filing date of the claimed invention it would have been obvious to a person of ordinary skill in the art to modify the teachings of Ramrakhyani by adapting the teachings of Frey to protect electronic systems (See Frey; page 1, para 0001).
Ramrakhyani and Frey do not disclose;
Lock, when updating a second node among the plurality of the nodes constituting the authentication tree by second access following the first access, and when a third node, which is a node already locked due to the first access, is present on a path from the second node to the root node, all nodes present on a path from the second node to a node immediately before the third node, and after all the nodes locked due to the first access are unlocked, lock remaining nodes present on a path from the third node to a node at which a cache line is stored in the authentication tree cache and which is closest to the first node among nodes present on the path from the third node to the root node, and then update the locked nodes.
However, Joshi discloses;
lock, when updating a second node among the plurality of the nodes constituting the authentication tree by second access following the first access, and when a third node, which is a node already locked due to the first access, is present on a path from the second node to the root node, all nodes present on a path from the second node to a node immediately before the third node, and after all the nodes locked due to the first access are unlocked, lock remaining nodes present on a path from the third node to a node at which a cache line is stored in the authentication tree cache and which is closest to the first node among nodes present on the path from the third node to the root node, and then update the locked nodes [i.e., a hierarchical locking protocol for nodes in a multi-level resource hierarchy, where locks may be placed on nodes along the hierarchy and escalated to ancestor nodes. (col. 3 – 4) i.e., when a second transaction requests access to a node whose ancestor is already strongly locked by another transaction, the protocol searches the hierarchy, queues lock request, and performs lock de-escalation and escalation to resolve conflicts (col. 4), (see figures 5A and 5B)].
Before the effecting filing date of the claimed invention it would have been obvious to a person of ordinary skill in the art to modify the teachings of Ramrakhyani and Frey by adapting the teaching of Joshi to improve performance in high memory requirements in low contention situations (See Joshi; col. 3).
Regarding claim 5, Ramrakhyani discloses; the information processing device according to claim 4, wherein the authenticated memory encryption engine is further configured to perform a process for updating a value of the major counter, which occurs as a result of a process for updating a value of the minor counter in a child node of the third node due to the first access, after the node locked due to the second access is updated [i.e., at step 274 the integrity tree generation circuitry 36 increments the minor counter which has been selected corresponding to the target block…at step 276 it is determined whether the minor counter has overflown due to this increment…if at step 276, an overflow of the minor counter occurs, then at step 280, the shared major counter is in the parent node of the target block is incremented (page 11, para 0095 – 0096), (see refs. 274 – 280 of figure 9)].
Regarding claim 6, Ramrakhyani discloses; the information processing device according to claim 4 [i.e., (see claim 4 above)].
Ramrakhyani and Frey do not disclose;
wherein the authenticated memory encryption engine is further configured so as not to accept any additional process for a child node of the third node locked due to the second access before the process for updating the value of the major counter of the child node.
However, Joshi discloses;
wherein the authenticated memory encryption engine is further configured so as not to accept any additional process for a child node of the third node locked due to the second access before the process for updating the value of the major counter of the child node [i.e., a hierarchical locking protocol for nodes in a multi-level resource hierarchy, where locks may be placed on nodes along the hierarchy and escalated to ancestor nodes. (col. 3 – 4) i.e., when a second transaction requests access to a node whose ancestor is already strongly locked by another transaction, the protocol searches the hierarchy, queues lock request, and performs lock de-escalation and escalation to resolve conflicts (col. 4), (see figures 5A and 5B)].
Before the effecting filing date of the claimed invention it would have been obvious to a person of ordinary skill in the art to modify the teachings of Ramrakhyani and Frey by adapting the teaching of Joshi to improve performance in high memory requirements in low contention situations (See Joshi; col. 3).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
AWAD (US 2019/0394021 A1) discloses storing each encrypted data block, of a cyphertext page in a cyphertext file, with corresponding encrypted error correction code (ECC) bits in a persistent memory device (PMD), the encrypted ECC bits verify both an encryption counter value of an encryption operation and a plaintext block of the cyphertext page from a decryption operation; decrypting, using the decryption operation during a read operation of a memory controller on a secure processor, a respective one block of the cyphertext file and the corresponding encrypted ECC bits stored in the PMD using a current counter value to form the plaintext block and decrypted ECC bits; verifying the plaintext block with the decrypted ECC bits; and performing a security check of the encryption counter value in response to the plaintext block failing the verification, using the decrypted ECC bits.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SYED A RONI whose telephone number is (571)270-7806. The examiner can normally be reached M-F 9:00-5:00 pm (EST).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey L Nickerson can be reached at (469) 295-9235. 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.
/SYED A RONI/Primary Examiner, Art Unit 2432
Prosecution Insights