DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement submitted on December 20, 2023 has been considered by the Examiner and made of record in the application.
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 of this title, 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 text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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, 8, 10-14, 17, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kuravangi-Thammaiah et al. (hereinafter Kuravangi) (U.S. Patent Application Publication # 2024/0323092 A1) in view of Judd (U.S. Patent Application Publication # 2016/0342588 A1).
Regarding claims 1, 10, and 19, Kuravangi teaches a method and a wireless communication network to inhibit network data system signaling overload ([0052]; “…efficient network processing in responding to discovery requests, while minimizing latency and also reducing signaling in the network…”; teaches efficient network processing in order to minimize latency and also reduce signaling in the network), the wireless communication network comprising: a primary Unified Data Registry (UDR) (NRF/UDR-1, figure 2) configured to: detect a fault condition (status information, such as suspended or down; [0047]) for a secondary UDR (NRF/UDR-2, figure 2); blacklist (notification; [0047]; [0051]) the secondary UDR node for inter-UDR communications based on the fault condition; and transfer a command to another secondary UDR node to blacklist (notification; [0047]; [0051]) the secondary UDR node (NFR/UDR-3, figure 2); and the other secondary UDR node configured to: receive the command; and blacklist (notification; [0047]; [0051]) the secondary UDR node for inter-UDR communications ([0047]; [0051]; teaches an NRF/UDR determining the status information for a second NRF/UDR and sending notification information to another NRF/UDR of the status information in order to notify and update the status of the other NRF/UDR related to synchronization and communication in the network).
However, Kuravangi may not explicitly disclose update a network topology graph to remove the secondary UDR node; and to update the network topology graph to remove the secondary UDR node; and the other secondary UDR node configured to: update the network topology graph to remove the secondary UDR node.
Nonetheless, in the same field of endeavor, Judd teaches and suggests blacklist (exclusion list; [0099]) the secondary UDR node (storage/server node, figure 1; [0099]) for inter-UDR communications based on the fault condition (failure status; [0098]); update a network topology graph to remove the secondary UDR node; and to blacklist (exclusion list; [0099]) the secondary UDR node and to update the network topology graph to remove the secondary UDR node; and the other secondary UDR node (storage/server node, figure 1; [0099]) configured to: blacklist (exclusion list; [0099]) the secondary UDR node for the inter-UDR communications; and update the network topology graph to remove the secondary UDR node ([0098]; “…topology changes, and in response to a change in failure status…New failures will cause nodes to be removed from the topology. Failure resolutions will result in additions to the topology…”; [0099]; “…determining when storage nodes have failed and when they are healthy…notifications of node health status…to track the physical health of servers (nodes). The file update may be, for example, a list identifying specific servers (nodes) that are known to have failed. Unhealthy nodes…are included in an exclusion list and healthy nodes (if previously included) are removed from the exclusion list…”; teaches keeping track of the status of the storages nodes and including nodes that have failed into an exclusion list in order to update topology changes by removing or adding nodes from the topology).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate keeping track of the status of the storages nodes and including nodes that have failed into an exclusion list in order to update topology changes by removing or adding nodes from the topology as taught by Judd with the method and apparatus for determining status of UDRs as disclosed by Kuravangi for the purpose of dynamically updating topology and handling topology changes in order to improve performance in a storage network, as suggested by Judd.
Regarding claims 2, 11, and 20, Kuravangi discloses determining status of UDRs, but may not explicitly disclose in response to determining the fault condition no longer exists: whitelisting the secondary UDR node for the inter-UDR communications; and updating the network topology graph to add the secondary UDR node; and transferring an additional command to the other secondary UDR node to whitelist the secondary UDR node and to update the network topology graph to add the secondary UDR node wherein the other secondary UDR node receives the additional command, whitelists the secondary UDR node for the inter-UDR communications, and updates the network topology graph to add the secondary UDR node.
Nonetheless, in the same field of endeavor, Judd further suggests in response to determining the fault condition no longer exists: whitelisting the secondary UDR node for the inter-UDR communications; and updating the network topology graph to add the secondary UDR node; and transferring an additional command to the other secondary UDR node to whitelist the secondary UDR node and to update the network topology graph to add the secondary UDR node wherein the other secondary UDR node receives the additional command, whitelists the secondary UDR node for the inter-UDR communications, and updates the network topology graph to add the secondary UDR node ([0098]; “…topology changes, and in response to a change in failure status…New failures will cause nodes to be removed from the topology. Failure resolutions will result in additions to the topology…”; [0099]; “…determining when storage nodes have failed and when they are healthy…notifications of node health status…to track the physical health of servers (nodes). The file update may be, for example, a list identifying specific servers (nodes) that are known to have failed. Unhealthy nodes…are included in an exclusion list and healthy nodes (if previously included) are removed from the exclusion list…”; teaches keeping track of the status of the storages nodes and continuously updating the status of the nodes in an exclusion list in order to update topology changes by removing or adding nodes from the topology).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to keeping track of the status of the storages nodes and continuously updating the status of the nodes in an exclusion list in order to update topology changes by removing or adding nodes from the topology as taught by Judd with the method and apparatus for determining status of UDRs as disclosed by Kuravangi, as modified by Judd, for the purpose of dynamically updating topology and handling topology changes in order to improve performance in a storage network, as suggested by Judd.
Regarding claims 3 and 12, Kuravangi, as modified by Judd, further discloses wherein the inter-UDR communications comprise at least one of a data query or a data update ([0047]; [0051]; teaches communicating updates between NRF/UDRs).
Regarding claims 4 and 13, Kuravangi, as modified by Judd, further discloses wherein the primary UDR node is configured to detect a connectivity issue between the primary UDR node and the secondary UDR node to detect the fault condition ([0047]; [0051]; teaches an NRF/UDR determining the status information includes detected a connectivity issue).
Regarding claims 5 and 14, Kuravangi, as modified by Judd, further discloses the secondary UDR node configured to detect the fault condition and responsively transfer a notification to the primary UDR node indicating the fault condition; and wherein: the primary UDR node is configured to receive the notification and detect the fault condition for the secondary UDR node based on the notification ([0047]; [0051]; teaches sending notification information to another NRF/UDR of the status information in order to notify and update the status of the other NRF/UDR related to synchronization and communication in the network).
Regarding claims 8 and 17, Kuravangi, as modified by Judd, further discloses wherein the secondary UDR node is further configured to: determine when a hardware failure occurs; and detect the fault condition when the hardware failure occurs ([0047]; [0051]; teaches an NRF/UDR determining the status information includes detected a hardware failure).
Claims 6 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Kuravangi-Thammaiah et al. (hereinafter Kuravangi) (U.S. Patent Application Publication # 2024/0323092 A1) in view of Judd (U.S. Patent Application Publication # 2016/0342588 A1), and further in view of Galvin (U.S. Patent Application Publication # 2025/0342129 A1).
Regarding claims 6 and 15, Kuravangi, as modified by Judd, discloses determining status of UDRs and updating the topology based on the status of the UDRs, but may not explicitly disclose determine when Central Processing Unit (CPU) utilization exceeds a utilization threshold for a threshold period of time; and detect the fault condition when the CPU utilization exceeds the utilization threshold for the threshold period of time.
Nonetheless, in the same field of endeavor, Galvin teaches and suggest determine when Central Processing Unit (CPU) utilization exceeds a utilization threshold for a threshold period of time; and detect the fault condition when the CPU utilization exceeds the utilization threshold for the threshold period of time ([0205]; “…Resource monitoring component 2011 tracks CPU utilization above 80%...as thresholds… Failover handler 2034 maintains system reliability through checkpointing at 30-second intervals…”; teaches determining CPU utilization exceeds a threshold for a certain interval for detecting failure).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to determining CPU utilization exceeds and threshold for a certain interval as taught by Galvin with the method and apparatus for determining status of UDRs as disclosed by Kuravangi, as modified by Judd, for the purpose of monitoring the state of network nodes and CPU utilization, as suggested by Galvin.
Claims 7 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Kuravangi-Thammaiah et al. (hereinafter Kuravangi) (U.S. Patent Application Publication # 2024/0323092 A1) in view of Judd (U.S. Patent Application Publication # 2016/0342588 A1), and further in view of Kondiles et al. (hereinafter Kondiles) (U.S. Patent Application Publication # 2025/0298787 A1).
Regarding claims 7 and 16, Kuravangi, as modified by Judd, discloses determining status of UDRs and updating the topology based on the status of the UDRs, but may not explicitly disclose determine when memory utilization exceeds a utilization threshold for a threshold period of time; and detect the fault condition when the memory utilization exceeds the utilization threshold for the threshold period of time.
Nonetheless, in the same field of endeavor, Kondiles teaches and suggest determine when memory utilization exceeds a utilization threshold for a threshold period of time; and detect the fault condition when the memory utilization exceeds the utilization threshold for the threshold period of time ([0369]; [0377]; teaches determining storage utilization exceeds a threshold for a certain interval for detecting failure).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to determining storage utilization exceeds a threshold for a certain interval for detecting failure as taught by Kondiles with the method and apparatus for determining status of UDRs as disclosed by Kuravangi, as modified by Judd, for the purpose of monitoring the state of network nodes and storage utilization, as suggested by Kondiles.
Claims 9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Kuravangi-Thammaiah et al. (hereinafter Kuravangi) (U.S. Patent Application Publication # 2024/0323092 A1) in view of Judd (U.S. Patent Application Publication # 2016/0342588 A1), and further in view of Iglesias et al. (hereinafter Iglesias) (U.S. Patent Application Publication # 2022/0166695 A1).
Regarding claims 9 and 18, Kuravangi, as modified by Judd, discloses the network function comprises one of a Unified Data Management (UDM), an Access and Mobility Management Function (AMF), or a Policy Control Function (PCF), and determining status of UDRs and updating the topology based on the status of the UDRs, but may not explicitly disclose determine when Key Performance Indicators (KPIs) for the secondary UDR node exceed a KPI threshold; when the KPIs exceed the KPI threshold, the network function determining to failover from the secondary UDR node to the primary UDR node.
Nonetheless, in the same field of endeavor, Iglesias teaches and suggest when Key Performance Indicators (KPIs) for the secondary UDR node exceed a KPI threshold; when the KPIs exceed the KPI threshold, the network function determining to failover from the secondary UDR node to the primary UDR node ([0018]; “…failover conditions may include, for example, threshold values associated with one or more particular KPIs or metrics, such as a maximum latency threshold, a minimum throughput threshold, a maximum call failure rate threshold, a minimum call success rate threshold, and/or other suitable types of values, metrics, KPIs…”; [0019]; teaches determining failover condition including determining KPI exceeding thresholds).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to determining failover condition including determining KPI exceeding thresholds as taught by Iglesias with the method and apparatus for determining status of UDRs as disclosed by Kuravangi, as modified by Judd, for the purpose of monitoring the state of network nodes and failover conditions, as suggested by Iglesias.
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicant’s disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SUK JIN KANG whose telephone number is (571) 270-1771. The examiner can normally be reached on Monday-Friday 8am-5pm.
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, Chirag Shah can be reached on (571) 272-3144. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
Any inquiry of a general nature or relating to the status of this application or proceeding should be directed to the receptionist/customer service whose telephone number is (571) 272-2600.
/Suk Jin Kang/
Examiner, Art Unit 2477
December 23, 2025