DETAILED ACTION
This office action is in response to applicant’s remarks filed on July 9, 2026 in application 19/007,323.
Claims 1-14, 16-21 are presented for examination. Claims 1-2, 13 and 19 are amended. Claim 15 is cancelled. Claim 21 is newly added.
Applicant intended for claim 19 to invoke interpretation under 35 USC 112(f) or under pre-AIA 35 USC 112, 6th paragraph is acknowledged.
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 .
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-14, 16-21 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
It is noted that the amendment does not conform to the requirements for making amendments in an application where (2) When claim text with markings is required. All claims being currently amended in an amendment paper shall be presented in the claim listing, indicate a status of "currently amended," and be submitted with markings to indicate the changes that have been made relative to the immediate prior version of the claims. The text of any added subject matter must be shown by underlining the added text. The text of any deleted matter must be shown by strike-through except that double brackets placed before and after the deleted characters may be used to show deletion of five or fewer consecutive characters. The text of any deleted subject matter must be shown by being placed within double brackets if strike-through cannot be easily perceived. Only claims having the status of "currently amended," or "withdrawn" if also being amended, shall include markings. If a withdrawn claim is currently amended, its status in the claim listing may be identified as "withdrawn— currently amended." See MPEP 37 C.F.R.1.121 for further details.
For the purpose of examination, examiner made corresponding changes to amended claims 1-2, 13 and 19.
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 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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-9, 11-14, 16-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Estep et al. (US 2023/0056665) in further view of Ozog et al. (US 2019/0188111).
In regard to claim 1, Estep et al. teach a method for scalable counters-based event detection, the method comprising:
receiving, at an event information collector, at least one event notification from an event source of a plurality of event sources, (the event receive mechanism implements an atomic operation to reset the event counter value to the initial value and maintains the collection receive mode, para. 27, fig. 10, 1052);
translating, the at least one event notification into at least one remote atomic increment operation (in collection mode, an event counter is used to track how many event messages are received… when the number of event messages equals the event count, then the event is said to have occurred, para. 139-140, fig. 10); and
modifying, based on the at least one remote atomic increment operation, at least one counter value (an incrementing or decrementing mechanism may be used to track, para. 139, fig. 10, 1054).
Estep et al. does not explicitly teach wherein the at least one event notification includes an identification associated with the event source and translating, based on the identification associated with the event source.
Ozog et al. teach of a High performance computing (HPC) where the host fabric interface (HFI) include hardware event counters to track when certain events occur. When the instruction from the CPU of the first node corresponds to a triggered operation, the HFI can monitor the count of a corresponding event counter to identify when to transmit the data identified by instructions from the CPU of the first node (para. 13). For example, the collector 108 utilizes processor resources of the example CPU 103 to collect performance data to measure the progress of communication operation of the application 104 (para. 23, fig. 1).
It would have been obvious to modify the Estep et al. by adding Ozog et al. improve performance data collection. A person of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to make the modification because it would aid in tracking when certain events occur or when the instruction from the CPU of the first node corresponds to a triggered operation (para. 13).
In regard to claim 2, Estep et al. teach the method of claim 1, wherein modifying, based on the at least one remote atomic increment operation, the at least one counter value further comprises: modifying, based on the at least one remote atomic increment operation, the at least one counter value (adjust count, fig. 10, 1004) at a specified address space of memory (the event receive state consists of an event receive mode, an overflow bit, event receive counter (16 bits) and a dual use event trigger/event broadcast channel (16 bits), para. 135).
In regard to claim 3, Estep et al. teach the method of claim 2, further comprising:
translating a portion of the at least one event notification into at least one further remote atomic increment operation (atomic operation, fig. 10, 1056); and
modifying, based on the at least one further remote atomic increment operation, a further counter value at a further specified address space of the memory (adjust count, fig. 10, 1054).
In regard to claim 4, Estep et al. does not explicitly teach the method of claim 1, wherein the identification associated with the event source includes an identification of the event source.
Ozog et al. teach of a High performance computing (HPC) where the host fabric interface (HFI) include hardware event counters to track when certain events occur. When the instruction from the CPU of the first node corresponds to a triggered operation, the HFI can monitor the count of a corresponding event counter to identify when to transmit the data identified by instructions from the CPU of the first node (para. 13). For example, the collector 108 utilizes processor resources of the example CPU 103 to collect performance data to measure the progress of communication operation of the application 104 (para. 23, fig. 1).
Refer to claim 1 for motivational statement.
In regard to claim 5, Estep et al. teach the method of claim 1, wherein translating the at least one event notification into the at least one remote atomic increment operation further comprises: translating, based on a base address of memory that stores the at least one counter value and a Segment Bus-Device-Function (SBDF) value, a Bus-Device-Function (BDF) value, a Bus-Device (BD) value, or a Bus (B) value, the at least one event notification into the at least one remote atomic increment operation (use an atomic operation to reset the counter value, alert a thread of the event, fig. 12, para. 161-169).
Estep et al. does not explicitly teach translating the event notification associated with the event source.
Ozog et al. teach of a High performance computing (HPC) where the host fabric interface (HFI) include hardware event counters to track when certain events occur. When the instruction from the CPU of the first node corresponds to a triggered operation, the HFI can monitor the count of a corresponding event counter to identify when to transmit the data identified by instructions from the CPU of the first node (para. 13). For example, the collector 108 utilizes processor resources of the example CPU 103 to collect performance data to measure the progress of communication operation of the application 104 (para. 23, fig. 1).
Refer to claim 1 for motivational statement.
In regard to claim 7, Estep et al. teach the method of claim 1, wherein modifying, based on the at least one remote atomic increment operation, the at least one counter value further comprises: incrementing, based on the remote atomic increment operation, the counter value as a saturating increment (an atomic operator of “increment’ can be specified in a command, para. 108).
In regard to claim 8, Estep et al. teach the method of claim 1, wherein modifying, based on the at least one remote atomic increment operation, the at least one counter value further comprises: decrementing, based on the remote atomic increment operation, the counter value as a saturating decrement (decrementing mechanism, an event count value is initially set to some value larger than one and a received event causes the event count value to be decremented by one, para. 141).
In regard to claim 9, Estep et al. teach the method of claim 1, further comprising:
determining whether the at least one counter value exceeds a threshold (when the count reaches the count trigger value, para. 140); and
based on a determination that the at least one counter value exceeds the threshold, (the event triggered bit is set, the EER instruction causes the event count to be reset, para. 140).
Estep et al. does not explicitly teach determining an operation that is to be performed on the event source.
Ozog et al. teach of a High performance computing (HPC) where the host fabric interface (HFI) include hardware event counters to track when certain events occur. When the instruction from the CPU of the first node corresponds to a triggered operation, the HFI can monitor the count of a corresponding event counter to identify when to transmit the data identified by instructions from the CPU of the first node (para. 13). The triggered put operation causes a write operation back to the memory of the node originating the triggered put operation (para. 16).
Refer to claim 1 for motivational statement.
In regard to claim 11, Estep et al. teach the method of claim 1, further comprising: determining, based on a bit vector, a region of memory that is modified (event receive counter is a 16 bits memory region that is incremented or decremented based on an event, para. 135).
In regard to claim 12, Estep et al. teach the method of claim 1, further comprising: utilizing an atomic swap to read the at least one counter value and to reset a counter associated with the at least one counter value (atomic operation: notify receiving thread when count is at threshold, maintain event mode and reset collection count, fig. 10, 1056).
In regard to claim 13, Estep et al. teach an apparatus for scalable counters-based event detection, the apparatus comprising: hardware configured to:
receive at least one event notification from an event source of a plurality of event sources (the event receive mechanism implements an atomic operation to reset the event counter value to the initial value and maintains the collection receive mode, para. 27, fig. 10, 1052);
translate the at least one event notification into at least one remote atomic increment operation (in collection mode, an event counter is used to track how many event messages are received… when the number of event messages equals the event count, then the event is said to have occurred, para. 139-140, fig. 10); and
modify, based on the at least one remote atomic increment operation, at least one counter value (an incrementing or decrementing mechanism may be used to track, para. 139, fig. 10, 1054).
Estep et al. does not explicitly teach wherein the at least one event notification includes an identification associated with the event source and translating, based on the identification associated with the event source.
Ozog et al. teach of a High performance computing (HPC) where the host fabric interface (HFI) include hardware event counters to track when certain events occur. When the instruction from the CPU of the first node corresponds to a triggered operation, the HFI can monitor the count of a corresponding event counter to identify when to transmit the data identified by instructions from the CPU of the first node (para. 13). For example, the collector 108 utilizes processor resources of the example CPU 103 to collect performance data to measure the progress of communication operation of the application 104 (para. 23, fig. 1).
Refer to claim 1 for motivational statement.
In regard to claim 14, Estep et al. teach the apparatus of claim 13, wherein to translate the at least one event notification into the at least one remote atomic increment operation, the hardware is further configured to: translate, based on a base address of memory that stores the at least one counter value and a Segment Bus-Device-Function (SBDF) value, a Bus-Device-Function (BDF) value, a Bus-Device (BD) value, or a Bus (B) value, the at least one event notification into the at least one remote atomic increment operation (use an atomic operation to reset the counter value, alert a thread of the event, fig. 12, para. 161-169).
Estep et al. does not explicitly teach translating the event notification associated with the event source.
Ozog et al. teach of a High performance computing (HPC) where the host fabric interface (HFI) include hardware event counters to track when certain events occur. When the instruction from the CPU of the first node corresponds to a triggered operation, the HFI can monitor the count of a corresponding event counter to identify when to transmit the data identified by instructions from the CPU of the first node (para. 13). For example, the collector 108 utilizes processor resources of the example CPU 103 to collect performance data to measure the progress of communication operation of the application 104 (para. 23, fig. 1).
Refer to claim 1 for motivational statement.
In regard to claim 16, Estep et al. teach the apparatus of claim 13, wherein to modify, based on the at least one remote atomic increment operation, the at least one counter value, the hardware is further configured to: increment, based on the at least one remote atomic increment operation, the at least one counter value as a saturating increment at a specified address space of memory (an atomic operator of “increment’ can be specified in a command, para. 108).
In regard to claim 17, Estep et al. teach the apparatus of claim 13, wherein to modify, based on the at least one remote atomic increment operation, the at least one counter value, the hardware is further configured to: decrement, based on the at least one remote atomic increment operation, the at least one counter value as a saturating decrement at a specified address space of memory (decrementing mechanism, an event count value is initially set to some value larger than one and a received event causes the event count value to be decremented by one, para. 141).
In regard to claim 18, Estep et al. teach the apparatus of claim 13, wherein the hardware is further configured to:
translate a portion of the at least one event notification into at least one further remote atomic increment operation (atomic operation, fig. 10, 1056); and
modify, based on the at least one further remote atomic increment operation, at least one further counter value (adjust count, fig. 10, 1054).
In regard to claim 19, Estep et al. teach an apparatus for scalable counters-based event detection, the apparatus comprising:
means for receiving, at an event information collector, at least one event notification from an event source of a plurality of event sources, (the event receive mechanism implements an atomic operation to reset the event counter value to the initial value and maintains the collection receive mode, para. 27, fig. 10, 1052);
means for translating the at least one event notification into at least one remote atomic increment operation (in collection mode, an event counter is used to track how many event messages are received… when the number of event messages equals the event count, then the event is said to have occurred, para. 139-140, fig. 10); and
means for modifying, based on the at least one remote atomic increment operation, at least one counter value (an incrementing or decrementing mechanism may be used to track, para. 139, fig. 10, 1054).
Estep et al. does not explicitly teach wherein the at least one event notification includes an identification associated with the event source and translating, based on the identification associated with the event source.
Ozog et al. teach of a High performance computing (HPC) where the host fabric interface (HFI) include hardware event counters to track when certain events occur. When the instruction from the CPU of the first node corresponds to a triggered operation, the HFI can monitor the count of a corresponding event counter to identify when to transmit the data identified by instructions from the CPU of the first node (para. 13). For example, the collector 108 utilizes processor resources of the example CPU 103 to collect performance data to measure the progress of communication operation of the application 104 (para. 23, fig. 1).
Refer to claim 1 for motivational statement.
In regard to claim 20, Estep et al. teach a non-transitory computer-readable medium storing computer-executable instructions that, when executed by a processor, cause the processor to:
receive, at an event information collector, at least one event notification from an event source of a plurality of event sources, (the event receive mechanism implements an atomic operation to reset the event counter value to the initial value and maintains the collection receive mode, para. 27, fig. 10, 1052);
translate the at least one event notification into at least one remote atomic increment operation (in collection mode, an event counter is used to track how many event messages are received… when the number of event messages equals the event count, then the event is said to have occurred, para. 139-140, fig. 10); and
modify, based on the at least one remote atomic increment operation, at least one counter value (an incrementing or decrementing mechanism may be used to track, para. 139, fig. 10, 1054).
Estep et al. does not explicitly teach wherein the at least one event notification includes an identification associated with the event source.
Ozog et al. teach of a High performance computing (HPC) where the host fabric interface (HFI) include hardware event counters to track when certain events occur. When the instruction from the CPU of the first node corresponds to a triggered operation, the HFI can monitor the count of a corresponding event counter to identify when to transmit the data identified by instructions from the CPU of the first node (para. 13). For example, the collector 108 utilizes processor resources of the example CPU 103 to collect performance data to measure the progress of communication operation of the application 104 (para. 23, fig. 1).
Refer to claim 1 for motivational statement.
In regard to claim 21, Estep et al. does not explicitly teach the method of claim 1, wherein the identification associated with the event source comprises a device identifier that identifies a device from which the at least one event notification originated.
Ozog et al. teach of a High performance computing (HPC) where the host fabric interface (HFI) include hardware event counters to track when certain events occur. When the instruction from the CPU of the first node corresponds to a triggered operation, the HFI can monitor the count of a corresponding event counter to identify when to transmit the data identified by instructions from the CPU of the first node (para. 13). For example, the collector 108 utilizes processor resources of the example CPU 103 to collect performance data to measure the progress of communication operation of the application 104 (para. 23, fig. 1).
Refer to claim 1 for motivational statement.
**********************
Claims 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Estep et al. (US 2023/0056665) in further view of Ozog et al. (US 2019/0188111) in further view of Levitt et al. (US 2025/0208960).
In regard to claim 6, Estep et al. and Ozog et al. does not explicitly teach the method of claim 1, wherein the at least one event notification includes at least one correctable error notification.
Levitt et al. teach of an error aggregator to identify a type of error from eh error reporting message and interface with error counter to update a count for the type of error received (e.g., count for correctable error, count for uncorrectable errors, and so on) (para. 203).
It would have been obvious to modify the method of Estep et al. and Ozog et al. by adding Levitt et al. correctable error address filtering. A person of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to make the modification because it would aid in identifying a type of error and also to aggregates the error reporting by using error counters (para. 203-209).
******************
Claims 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Estep et al. (US 2023/0056665) in further view of Ozog et al. (US 2019/0188111) in further view of Richards et al. (US 2006/0230306).
In regard to claim 10, Estep et al. and Ozog et al. does not explicitly teach the method of claim 1, further comprising: comparing the at least one counter value to a plurality of thresholds; and selecting, based on the comparison of the at least one counter value to the plurality of thresholds, an operation from a plurality of operations corresponding to different thresholds of the plurality of thresholds that is to be performed on the event source.
Richards et al. teach of count error event counting a plurality of error events and providing different threshold levels that trigger different degrees of error recovery, preserves certain counters between resets and system failures, permits end-users to adjust threshold levels indirectly based on predefined historical and empirical information and permits counting of error events in relation to a sliding window of time (para. 11).
It would have been obvious to modify the method of Estep et al. and Ozog et al. by adding Richards et al. monitoring and responding to error events. A person of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to make the modification because it would aid in counting error events in relation to time and to provide different threshold levels (para. 11).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO 892.
Ozog et al. (US 2022/0334948) event counters
Brennan et al. (US 12,405,888) performance event information counter
Hassan et al. (US 2026/0116417) atomic event counter
******************
Liu et al. (US 12,39,982) (Intel) correctable errors counter
Guo et al. (US 2025/0238298) (Intel) counter for correctable error
Xu et al. (US 2025/0208939) (Intel) correctable error (CE) counters and leaky buckets
Dice et al. (US 2014/0181827) (Oracle) scalable statistics counters that are adaptive to the amount of contention
HYPERLINK "mailto:Loan.truong@uspto.gov"
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LOAN TRUONG whose telephone number is 408-918-7552. The examiner can normally be reached on 10AM-6PM PST M-F.
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, Ashish Thomas can be reached on 571-272-0631. 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.
/Loan L.T. Truong/Primary Examiner, Art Unit 2114 Loan.truong@uspto.gov
