DETAILED ACTION
Claims 1, 19, 24, 25 are amended. Claim 6 previously canceled. Claim 26 is new. Claims 1-5, 7-26 are pending.
Priority: June 16, 2023
Assignee: Akeana
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 .
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 5/30/2026 has been entered.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim(s) 12, 15, 19, 26 is/are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
1.Claim 26 is rejected for reciting a limitation that is unclear, inconsistent and indefinite.
Claim 26 recites, ‘wherein enabling the DCT includes accessing the DSF by using an index value to reference an entry in an M-way associative table having an index value, a valid indicator, ….the direct cache transfer’.
The spec does not recite this limitation. Fig. 7, Para-0053 of the spec recites, ‘Column 701 includes an index value. The index value provides a mechanism for identifying a given row within the DSF’.
As shown, the spec discloses index value 701 to identify an entry in the table. The claim has an antecedent basis issue because it recites ‘an index value’ and ‘having an index value’. If ‘index value’ in the claim refers to the exact same index value used to identify rows in the table, it is redundant.
Furthermore, based on the definition of the table in the spec, the claim takes this specific table and adds an additional requirement, ‘using an index value to reference an entry….’.
Because the claim does not require the index value to identify a given row within the DSF as taught in the spec, the claim covers any index value used to reference an entry regardless of whether it achieves the primary function described in the spec. Accordingly the claim is indefinite because its boundaries are unclear as it fails to capture the essential mechanism (the DSF row identification) that the spec recites. Hence claim 26 is rejected.
2.Claims 12,15 are rejected for reciting limitations that are unclear, vague and indefinite.
Claim 12 recites, ‘wherein an index of the address associated with the coherent cache line misses in the DSF’. The limitation has been copied from the spec. But the spec does not provide any additional information.
Fig. 2, Para-0032 of the spec recites, ‘the DSF is an M-way associative set of tables that includes an index number, a valid bit,…..and an owner valid field’.
The phrases ‘index of the address’ and ‘index number’ are used without definition. The claim requires that an ‘index of the address’ is used to determine if a cache line misses in the DSF. However, the spec only vaguely lists an ‘index number’ as a parameter of the DSF, without explaining how an ‘index of the address’ is derived, calculated, or how it relates to the ‘index number’.
It is unclear whether the ‘index of the address’ refers to a tag-array index, a lookup key into the M-way associative tables of the DSF, or a separate calculated hash, rendering the claim scope open to multiple conflicting interpretations.
It is unclear whether ‘index of the address’ is synonymous with ‘index number’ or if it is an entirely different metric (e.g., a specific subset of bits from the address). Because the spec does not teach how the address is transformed into or associated with the recited index, the claim fails to provide a clear boundary of the invention. Hence the claim is indefinite and rejected. Claim 15 has the same issue.
3.Amended Claim 19 is rejected for reciting a limitation that is unclear, by the spec.
Claim 19 recites, ‘saving, in the DSF, details about the coherent cache line, wherein the saving includes updating the DSF…., and wherein the details include a presence vector, an owner ID, ….and a valid field value’.
Claim 1 recites, ‘the DSF comprises a cache with a plurality of ways’ and Fig. 2, Para-0036 of the spec which recites updating the DSF in step 290, recites that the DSF as ‘an M-way associative set of tables’.
The DSF is described as a ‘cache with a plurality of ways’ and an ‘M-way associative set of tables’, offering conflicting, open-ended, and insufficient descriptions. There is no disclosure of the mapping between the two data structures, suggesting lack of possession.
Broad references to a ‘cache with a plurality of ways’ and an ‘M-way associative set of tables’ without disclosing how data is accessed, or searched in the tables for read or write, makes the phrase ‘updating the DSF’ just a functional phrase defined by what it does (updating) rather than by specific structural limitations and how it is done.
Without an explanation of how the DSF is accessed and searched (e.g., how the M-way tables are indexed, searched, or structured), it is unclear what constitutes ‘updating the DSF’. For example, how are addresses mapped? How is data selected or overwritten during an update? Are all ‘M’ ways updated, or is there a specific eviction policy?
Because the spec fails to define how the DSF is structured, accessed, or searched, the exact boundaries of what ‘updating’ entails are rendered indefinite. Hence claim 19 is rejected.
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim(s) 1-5, 7-26 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
1.Amended Claim 1 is rejected for reciting a limitation that is unsupported by the spec.
Claim 1 recites, ‘in response to the first coherent request node indicating that data ….will be overwritten by a subsequent write operation, the first coherent home node provides the first coherent request node with an empty cache line’.
The spec does not recite this limitation. Para-0034 of the spec recites, ‘a requesting node can request an empty cache line prior to starting a write operation, enabling saving of system bandwidth by avoiding the need to transfer data that will be overwritten with the subsequent write operation’.
In the spec, the requesting node is the initiator, requesting the empty line before the write operation to save bandwidth. But in the claim, the requesting node simply provides a passive indication, and the home node evaluates this passive ‘indication’ and provides the empty line.
The spec does not disclose the mechanics of how the home node determines it should provide an empty line upon a mere indication from the requesting node.
The spec explicitly states the node actively asks for the empty cache line ‘prior to starting a write’. But the claim allows for the ‘indication’ to happen during or as part of a future/subsequent write, thereby broadening scope to real-time allocation of the empty line that the spec does not envision or teach. Hence the limitation recites new matter.
In summary, because the spec fails to describe the home node independently providing an empty cache line or the exact mechanism for such an ‘indication’, the claim covers a (broader) scope beyond the scope of the spec. Hence claim 1 is rejected for reciting a limitation unsupported by the spec.
2.Claim 26 is rejected for reciting a limitation that is unsupported by the spec.
Claim 26 recites, ‘….enabling the DCT includes accessing the DSF by using an index value to reference an entry in an M-way associative table having an …..for each row and wherein the DSF is configured to provide coherence information used to establish the direct cache transfer’.
Nowhere does the spec recite this limitation.
The spec does not recite and/or define ‘coherence information’. There is no written description support for ‘….the DSF is configured to provide coherence information used to establish the….transfer’.
That said, Para-0053 of the spec which refers to Fig. 7, recites, ‘The DSF can include an M-way associative table…..Each way includes a plurality of columns’.
Based on Fig. 7 of the spec and claim 1 recitation, ‘DSF is a cache with a plurality of ways’, an M-way associative table can be considered like an M-way set associative cache.
It is well-known in the art that an M-way set associative cache is searched by dividing a memory address into three components: Tag, Index, and Offset. The cache divides its data into ‘sets’, and each set contains ‘M’ ways of data. And searching involves sequential steps such as extracting the index, retrieving the set and parallel tag comparison. But Para-0053 of the spec casually mentions an incomplete search mechanism as it recites, ‘….to search within the DSF,….utilize an index value to reference a desired entry in the DSF’. The spec does not teach how ‘an index value’ is determined or utilizing the index value to reference a DSF entry. A casual, one-line, vague recitation does not fulfill the written description requirement.
The spec does not explicitly teach that ‘an M-way associative table’ maps to an M-way set associative cache. More importantly, the spec does not teach how the claim 1 phrase ‘a cache with a plurality of ways’ maps to ‘an M-way associative table’.
In addition, the spec provides three inconsistent definitions for the DSF term (table vs. set of tables vs. two-dimensional matrix). Though Para-0053 of the spec describes the M-way associative table with ways, columns, and index, the spec lacks disclosure regarding how the table is navigated, addressed, written to, or read from.
Claims 9, 10-12, 14-15, 17, 19 recite limitations that involve searching the DSF to determine a hit or miss, eviction and updating parameters of the table. But the spec provides no specific guidance, working examples, or algorithms for carrying out the search and retrieval of parameters from the DSF. A PHOSITA would have to engage in undue experimentation, essentially inventing their own search/retrieval methods, to determine how to access and search the DSF to read and write to it.
The lack of a clear, consistent structure to represent the DSF and the missing table access mechanisms renders the invention essentially a ‘black box’ where the claim limitations recite only the result to be achieved rather than how to achieve the result. This lack of disclosure demonstrates that the inventor's possession of the claimed subject matter, especially the DSF and accessing and searching the DSF, at the time of filing was incomplete. Hence claim 26 recites a scope unsupported by the spec and is rejected.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-5, 7-18, 20-25 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Jalal et al (20190079868) in view of Arm (‘AMBA 5 CHI Architecture Specification’, 2014, Pgs. 1-20 to 16-463) and Tune (20140281180).
As per Claim 1, Jalal discloses a processor-implemented method for cache management (Jalal, [0015 – In Fig. 1, a System-on-Chip/SoC contains multiple processing devices, multiple data caches and shared data resources]; [0020 - A cache coherence protocol employs a MOESI cache coherence model]) comprising:
accessing a system on a chip (SOC) (Jalal, [0015 – In Fig. 1, system 100 is implemented in a System-on-Chip/SoC]) wherein the SOC communicates internally on a coherent bus (Jalal, [Fig. 1: interconnect circuit 106/coherent bus]; [0015 – In Fig. 1, blocks 102 generate data access requests and are called request nodes/RNs]),
wherein the SOC includes a plurality of coherent request nodes (Jalal, [Fig. 1: request nodes/RN’s or RN-F’s]) and a first coherent home node (Jalal, [Fig. 1: a home node 108, HN-F]),
and the first coherent home node includes a directory-based snoop filter (DSF) (Jalal, [Fig. 1: a snoop filter 400/DSF]; [Fig. 5: snoop filter directory]),
wherein the DSF comprises a cache with a plurality of ways (Jalal, [0019 – In Fig. 1, snoop filter 400 monitors data transactions and maintains the status of data stored in system cache 116]);
requesting, by a first coherent request node within the plurality of coherent request nodes (Jalal, [Fig. 1]), ownership of a coherent cache line within the SOC (Jalal, [0082 - The home node receives from a first request node, for data stored at a system address in the shared data resource]; [0030 – As per Table 1, at line 2, another request node, RNF1, performs a cacheable read to the same memory location/address A]; [0050 – As per Table 2, request node, RNF1, performs a cacheable read to the same memory location/address A]),
wherein the requesting includes an address associated with the coherent cache line (Jalal, [0030 - location/address A]; [0050 - location/address A]);
detecting, by the first coherent home node, that the coherent cache line is shared with one or more other coherent request nodes (Jalal, [0030 – In Table 1, the read causes the HNF snoop filter to send a snoop to RNF0 for address A, since the snoop filter indicates that the data is in the cache of RNF0. The state in the snoop filter is updated to ‘SD’ and the identifier of the data/SD RNFID is updated to RNF0]; [0050 – In Table 2, the read causes the HNF snoop filter to send a snoop to RNF0 for address A, since the snoop filter presence vector indicates that the data is in the cache of RNF0, thereby implying detecting by the home node that the coherent cache line is shared with other RN-Fs]),
wherein the detecting is based on a presence vector within the DSF of the first coherent home node (Jalal, [0029 - The snoop filter records the data as UniqueClean/UC and updates the presence vector/SF presence to indicate that RNF0 has a copy of the data. See Table 1]; [0050 - The snoop filter/DSF presence vector indicates that the data is in the cache of RNF0]);
determining, by the first coherent home node, a current owner (Jalal, [0030 - The snoop filter indicates that the data is in the cache of RNF0/current owner]) of the coherent cache line (Jalal, [0027 - The snoop filter cache 302 contains a number of records 308 associated with cached data in the system. Each record 308 comprises tag field 310, a cache coherence status field 312, a RNF-ID field 314 that identifies the owner of any SharedDirty/SD or Owned data, and presence vector 316, thereby implying that the information helps the HN-F to determine the current owner of the cache line]),
wherein the determining is based on information within the DSF of the first coherent home node (Jalal, [0030 – As per Table 1, the snoop filter indicates that the data is in the cache of RNF0/current owner]; [0049 – As per Table 2, the snoop filter/DSF records the data as UniqueClean/UC and updates the presence vector to indicate that RNF0/current owner has a copy of the data]);
Arm further discloses,
sending, by the first coherent home node, to the one or more other coherent request nodes (Arm, [Pg. 1-27: See Figs. 1-2]; [Pg. 1-30: See Figs. 1-4]), except the current owner that was determined (Arm, [Pg. 4-189 - A snoop filter or directory within the interconnect to track the state of cache lines present in RN-F caches. The tracking can be as detailed as knowing each RN-F that has a copy of the cache line. Such tracking permits the ICN to filter unnecessary snooping of an RN-F, thereby implying determination of current owner]), an invalidating snoop instruction (Arm, [Pg. 1-24 - Write-Invalidate protocol - A protocol in which an RN writing to a cache line that is shared in the system must invalidate all the shared copies before proceeding with the write. The AMBA CHI protocol is a Write-Invalidate protocol]; [Pg. 4-186 – SnpCleanInvalid, SnpMakeInvalid; Since the claim does not recite any invalidating snoop instruction/transaction name, the recitation is a valid interpretation]);
transmitting (Arm, [Pg. 2-85 – See Fig. 2-25]), by the first coherent home node, a forwarding snoop instruction (Arm, [Pg. 2-85 - The interconnect/HN provides a Snoop request, SnpSharedFwd or SnpUniqueFwd, on the SNP channel; Also see Pg. 2-45]),
wherein the forwarding snoop instruction establishes a direct cache transfer (DCT) (Arm, [Pg. 4-222 - Forwarding Snoop transactions – Forwarding/Fwd type snoops are used by Home to support DCT/Direct Cache Transfer]) between the first coherent request node and the current owner of the coherent cache line (Arm, [Pg. 2-85 - The snooped RN/current owner forwards the Data to the Requester using the CompData opcode on the WDAT channel]; [Pg. 1-31 - Defines the feature which permits a peer RN-F to send Data directly to the Requester]),
wherein the sending an invalidating snoop instruction occurs prior to the transmitting a forwarding snoop instruction (Arm, [Pg. 4-162 – Coherence Protocol]; [Pg. 124, Write-Invalidate protocol - A protocol in which an RN writing to a cache line that is shared in the system must invalidate all the shared copies before proceeding with the write. The AMBA CHI protocol is a Write-Invalidate protocol; This implies that the invalidating snoop is broadcast on the bus before the writing node updates its local cache, which ensures that all other caches holding a copy of the data receive the invalidation signal and mark their copies as invalid. This further implies that the invalidating snoop occurs prior to the forwarding snoop]; [Pg. 4-222, Sec. 4.8.3: Forwarding Snoop transactions – Forwarding/Fwd type snoops are used by Home to support DCT]; [Pg. 2-85, Pg. 4-228 - Home is permitted to send the SnpUniqueFwd snoop to an RN-F in Shared state if Home determines that the invalidating snoop needs to be sent to only one cache, thereby also implying that the invalidating snoop precedes the forwarding snoop; Since the claim previously recites sending the invalidating snoop by the home node, to the one or more request nodes, it suggests sending the invalidating snoop to at least one request node. Therefore the citation is a valid interpretation]);
wherein in response to the first coherent request node indicating ([See 112(a)]) that data associated with the coherent cache line will be overwritten by a subsequent write operation (Arm, [Pg. 4-163, Sec. 4.1.1: Empty cache line ownership - Before starting a write, to save system bandwidth, a Requester that expects to write to a cache line can obtain an empty cache line with permission to store, instead of obtaining a Valid copy of the cache line]), the first coherent home node provides the first coherent request node with an empty (Arm, [Pg. 4-163, Sec. 4.1.1: Empty cache line ownership - An empty cache line is a cache line that is held in a Unique state, so no other copies of the cache line exist]) cache line (Arm, [Pg. 4-163 - A Requester can deliberately obtain an empty cache line, thereby implying requesting the empty cache line from the first coherent home node]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the coherence protocol of Arm into the multicore SoC architecture of Jalal, for the benefit of using a scalable packet-based communication where all transactions are handled by an interconnect-based Home Node that co-ordinates required snoops, cache, and memory accesses (Arm, Pg. 1-20).
Tune clarifies the DSF related cache as follows,
wherein the DSF comprises a cache with a plurality of ways (Tune, [0042 – In Fig. 1, inclusive snoop directory memory 14 is a SRAM memory having multiple ways, i.e. set associative. These ways are addressed using an index value derived from a portion of the memory address of the memory access request]; [0039 - Inclusive snoop directory memory 14/cache is part of a snoop filter/DSF]);
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the set associative DSF cache of Tune into the multicore SoC architecture of Jalal, Arm for the benefit of using the inclusive snoop directory memory for coherent writes and cache maintenance operations to reduce the amount of snoop traffic generated (Tune, 0041).
As per Claim 2, the rejection of claim 1 is incorporated, and Jalal discloses,
wherein the first coherent request node comprises a plurality of processor cores and caches (Jalal, [0015 – In Fig. 1, each functional block 102 comprises cluster of processing cores/CPUs that share an L2 cache, with each processing core having its own L1 cache]).
As per Claim 3, the rejection of claim 2 is incorporated, and Jalal discloses,
coupling, within the first coherent request node, a hierarchical cache to one or more processor cores within the plurality of processor cores (Jalal, [0015 – In Fig. 1, each RN-F 102 comprises cluster of processing cores/CPUs that share an L2 cache, with each processing core having its own L1 cache]),
wherein the hierarchical cache is shared among the one or more processor cores (Jalal, [0015 – In Fig. 1, cores/CPUs share an L2 cache]),
and wherein the hierarchical cache is further coupled to a compute coherency block (CCB) (Jalal, [0018 - To maintain coherence, each RN includes a cache controller 114/CCB]).
Arm clarifies the hierarchical cache as follows,
coupling, within the first coherent request node (Arm, [Fig. 11-1]), a hierarchical cache to one or more processor cores within the plurality of processor cores (Arm, [Pg. 11-351 – In Fig. 11-1, each chip in the system has two processors per cluster/RN, with a three level cache hierarchy]),
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the coherence protocol of Arm into the multicore SoC architecture of Jalal, Tune for the benefit of using a scalable packet-based communication where all transactions are handled by an interconnect-based Home Node that co-ordinates required snoops, cache, and memory accesses (Arm, Pg. 1-20).
As per Claim 4, the rejection of claim 3 is incorporated, and Jalal discloses,
wherein the requesting is accomplished by the CCB within the first coherent request node (Jalal, [0018 – In Fig. 1, to maintain coherence, each RN-F/first includes a cache controller 114 that accepts load and store instructions from the processor cores. The cache controller 114 also issues and receives coherence requests and responses via the interconnect circuit 106 from other nodes, thereby implying that the requesting is accomplished by the CCB within the first RN-F]).
As per Claim 5, the rejection of claim 4 is incorporated, and Jalal discloses,
wherein the forwarding snoop instruction establishes a DCT between the CCB (Jalal, [0018 - The cache controller 114/CCB also issues and receives coherence requests and responses via the interconnect circuit 106 from other nodes]) within the first coherent request node and the current owner of the coherent cache line (Jalal, [0031 - In response to the snoop, RNF0 downgrades the data in its cache to state SD, also in line 2 of the table, and provides data with snoop response. RNF1 receives the cache data in the SC state from RNF0 directly/DCT]).
Arm clarifies the forwarding snoop instruction and DCT as,
wherein the forwarding snoop instruction (Arm, [Pg. 1-26 – Transaction Classification, Snoop: SnpSharedFwd]) establishes a DCT (Arm, [Pg. 1-31 - DCT: Defines the feature which permits a peer RN-F to send Data directly to the Requester]) between the CCB within the first coherent request node and the current owner of the coherent cache line (Arm, [Pg. 4-194 - Snoop response without Data to Home and Direct Cache Transfer (DCT): This Snoop response is used when the Snoopee/current owner sends Data to the Requester]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the coherence protocol of Arm into the multicore SoC architecture of Jalal, Tune for the benefit of using a scalable packet-based communication where all transactions are handled by an interconnect-based Home Node that co-ordinates required snoops, cache, and memory accesses (Arm, Pg. 1-20).
As per Claim 7, the rejection of claim 3 is incorporated, and Jalal discloses,
wherein a second coherent request node, in the plurality of coherent request nodes, includes a CCB (Jalal, [0018 – In Fig. 1, to maintain coherence, each RN includes cache controller 114/CCB, thereby implying that the second RN-F includes a CCB]).
As per Claim 8, the rejection of claim 7 is incorporated, and Jalal discloses,
wherein the DSF includes an entry for each cache line within the hierarchical cache coupled to the CCB (Jalal, [Fig. 1]) of the second coherent request node and the hierarchical cache coupled to the CCB of the second coherent request node (Jalal, [0027 – In Fig. 3, snoop filter cache 302 contains a number of records 308 associated with cached data in the system. Each record 308/entry comprises tag field 310, a cache coherence status field 312, an RNF-ID field 314, and a presence vector 316. The presence vector 316 contains bits that indicate which nodes/RN-F’s of the system have the data in their local cache, thereby implying that the DSF includes an entry for each cache line within the hierarchical cache coupled to the CCB of the second RN-F]).
As per Claim 9, the rejection of claim 1 is incorporated, and Jalal discloses,
the determining further comprises searching, by the first coherent home node (Jalal, [0043 – In Fig. 5, following a request sent from an RN-F to the HN-F, to access data at an address in system memory, the address is looked-up in the system cache of the HN-F and in the snoop filter at step 504]), for a hit within the DSF on the address associated with the coherent cache line (Jalal, [0044 – In Fig. 5, step 510, determining if the address is found in the snoop filter,.i.e. snoop filter hit?]).
As per Claim 10, the rejection of claim 1 is incorporated, and Jalal discloses,
reading an owner ID and an owner valid bit within the DSF (Jalal, [0027 – In Fig. 3, each record 308 comprises tag field 310, which identifies the associated data, a cache coherence status field 312 that indicates the MOESI state of the data, an RNF-ID field 314 that identifies the owner of any SharedDirty or Owned data, and a presence vector 316. The presence vector 316 contains bits/owner valid bit that indicate which nodes of the system have the data in their local cache. Thus the snoop filter keeps track, in field 314, of the owner of SharedDirty/SD data in addition to all of the sharers of the data. The owner of the SD data is a device such as a Request Node for CPU cluster, GPU, DSP etc.]).
As per Claim 11, the rejection of claim 1 is incorporated, and Jalal discloses,
wherein the determining further comprises sending a read request to a memory (Jalal, [Fig. 5: step 510, SF hit? No]; [0043 – In Fig. 5, step 510, if the address is not found in the snoop filter, or a snoop filter ‘miss’ occurred, a signal to read the data from memory is sent to a memory controller at step 512]).
As per Claim 12, the rejection of claim 11 is incorporated, and Jalal discloses,
wherein an index of the address associated with the coherent cache line misses in the DSF (Jalal, [0043 – In Fig. 5, step 510, if the address is not found in the snoop filter, then a snoop filter miss occurred]).
As per Claim 13, the rejection of claim 12 is incorporated, and Jalal discloses,
forwarding data from memory to the first coherent request node (Jalal, [0043 – In Fig. 5, the data is received from the memory controller at step 514 and forwarded to the requesting RN-F/first at step 516]).
As per Claim 14, the rejection of claim 13 is incorporated, and Jalal discloses,
saving, in the DSF, details about the coherent cache line (Jalal, [0043 – In Fig. 5, step 512, the snoop filter is updated, thereby implying saving, in the DSF, details about the coherent cache line]).
As per Claim 15, the rejection of claim 2 is incorporated, and Jalal, Arm disclose the DSF or the snoop filter.
Tune further clarifies the DSF as follows,
wherein an index (Tune, [0042 – In Fig. 1, inclusive snoop directory memory 14 is an SRAM memory having multiple ways, i.e. set associative. These ways are addressed using an index value]) of the address associated with the coherent cache line misses in the DSF (Tune, [Fig. 4: step 46, Hit in snoop directory? No]), but all ways associated with the index are occupied (Tune, [0061 – In Fig. 4, step 54, a determination is made as to whether or not there is a free line available in the inclusive snoop directory memory 14, which may depend on the organization of the inclusive snoop directory memory, e.g. set associativity]; [Fig. 4: step 54, Free line in snoop directory? No, thereby implying that all ways associated with the index are occupied]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the set associative DSF cache of Tune into the multicore SoC architecture of Jalal, Arm for the benefit of using the inclusive snoop directory memory for coherent writes and cache maintenance operations to reduce the amount of snoop traffic generated (Tune, 0041).
As per Claim 16, the rejection of claim 15 is incorporated, and Jalal, Arm,
Tune disclose,
evicting a random entry within the way of the DSF that is associated with the index (Tune, [0061 – In Fig. 4, if no free line is detected at step 54, then processing proceeds to step 58 where a line is evicted from the inclusive snoop directory memory 14]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the set associative DSF cache of Tune into the multicore SoC architecture of Jalal, Arm for the benefit of using the inclusive snoop directory memory for coherent writes and cache maintenance operations to reduce the amount of snoop traffic generated (Tune, 0041).
As per Claim 17, the rejection of claim 16 is incorporated, and Jalal, Arm,
Tune disclose,
invalidating, by each coherent request node in the plurality of coherent request nodes (Tune, [0039 – In Fig. 1, L1 cache memories 6 for a pair of cores 4 share a L2 cache memory 8]), an entry corresponding to the random entry within the way of the DSF that was evicted (Tune, [Fig. 4: step 58: Evict line from snoop directory and invalidate/clean cache lines in L2 caches]; [0061 – In Fig. 4, the corresponding cache lines pointed to by the newly evicted directory line are invalidated, cleaned from the L2 cache memories 8]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the set associative DSF cache of Tune into the multicore SoC architecture of Jalal, Arm for the benefit of using the inclusive snoop directory memory for coherent writes and cache maintenance operations to reduce the amount of snoop traffic generated (Tune, 0041).
As per Claim 18, the rejection of claim 17 is incorporated, and Jalal discloses,
writing, to a memory, data from the entry that was evicted (Jalal, [0053 - If evicted, the data is written back to the memory since it was marked as ‘dirty’]),
wherein the data was marked as dirty in a coherent request node in the plurality of coherent request nodes (Jalal, [0051 - The system cache is filled and the data in the system cache is marked ‘dirty’, since the home node determines that the data store RNF0 should now be in the SD/SharedDirty state]).
As per Claim 20, the rejection of claim 1 is incorporated, and Jalal discloses,
wherein the plurality of coherent request nodes includes one or more multicore processors (Jalal, [0015 – In Fig. 1, functional blocks 102 each comprise cluster of processing cores/CPUs)]).
As per Claim 21, the rejection of claim 22 is incorporated, and Jalal, Arm, Tune disclose,
wherein the coherent bus implements an AMBA (Arm, [Pg. 483 – AMBA/ Advanced Microcontroller Bus Architecture provides solutions for the interconnection and management of the functional blocks that make up a System-on-Chip/SoC]) CHI coherency protocol (Arm, [Pg. 1-27, Fig. 1-2: Coherency model, ICN]; [Pg. 1-24 – ICN/interconnect which is the CHI transport mechanism that is used for communication between protocol nodes. The ICN might include protocol nodes such as Home Node and Misc Node]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the coherence protocol of Arm into the multicore SoC architecture of Jalal, Tune for the benefit of using a scalable packet-based communication where all transactions are handled by an interconnect-based Home Node that co-ordinates required snoops, cache, and memory accesses (Arm, Pg. 1-20).
As per Claim 22, the rejection of claim 1 is incorporated, and Jalal discloses,
wherein the SOC includes a second coherent home node (Jalal, [0015 – In Fig. 1, system 100 is implemented in a System-on-Chip/SoC integrated circuit, with second HN-F]).
As per Claim 23, the rejection of claim 22 is incorporated, and Jalal discloses,
wherein the requesting includes the first coherent home node and the second coherent home node (Jalal, [0015 – In Fig. 1 blocks 102/RN-F and 104/RN-F are request nodes that generate requests for data transactions. They are coupled via interconnect circuit 106, to data resources that are accessed via home nodes 108/HN-F’s and memory controller 110 that enable the request nodes to access shared main memory 112 or input/output devices, thereby implying that the requesting includes the first coherent home node and the second coherent home node]).
As per Claim 24, it is similar to claim 1 and therefore the same rejections are incorporated.
As per Claim 25, it is similar to claim 1 and therefore the same rejections are incorporated.
Claims 19, 26 are rejected under AIA 35 U.S.C. 103(a) as being unpatentable over Jalal et al (20190079868) in view of Arm (‘AMBA 5 CHI Architecture Specification’, 2014, Pgs. 1-20 to 16-463), Tune (20140281180), and Randall et al (20230139212).
As per Claim 19, the rejection of claim 18 is incorporated, and Jalal discloses,
saving, in the DSF ([See 112(b)]), details about the coherent cache line (Jalal, [0027 – In Fig. 2, the snoop filter cache 302 contains a number of records 308 associated with cached data in the system]), wherein the saving includes updating the DSF (Jalal, [0043 - Fig. 5 shows operation of a snoop filter control logic of a SF of a fully-coherent home node/HN-F]; [0045 – In Fig. 5, step 526, the snoop filter/DSF is updated to indicate that the requesting RN-F will have a copy of the data and the data is forwarded to the RN-F node at block 516]) as part of transferring ownership (Jalal, [0037 – In Table 1, data stored in and transferred between caches is marked with a MOESI state, i.e. requester in UniqueClean/UC state and current owner in Invalid/I state]) of the coherent cache line from one core to another core (Jalal, [0027 – In Fig. 3, the snoop filter keeps track, in field 314, of the owner of SharedDirty/SD data in addition to all sharers of the data]; [0062 - A method of data transfer in a system having a shared data resource and a network of nodes, the shared data resource accessible by request nodes of the network via a home node of the network]),
wherein the details include a presence vector, an owner ID, an owner valid field, an index value ([See 112(b)]), and a valid field value (Jalal, [0027 – In Fig. 3, each record 308 comprises tag field 310/index, which identifies the associated data, a cache coherence status field 312 that indicates the MOESI state/valid field of the data, an RNF-ID field 314 that identifies the owner of any SharedDirty/SD or Owned data, and a presence vector 316. The presence vector 316 contains bits/owner valid bit that indicate which nodes of the system have the data in their local cache]).
Neither the claim nor the spec define ‘an index value’ and how it is determined.
Randall clarifies,
wherein the details include a presence vector (Randall, [0120 - Figs. 12A-12B a presence vector comprising multiple presence bits]; [0123 - Fig. 13 shows a 4-bit presence vector implementation]), an owner ID (Randall, [0126 – In Fig. 13, two bits from the tag portion of the address for cache line C are used to identify one of the bits in the presence vector 0 700 associated with set 0 of the backup snoop filter table; This representation is similar to Fig. 7 of the spec]), an owner valid field (Randall, [0125 - In Fig. 13, it is assumed that the relevant two bits of the tag portion of the address for cache lines A and B identify the third presence bit, and the relevant two bits of the tag portion of the address for cache line C identify the second presence bit, and accordingly the current state/valid of the presence vector 0 is 0110]; [0057 - When adopting an implementation that uses a presence bit vector in association with each of the sets in a lower level snoop filter table, then the current state/validity of the presence bits in the presence bit vector can be used to influence decisions taken when a victim entry is to be selected]), an index value (Randall, [0084 – In Fig. 3, the index portion 160 of the address is provided to a set determination function 197 which determines from that index portion an index value used to identify a particular set within the snoop filter table; It is well known in the art that in an m-way associative snoop filter, row index is same as set index]), and a valid field value (Randall, [0086 – In Fig. 4, at step 210, it is determined if there is a free entry in the identified set. One example of determining is when each of the entries includes a valid bit which is set to indicate that the corresponding entry stores valid coherence data]; [0087 - The valid bit will also be set to identify that the entry stores valid coherence data]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the presence vector of Randall into the multicore SoC architecture of Jalal, Arm, Tune for the benefit of having each entry store, for an associated address, coherence data used to determine which cache storages provided within the multiple processing units need to be subjected to a snoop operation in response to a request specifying that associated address. By using the presence vector, the snoop filter acts as a directory or a M-way associative set of tables, allowing the system to know where data is cached without having to query every single cache every time (Randall, 0006).
As per Claim 26, the rejection of claim 1 is incorporated, and Jalal, Arm, Tune disclose,
wherein enabling the DCT (Arm, [Pg. 1-31 – DCT: Defines the feature which permits a peer RN-F to send Data directly to the Requester]) includes accessing the DSF (Arm, [Pg. 1-29, HN-F - Fully coherent Home Node receives protocol transactions from RNs. It includes a directory or snoop filter. Also includes a Point of Coherence/PoC that manages coherency by snooping the required RN-Fs, consolidating the snoop responses for a transaction, and sending a single response to the requesting RN; This implies that when a fully coherent Request Node/RN-F initiates a transaction, the HN-F receives the request and consults the snoop filter]),
wherein the DSF is configured to provide coherence information ([See 112(a)]) used to establish the direct cache transfer (Arm, [Pg. 1-27 – In Fig. 1-2, the coherence protocol ensures that all masters/RN-Fs observe the correct data value at any given address location by enforcing that no more than one copy exists whenever a store occurs to the location. After each store to a location, other masters can obtain a new copy of the data for their own local cache, to permit multiple cached copies to exist]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the coherence protocol of Arm into the multicore SoC architecture of Jalal, for the benefit of using a scalable packet-based communication where all transactions are handled by an interconnect-based Home Node that co-ordinates required snoops, cache, and memory accesses (Arm, Pg. 1-20).
Randall discloses,
wherein enabling the DCT includes accessing the DSF (Randall, [Fig. 1: snoop unit 70]; [0066 - When an access request is issued by one of the processing units seeking to access data at a memory address specified by the access request, and a hit is not detected in any local cache structure of that processing unit, then that access request is propagated to snoop unit 70]) by using an index value (Randall, [0072 – In Fig. 1, snoop control circuitry applies a hash function when generating an index into one or more snoop filter tables]; [0084 – In Fig. 3, index portion 160 of the address is provided to a set determination function 197 which determines from that index portion an index value used to identify a particular set within the snoop filter table]) to reference an entry in an M-way associative table (Randall, [0073 - Each snoop filter table is arranged as a multi-way set associative storage structure providing a plurality of entries]) having an index value (Randall, [0084 – In Fig. 3, the index portion 160 of the address is provided to a set determination function 197 which determines from that index portion an index value used to identify a particular set within the snoop filter table; It is well known in the art that in an m-way associative snoop filter, row index is same as set index), a valid indicator (Randall, [0086 – In Fig. 4, at step 210, it is determined if there is a free entry in the identified set. One example of determining is when each of the entries includes a valid bit which is set to indicate that the corresponding entry stores valid coherence data]; [0087 - The valid bit will also be set to identify that the entry stores valid coherence data]), a presence vector (Randall, [0120 - Figs. 12A-12B a presence vector comprising multiple presence bits]; [0123 - Fig. 13 shows a 4-bit presence vector implementation]), an owner identifier (Randall, [0126 – In Fig. 13, two bits from the tag portion of the address for cache line C are used to identify one of the bits in the presence vector 0 700 associated with set 0 of the backup snoop filter table; This representation is similar to Fig. 7 of the spec]), and an owner valid bit for each row (Randall, [0125 - In Fig. 13, it is assumed that the relevant two bits of the tag portion of the address for cache lines A and B identify the third presence bit, and the relevant two bits of the tag portion of the address for cache line C identify the second presence bit, and accordingly the current state/valid of the presence vector 0 is 0110]; [0057 - When adopting an implementation that uses a presence bit vector in association with each of the sets in a lower level snoop filter table, then the current state/validity of the presence bits in the presence bit vector can be used to influence decisions taken when a victim entry is to be selected]),
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the presence vector of Randall into the multicore SoC architecture of Jalal, Arm, Tune for the benefit of having each entry store, for an associated address, coherence data used to determine which cache storages provided within the multiple processing units need to be subjected to a snoop operation in response to a request specifying that associated address. By using the presence vector, the snoop filter acts as a directory or a M-way associative set of tables, allowing the system to know where data is cached without having to query every single cache every time (Randall, 0006).
Response to Arguments
The Applicant's arguments filed on May 30, 2026 have been fully considered, but they are not persuasive.
The amendments are improper because they rely on speculation and extrapolation. Speculation, extrapolation, hindsight reconstruction, and ‘filling in the gaps’, does not satisfy the written description requirement.
Applicant argues:‘Claim 1 is currently amended to include…. in response to the first coherent request node indicating that data associated with the coherent cache line will be overwritten by a subsequent write operation, the first coherent home node provides the first coherent request node with an empty cache line’. (Rem, Pg. 9)
Response: The spec does not recite this limitation. Please see the 112(a).
Para-0034 of the spec recites, ‘…. a requesting node can request an empty cache line prior to starting a write operation, enabling saving of system bandwidth by avoiding the need to transfer data that will be overwritten with the subsequent write operation’.
In the spec, the requesting node drives the process by actively requesting an empty line. Conversely, the claim shifts the responsibility, requiring the home node to provide the empty line in response to the requesting node indicating a future overwrite.
The limitation is improper because it amounts to paraphrasing without clear citations to the original spec.
Applicant further argues:‘With particular regard to claim 19, it is currently amended to include…."wherein the saving includes updating the DSF ….including in paragraph [0053].....Disclosed embodiments may modify the owner ID field, and/or owner valid bit as part of transferring ownership of a cache line from one core to another core’. (Rem, Pg. 10)
Response: This argument is incorrect. The argument relies on extrapolation and speculation not inherent to the original disclosure. Please see the 112(b).
Para-0053 of the spec does not disclose ‘updating the DSF’. Para-0053 merely discloses the parameters of an entry/row in the DSF. That’s all.
The spec teaches the ‘DSF’ as a black box. To ‘update the DSF’, the DSF must be searchable. But the spec does not teach how to search the DSF, suggesting lack of possession. Accordingly the spec does not teach ‘update the DSF’.
The applicant’s arguments cannot take the place of disclosure in the spec. The scope cannot be broadened by applicant assertions unsupported by the original application's text or drawings.
Applicant further argues:‘Claim 26 is new…., including in Fig. 7, along with paragraphs [0053]-[0055], which states: "In one or more embodiments, to search within the DSF, disclosed embodiments utilize an index value to reference a desired entry in the DSF."’ (Rem, Pg. 11)
Response: This argument is incorrect. Please see the 112(a).
The spec does not recite the limitation. The spec is a high-level document and does not disclose details. It relies on one-line, casual recitations to disclose a component and/or feature. One-line recitations do not fulfill the written description requirement.
For example, claim 26 defines the ‘DSF’ as a M-way associative table. However, the spec provides three inconsistent definitions for the same DSF term (table vs. set of tables vs. two-dimensional matrix). There is no text describing if the DSF is meant to be a single table, a group of tables, or an entirely different mathematical matrix, rendering the bounds of the claim scope unsupported by the spec. The lack of disclosure of a specific structure for the DSF suggests lack of possession.
The spec provides no written description support determining the ‘index’ and/or ‘an index value to reference a desired entry in the DSF’.
By not clearly defining the structure of the ‘DSF’, by not disclosing how to derive the ‘index’ to search and update the DSF, but instead broadly claiming ‘utilize an index value to reference a desired entry in the DSF’ the inventor is attempting to lock in every possible method of creating an index to search every form of DSF structure, regardless of whether they possess it.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARVIND TALUKDAR whose telephone number is (303)297-4475. The examiner can normally be reached M-F, 10 am-6pm 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, Hosain Alam can be reached at 571-272-3978. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
Arvind Talukdar
Primary Examiner
Art Unit 2132
/ARVIND TALUKDAR/Primary Examiner, Art Unit 2132
Prosecution Insights