DETAILED ACTION
Response to Amendment
The applicant has amended the following:
Claims: 62 have been amended.
Claims: 57-61 and 63-66 have not been amended.
Claims: 67-77 have been withdrawn.
Claims: 1-56 have been cancelled.
Response to Arguments
Applicant’s arguments filed 06/23/26 with regards to claims 57-66 have been fully considered but they are not persuasive.
APPLICANT’S ARGUMENTS:
The applicant argues that … Bojeryd does not cure the deficiency. Bojeryd describes a different mechanism in which a network element, such as an MME, receives a paging request or tracking area update request, derives information identifying a first register, determines a second register for the UE, compares the first-register information with the second-register information, and, if the comparison indicates a mismatch, delivers a location update request to the second register. The indication relied upon by the Office Action is an indication of the mismatch detected by the MME as an outcome of that comparison. Thus, Bojeryd's indication identifies a locally detected mismatch between register information and is included in a location update request to initiate modification of information in another register. That is not the claimed "first indication indicating that a reason for the registration request is potential data inconsistency." Claim 57 recites that the registration request itself includes an indication that the reason for that registration request is potential data inconsistency. Bojeryd does not disclose a registration request from a third network function to a first network function that includes such a reason indication. Nor does Bojeryd disclose a UDR/UDM restoration scenario in which a network function receives an indication of potential registration data inconsistency from a data repository and, in response to a later registration request having a potential-data-inconsistency reason indication, updates registration data at that repository. Bojeryd's mismatch indication is therefore not the claimed reason indication, and the combination of 3GPP and Bojeryd fails to teach or suggest the disputed limitation of claim 57. The proposed combination also lacks a sufficient technical rationale. 3GPP already defines specific UDR/UDM restoration signaling, including restart/recovery information and procedures by which network functions may trigger synchronization operations. Bojeryd addresses a different problem in a different architecture: correcting dual or incorrect VLR registration by having an MME compare register information and include a mismatch indication in a location update request to a VLR. The indication in Bojeryd is used because, absent that indication or a corresponding modification of location-area information, the VLR might not initiate the further update toward the HLR. That engineering purpose does not apply to the 3GPP UDR/UDM restoration procedure relied upon in the Office Action, where the alleged registration procedure, UDR recovery information, and synchronization behavior are already defined within the UDM/UDR/AMF service framework. Accordingly, Applicant respectfully requests withdrawal of the rejection of claim 57. The remaining dependent claims are patentable at least per the patentability of the independent claims from which they depend. Therefore, the rejection of claims 57-66 should be withdrawn (See Pages 7-8 of Applicant’s Arguments filed on 06/23/26).
EXAMINER’S RESPONSE:
The examiner respectfully disagrees. Contrary to the applicant’s arguments the combination of 3GPP in view of Bojeryd together as a whole does disclose the applicant’s claimed invention as will be apparent in the following explanations provided below.
To begin with, the applicant’s arguments against Bojeryd for failing to disclose the claimed limitation of “the request comprises a first indication indicating that a reason for the request is potential data inconsistency”, appears to be directed towards reasons that Bojeryd fails to disclose each and every limitation of the claimed invention (i.e. arguments reciting “Bojeryd does not disclose a registration request from a third network function to a first network function that includes such a reason indication. Nor does Bojeryd disclose a UDR/UDM restoration scenario in which a network function receives an indication of potential registration data inconsistency from a data repository and, in response to a later registration request having a potential-data-inconsistency reason indication, updates registration data at that repository. Bojeryd's mismatch indication is therefore not the claimed reason indication, and the combination of 3GPP and Bojeryd fails to teach or suggest the disputed limitation of claim 57. … Bojeryd addresses a different problem in a different architecture: correcting dual or incorrect VLR registration by having an MME compare register information and include a mismatch indication in a location update request to a VLR. The indication in Bojeryd is used because, absent that indication or a corresponding modification of location-area information, the VLR might not initiate the further update toward the HLR. That engineering purpose does not apply to the 3GPP UDR/UDM restoration procedure relied upon in the Office Action, where the alleged registration procedure, UDR recovery information, and synchronization behavior are already defined within the UDM/UDR/AMF service framework”) and are made against the references alone without considering what the combination of the cited references together as a whole would teach and as such, the applicant’s arguments are against the references individually and are therefore not based on the combination of the references as a whole.
In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Where a rejection of a claim is based on two or more references, a reply that is limited to what a subset of the applied references teaches or fails to teach, or that fails to address the combined teaching of the applied references may be considered to be an argument that attacks the reference(s) individually (see MPEP 2145, Section lV).
The applicant’s arguments appears to be arguing that a single reference is required to show the entire claimed invention which is incorrect, as the guidelines for obviousness clearly indicates that a single reference is not required to disclose each and every element in the applicant’s claimed invention as can be seen in the highlighted portions of MPEP 2143, Section A, Example 2 that recites “Example 2: The claimed invention in Ruiz v. A.B. Chance Co., 357 F.3d 1270, 69 USPQ2d 1686 (Fed. Cir. 2004) was directed to a system which employs a screw anchor for underpinning existing foundations and a metal bracket to transfer the building load onto the screw anchor. The prior art (Fuller) used screw anchors for underpinning existing structural foundations. Fuller used a concrete haunch to transfer the load of the foundation to the screw anchor. The prior art (Gregory) used a push pier for underpinning existing structural foundations. Gregory taught a method of transferring load using a bracket, wherein a metal bracket transfers the foundation load to the push pier. The pier is driven into the ground to support the load. Neither reference showed the two elements of the claimed invention – screw anchor and metal bracket – used together. The court found that “artisans knew that a foundation underpinning system requires a means of connecting the foundation to the load-bearing member” … The nature of the problem to be solved – underpinning unstable foundations – as well as the need to connect the member to the foundation to accomplish this goal, would have led one of ordinary skill in the art to choose an appropriate load bearing member and a compatible attachment. Therefore, it would have been obvious to use a metal bracket (as shown in Gregory) in combination with the screw anchor (as shown in Fuller) to underpin unstable foundations”.
As can be seen from MPEP 2143, Section A, Example 2 above, the claimed invention is directed towards “a screw anchor for underpinning existing foundations and a metal bracket to transfer the building load onto the screw anchor”.
The primary reference Fuller discloses only a portion of the applicant’s claimed invention by disclosing the first component (i.e. “a screw anchor”) and a corresponding function (i.e. “for underpinning existing foundations and to transfer the building load onto the screw anchor”) and a second component (i.e. “concrete haunch”) corresponding to a second function (i.e. “to transfer the load of the foundation”) but fails to disclose the portion reciting “and a metal bracket to transfer the building load onto the screw anchor”.
The secondary reference Gregory was utilized to remedy the missing aspects of Fuller and similarly only discloses a portion of the applicant’s claimed invention by disclosing an alternative compatible second component (i.e. “a metal bracket”) and a similar corresponding function (i.e. “for underpinning existing foundations” and “to transfer the building load”).
Even though neither of the Fuller and Gregory reference discloses any of the claimed limitations in full, the court still found the combination to be obvious and concluded that given the nature of the problem to be solved or similar corresponding function, one of ordinary skill in the art would choose an appropriate and compatible component.
The examiner also directs the applicant to the following guidelines for obviousness set forth by the MPEP 2143 as seen below:
MPEP 2143, Section l. EXAMPLES OF RATIONALES that recites “Examples of rationales that may support a conclusion of obviousness include: (A) Combining prior art elements according to known methods to yield predictable results; (B) Simple substitution of one known element for another to obtain predictable results; (C) Use of known technique to improve similar devices (methods, or products) in the same way; (D) Applying a known technique to a known device (method, or product) ready for improvement to yield predictable results; (E) "Obvious to try" – choosing from a finite number of identified, predictable solutions, with a reasonable expectation of success; (F) Known work in one field of endeavor may prompt variations of it for use in either the same field or a different one based on design incentives or other market forces if the variations are predictable to one of ordinary skill in the art; G) Some teaching, suggestion, or motivation in the prior art that would have led one of ordinary skill to modify the prior art reference or to combine prior art reference teachings to arrive at the claimed invention. … It is important for Office personnel to recognize that when they do choose to formulate an obviousness rejection using one of the rationales suggested by the Supreme Court in KSR and discussed herein, they are to adhere to the guidance provided regarding the necessary factual findings. It remains Office policy that appropriate factual findings are required in order to apply the enumerated rationales properly. The subsections below include discussions of each rationale along with examples illustrating how the cited rationales may be used to support a finding of obviousness. Some examples use the facts of pre-KSR cases to show how the rationales suggested by the Court in KSR may be used to support a finding of obviousness. The cases cited (from which the facts were derived) may not necessarily stand for the proposition that the particular rationale is the basis for the court’s holding of obviousness, but they do illustrate consistency of past decisions with the lines of reasoning laid out in KSR. Other examples are post-KSR decisions that show how the Federal Circuit has applied the principles of KSR. Cases are included that illustrate findings of obviousness as well as nonobviousness. Note that, in some instances, a single case is used in different subsections to illustrate the use of more than one rationale to support a finding of obviousness. It will often be the case that, once the Graham inquiries have been satisfactorily resolved, a conclusion of obviousness may be supported by more than one line of reasoning”.
MPEP 2143, Section l, Subsection B. Simple Substitution of One Known Element for Another To Obtain Predictable Results that recites “To reject a claim based on this rationale, Office personnel must resolve the Graham factual inquiries. Then, Office personnel must articulate the following: (1) a finding that the prior art contained a device (method, product, etc.) which differed from the claimed device by the substitution of some components (step, element, etc.) with other components; (2) a finding that the substituted components and their functions were known in the art; (3) a finding that one of ordinary skill in the art could have substituted one known element for another, and the results of the substitution would have been predictable; and (4) whatever additional findings based on the Graham factual inquiries may be necessary, in view of the facts of the case under consideration, to explain a conclusion of obviousness. The rationale to support a conclusion that the claim would have been obvious is that the substitution of one known element for another yields predictable results to one of ordinary skill in the art. If any of these findings cannot be made, then this rationale cannot be used to support a conclusion that the claim would have been obvious to one of ordinary skill in the art. … Example 3: The fact pattern in Ruiz v. AB Chance Co., 357 F.3d 1270, 69 USPQ2d 1686 (Fed. Cir. 2004) is set forth above in Example 2 in subsection I.A., above. The prior art showed differing load-bearing members and differing means of attaching the foundation to the member. Therefore, it would have been obvious to one of ordinary skill in the art to substitute the metal bracket taught in Gregory for Fuller’s concrete haunch for the predictable result of transferring the load.”
MPEP 2143.01 Suggestion or Motivation To Modify the References that recites “Obviousness can be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so. In re Kahn, 441 F.3d 977, 986, 78 USPQ2d 1329, 1335 (Fed. Cir. 2006) (discussing rationale underlying the motivation-suggestion-teaching test as a guard against using hindsight in an obviousness analysis). Axonics, Inc. v. Medtronic, Inc., 73 F.4th 950, 957-58, 2023 USPQ2d 795 (Fed. Cir. 2023) (the court found an erroneous framing of the motivation inquiry led to an incorrect conclusion of nonobviousness). A "motivation to combine may be found explicitly or implicitly in market forces; design incentives; the ‘interrelated teachings of multiple patents’; ‘any need or problem known in the field of endeavor at the time of invention and addressed by the patent’; and the background knowledge, creativity, and common sense of the person of ordinary skill." Zup v. Nash Mfg., 896 F.3d 1365, 1371, 127 USPQ2d 1423, 1427 (Fed. Cir. 2018) (quoting Plantronics, Inc. v. Aliph, Inc., 724 F.3d 1343, 1354 [107 USPQ2d 1706] (Fed. Cir. 2013) (citing Perfect Web Techs., Inc. v. InfoUSA, Inc., 587 F.3d 1324, 1328 [92 USPQ2d 1849] (Fed. Cir. 2009) (quoting KSR, 550 U.S. at 418-21)).”
Therefore based on the guidelines for obviousness set forth by the MPEP as indicated above, one of ordinary skill in the art would recognize the following:
1. a single prior art reference need not disclose each and every limitation of the claimed invention alone and may only disclose portions thereof.
2. substituting comparable elements performing similar functionalities has been determined to be obvious by the courts.
3. there are a number of rationales that can be utilized to determining a finding of obviousness when performing a combination of different prior art references.
4. said motivation and rationale to combine different prior art references may be explicit or implicit and may be based on the background knowledge, creativity and common sense of the person of ordinary skill.
Based on the guidelines for obviousness set forth by the MPEP above and applied to the current combination of 3GPP in view of Bojeryd, it has been shown that:
The primary reference 3GPP discloses a mobility management entity AMF component that performs a function of sending a registration request to update information that includes an indication for the reason for the registration request (i.e. 3GPP Page 30, Lines 1-4 & 3GPP, Page 16, Section 6.5.2) and the primary reference 3GPP also discloses that communication between the UDR and serving NF AMF are always via UDM and that the serving NF are made aware when there is a potential inconsistency of profiles (i.e. 3GPP Page 8, Section 4.1) and the missing aspects of 3GPP is directed towards failing to explicitly recite that said indication for the reason for the registration request includes a reason that indicates potential data inconsistency corresponding to the claimed limitations reciting that “the indication for the reason indicates a potential data inconsistency.”
The secondary reference Bojeryd was utilized to remedy the missing aspects of 3GPP by disclosing a similar mobility management entity MME component that performs a similar function of sending a registration request to update information that includes an alternative comparable indication for the reason for the registration request indicating a mismatch (i.e. reads on “data inconsistency”) between information (i.e. Bojeryd, [0022]).
Therefore, given the similarities between components performing the same functions, one of ordinary skill in the art would reasonably conclude that the primary reference 3GPP may be modified with the teachings of the secondary reference Bojeryd to substitute or apply the known technique of utilizing an indication indicating a mismatch between information as the reason for the indication of the registration request of the invention of 3GPP and is a matter of alternative design such a rationale for said combination has already been indicated by the examiner in pages 8-9 of the Office Action filed on 04/13/26.
Therefore, the argued limitations read upon the cited references or are written broad such that they read upon the cited references, as follows:
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 57-66 is/are rejected under 35 U.S.C. 103 as being unpatentable over NPL Document “3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Study on Restoration of profiles related to UDR (Release 17)” (3GPP TR 29.821 V0.4.0 (2021-05) herein after referenced as 3GPP) in view of BOJERYD (US Patent Publication 2013/0244646 herein after referenced as Bojeryd).
Regarding claim 57, 3GPP discloses:
A method in a first network function for synchronizing data at a second network function, the method comprising: (3GPP, Page 16, Section 6.5.2 discloses when the UDM (i.e. reads on a first network function) receives the first new request from the NF service consumers e.g. AMF / SMSF / SMF / NEF, the UDM may include the UDR recovery indication, the recovery time of the UDR, the impacted user identifier ranges e.g. SUPI ranges in a response header to NF service consumers, the NF service consumers may trigger data synchronization (i.e. reads on for synchronizing data) operation related to the users indicated in the response e.g. AMF updates the registration and get the UE subscription via UDM again according to local policy; 3GPP, Page 7, Section 1 discloses Clarify the necessity on defining procedures for 5GC to allow NFs, e.g. AMF, SMF, SMSF, NEF, PCF, AUSF to trigger correction and synchronization of temporary data (i.e. reads on synchronizing data) within the UDR (i.e. reads on at a second network function) in case any corruption, loss, or inconsistency of data in UDR takes place, along with how NFs detect such case).
receiving, from the second network function, an indication of potential registration data inconsistency associated with one or more wireless devices; (3GPP Page 8, Section 4.1 discloses All communication between UDR (i.e. reads on from the second network function) and serving NFs, e.g. AMF, SMF and SMSF, AUSF are always via UDM (i.e. reads on receiving) and Serving NFs shall be made aware when there is a potential inconsistency of profiles (i.e. reads on an indication of potential registration data inconsistency associated with one or more wireless devices) with UDR and the profiles within themselves; 3GPP Page 18, Section 6.5.4 discloses AMF/SMF/SMSF/NEF: - Support receiving the UDR status data indicated by the UDM in HTTP header in response message and triggering the operations related to the data synchronization for impacted users (i.e. reads on associated with one or more wireless devices); 3GPP Page 21, Section 6.7.2.1 discloses Step 1.When UDR fails and restarts after reloading data from its back-up, the UDR sends its front-end i.e. UDM, PCF, or NEF a "UDR recovery message". This message contains a "scope" that this failure impacts on. Step 2. The frond-end reformats the message, names it as e.g. "UDM recovery message", and forwards it to NF that has accessed the front-end before. Step 3.The NF, taking into account the "scope" and local information, identifies profiles therein that require synchronization. The NF further identifies procedures that the NF needs to invoke for synchronization of each of those profiles; 3GPP Page 11, Section 6.1.2.3 discloses When the UDR fails and restarts after reloading data from its back-up, the UDR sends Nnrf_NFManagement_NFUpdate to NRF, setting the recovery time. Triggered by the change of the recovery time, the NRF sends Nnrf_NFManagement_NFStatusNotify to AMFs to notify the status of this restarted UDR. This causes each AMF to mark "Location Information Not Confirmed in UDR" for each UE context, if the UE context is associated with this restarted UDR and if the UE context has stored a registration time indicating the AMF registered to the UDR before the recovery time; 3GPP Page 29, Section 6.10.1 discloses The solution describes how AMF/SMSF and UDM/UDR can avoid overwriting UE's latest UECM data into UDR with UECM data from old AMF/SMSF.).
receiving a registration request for a first wireless device from a third network function, (3GPP Page 12, Section 6.1.2.4 discloses At the Registration procedure or after detection of any activity e.g. either signalling or data for a marked UE (i.e. reads on for a first wireless device), the AMF (i.e. reads on from a third network function) performs Nudm_UECM_Registration (i.e. reads on receiving a registration request) via UDM to UDR).
wherein the registration request comprises a first indication indicating that a reason for the registration request (3GPP Page 30, Lines 1-4 discloses When an AMF or an SMSF performs Nudm_UECM_Rcgistration (i.e. reads on wherein the registration request comprises and reads on and responsive to receiving the registration request) procedure due to UDR/UDM Restart notification, includes a flag (i.e. reads on a first indication) e.g. UdrRestartInd to indicate to UDM that the procedure is being performed due to a re-start notification (i.e. reads on indicating that a reason for the registration request) and UDM subsequently stores (i.e. reads on updating the registration data) the same in UDR (i.e. reads on at the second network function). If UDR has already been updated with UECM data "without" the re-start indication, it rejects the update; 3GPP, Page 16, Section 6.5.2 discloses when the UDM receives the first new request from the NF service consumers e.g. AMF / SMSF / SMF / NEF, the UDM may include the UDR recovery indication, the recovery time of the UDR, the impacted user identifier ranges e.g. SUPI ranges in a response header to NF service consumers, the NF service consumers may trigger data synchronization operation related to the users indicated in the response e.g. AMF updates the registration and get the UE subscription via UDM again according to local policy).
3GPP discloses informing network functions of potential data inconsistencies resulting in a network function sending a request to update information that includes a reason for the request but fails to explicitly recite that said reason indicates it being due to potential data inconsistencies and therefore fails to disclose “the request comprises a first indication indicating that a reason for the request is potential data inconsistency”.
In a related field of endeavor, Bojeryd discloses:
the request comprises a first indication indicating that a reason for the request is potential data inconsistency (Bojeryd, [0022] discloses The network element may be configured to request the initiation of the modification of information in a third register by delivering a location update request to the second register. Further, the network element may be configured to add an indication (i.e. reads on a first indication) of the mismatch between information (i.e. reads on indicating that a reason for the request is potential data inconsistency) compared to the location update request (i.e. reads on the request comprises); Bojeryd, [0048] discloses the MME 204 is configured to deliver 406 a location update request 406 to the second register 403, which is the correct VLR for the UE 103. The location update request also comprises an identifier indicating that the MME 204 has recognized that there exists wrong VLR information in the network into which the UE 103 is associated to. The correct VLR 403 in response to the location update request and the indicator of the wrong VLR 402 is configured to deliver an update location message 407 to the HLR 105 being the master subscriber information database in the network. As the HLR 105 receives the update location message 407 from the correct VLR 403 the HLR 105 is configured to remove information on any wrong VLR 402 in the database and store the information with the information on the correct VLR 403).
Therefore, at the time before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify the invention of 3GPP to incorporate the teachings of Bojeryd for the purpose of providing the system with a means to inform the system of the specific reason for requesting the update to be data inconsistency or mismatch (Bojeryd, [0022]) and for the purpose of making the system more dynamic and adaptable by providing the system with added functionalities and various different alternatives in design, thereby allowing the system to handle a number of various different combination of specific design structure and scenarios and preventing the system from being limited to a single specific design structure and scenario and furthermore, one of ordinary skill in the art would recognize based on the guidelines to rationales supporting a conclusion of obviousness seen on MPEP 2143, that the modification would involve use of a simple substitution of one known element and base device (i.e. performing a process of a mobility management entity sending a request to update information that includes a reason for the request as taught by 3GPP) with another known element and comparable device utilizing a known technique (i.e. performing a process of a mobility management entity sending a request to update information that includes a reason for the request, wherein the reason indicates an inconsistency or mismatch of the information as taught by Bojeryd) to improve the similar devices in the same way and to obtain the predictable result of the system performing a process of a mobility management entity sending a request to update information that includes a reason for the request (i.e. as taught by both 3GPP & Bojeryd) and is dependent upon the specific intended use, design incentives, needs and requirements (i.e. such as due to teachings of a known standard, current technology, conservation of resources, personal preferences, economic considerations, etc.) of the user and the system as has been established in MPEP 2144.04.
Regarding claim 58, 3GPP in view of Bojeryd discloses:
The method as claimed in claim 57 further comprising: (see claim 57).
notifying one or more fourth network functions of the potential registration data inconsistency for the one or more wireless devices (3GPP Page 8, Section 4.1 discloses All communication between UDR and serving NFs, e.g. AMF, SMF and SMSF, AUSF are always via UDM and Serving NFs shall be made aware when there is a potential inconsistency of profiles with UDR and the profiles within themselves; 3GPP, Page 16, Section 6.5.2 discloses when the UDM receives the first new request from the NF service consumers e.g. AMF / SMSF / SMF / NEF, the UDM may include the UDR recovery indication, the recovery time of the UDR, the impacted user identifier ranges e.g. SUPI ranges in a response header to NF service consumers, the NF service consumers may trigger data synchronization operation related to the users indicated in the response e.g. AMF updates the registration and get the UE subscription via UDM again according to local policy; 3GPP Page 18, Section 6.5.4 discloses NRF: - Support indicating partial update indicator in the Nnrf_NFManagement_NFUpdate service operation and Notify the partial update indicator to the NFs which subscribed to the notify. AMF/SMF/SMSF/NEF: - Support receiving the UDR status data indicated by the UDM in HTTP header in response message and triggering the operations related to the data synchronization for impacted users).
Regarding claim 59, 3GPP in view of Bojeryd discloses:
The method as claimed in claim 58 (see claim 58).
wherein the one or more fourth network functions each comprise a Network Exposure Function (3GPP, Page 16, Section 6.5.2 discloses when the UDM receives the first new request from the NF service consumers e.g. AMF / SMSF / SMF / NEF, the UDM may include the UDR recovery indication, the recovery time of the UDR, the impacted user identifier ranges e.g. SUPI ranges in a response header to NF service consumers, the NF service consumers may trigger data synchronization operation related to the users indicated in the response e.g. AMF updates the registration and get the UE subscription via UDM again according to local policy; 3GPP Page 8, Section 4.1 discloses All communication between UDR and serving NFs, e.g. AMF, SMF and SMSF, AUSF are always via UDM and Serving NFs shall be made aware when there is a potential inconsistency of profiles with UDR and the profiles within themselves).
Regarding claim 60, 3GPP in view of Bojeryd discloses:
The method as claimed in claim 58 further comprising: (see claim 58).
discovering the one or more fourth network functions from a fifth network function, wherein the one or more fourth network functions are registered at the fifth network function as potential registration data inconsistency endpoints (3GPP, Page 17, Section 6.5.3 discloses When the NRF receives the Nnrf_NFManage_NFUpdate request from the UDR, the NRF shall notify the UDM of the changes if the UDM subscribed to the NFStatusNotify of this UDR, the NRF also include the received partial update indicator in the notification, but NRF won't store the partial update indicator as part of UDR NF profile. 4. When the UDM receives Nurf_NFManage_NFStatusNotify, if partial update indicator is received in the request and set to true, the UDM shall compare the received NF status data with the UDR NF profile locally stored, and then recognize out which data is changed. If the recovery time is changed, the UDM will store received recovery time and user identifier ranges e.g. SUPI ranges and/or GPSI ranges whose profile data is available in this UDR, if the user identifier ranges that are available in the UDR are changed, the UDM will recognize which user identifier ranges are changed e.g. which user data ranges are removed and which are added and store the changed user identifier ranges. 5. After step 4. when the UDM receives the first new request any request for any user from the NF service consumers e.g. AMF/SMSF/SMF/NEF, the UDM may include the UDR recovery indication, the recovery time of the UDR, the impacted user identifier ranges e.g. SUPI ranges in a response header to NF service consumers; 3GPP Page 18, Section 6.5.4 discloses NRF: - Support indicating partial update indicator in the Nnrf_NFManagement_NFUpdate service operation and Notify the partial update indicator to the NFs which subscribed to the notify. AMF/SMF/SMSF/NEF: - Support receiving the UDR status data indicated by the UDM in HTTP header in response message and triggering the operations related to the data synchronization for impacted users).
Regarding claim 61, 3GPP in view of Bojeryd discloses:
The method as claimed in claim 60 (see claim 60).
wherein the fifth network function comprises a network repository function, NRF (3GPP, Page 17, Section 6.5.3 discloses When the NRF receives the Nnrf_NFManage_NFUpdate request from the UDR, the NRF shall notify the UDM of the changes if the UDM subscribed to the NFStatusNotify of this UDR, the NRF also include the received partial update indicator in the notification, but NRF won't store the partial update indicator as part of UDR NF profile. 4. When the UDM receives Nurf_NFManage_NFStatusNotify, if partial update indicator is received in the request and set to true, the UDM shall compare the received NF status data with the UDR NF profile locally stored, and then recognize out which data is changed. If the recovery time is changed, the UDM will store received recovery time and user identifier ranges e.g. SUPI ranges and/or GPSI ranges whose profile data is available in this UDR, if the user identifier ranges that are available in the UDR are changed, the UDM will recognize which user identifier ranges are changed e.g. which user data ranges are removed and which are added and store the changed user identifier ranges. 5. After step 4. when the UDM receives the first new request any request for any user from the NF service consumers e.g. AMF/SMSF/SMF/NEF, the UDM may include the UDR recovery indication, the recovery time of the UDR, the impacted user identifier ranges e.g. SUPI ranges in a response header to NF service consumers; 3GPP Page 18, Section 6.5.4 discloses NRF: - Support indicating partial update indicator in the Nnrf_NFManagement_NFUpdate service operation and Notify the partial update indicator to the NFs which subscribed to the notify. AMF/SMF/SMSF/NEF: - Support receiving the UDR status data indicated by the UDM in HTTP header in response message and triggering the operations related to the data synchronization for impacted users).
Regarding claim 62, 3GPP in view of Bojeryd discloses:
The method as claimed in claim 57 further comprising: (see claim 57).
notifying one or more third network functions of the potential registration data inconsistency for the one or more wireless devices, wherein the one or more third network functions comprise the third network function from which the registration request for the first wireless device is received, wherein the first wireless device is among the one or more wireless devices, and wherein the registration request is received from the third network function responsive to the notifying (3GPP Page 8, Section 4.1 discloses All communication between UDR and serving NFs, e.g. AMF, SMF and SMSF, AUSF are always via UDM and Serving NFs shall be made aware when there is a potential inconsistency of profiles with UDR and the profiles within themselves; 3GPP Page 18, Section 6.5.4 discloses AMF/SMF/SMSF/NEF: - Support receiving the UDR status data indicated by the UDM in HTTP header in response message and triggering the operations related to the data synchronization for impacted users; 3GPP Page 12, Section 6.1.2.4 discloses At the Registration procedure or after detection of any activity e.g. either signalling or data for a marked UE, the AMF performs Nudm_UECM_Registration via UDM to UDR; 3GPP, Page 16, Section 6.5.2 discloses when the UDM receives the first new request from the NF service consumers e.g. AMF / SMSF / SMF / NEF, the UDM may include the UDR recovery indication, the recovery time of the UDR, the impacted user identifier ranges e.g. SUPI ranges in a response header to NF service consumers, the NF service consumers may trigger data synchronization operation related to the users indicated in the response e.g. AMF updates the registration and get the UE subscription via UDM again according to local policy).
Regarding claim 63, 3GPP in view of Bojeryd discloses:
The method as claimed in claim 62 (see claim 62).
wherein the one or more third network functions each comprise an Access and Mobility Management Function, AMF (3GPP Page 8, Section 4.1 discloses All communication between UDR and serving NFs, e.g. AMF, SMF and SMSF, AUSF are always via UDM and Serving NFs shall be made aware when there is a potential inconsistency of profiles with UDR and the profiles within themselves; 3GPP Page 18, Section 6.5.4 discloses AMF/SMF/SMSF/NEF: - Support receiving the UDR status data indicated by the UDM in HTTP header in response message and triggering the operations related to the data synchronization for impacted users).
Regarding claim 64, 3GPP in view of Bojeryd discloses:
The method as claimed in claim 62 further comprising: (see claim 62).
discovering the one or more third network functions from a fifth network function endpoints (3GPP, Page 17, Section 6.5.3 discloses When the NRF receives the Nnrf_NFManage_NFUpdate request from the UDR, the NRF shall notify the UDM of the changes if the UDM subscribed to the NFStatusNotify of this UDR, the NRF also include the received partial update indicator in the notification, but NRF won't store the partial update indicator as part of UDR NF profile. 4. When the UDM receives Nurf_NFManage_NFStatusNotify, if partial update indicator is received in the request and set to true, the UDM shall compare the received NF status data with the UDR NF profile locally stored, and then recognize out which data is changed. If the recovery time is changed, the UDM will store received recovery time and user identifier ranges e.g. SUPI ranges and/or GPSI ranges whose profile data is available in this UDR, if the user identifier ranges that are available in the UDR are changed, the UDM will recognize which user identifier ranges are changed e.g. which user data ranges are removed and which are added and store the changed user identifier ranges. 5. After step 4. when the UDM receives the first new request any request for any user from the NF service consumers e.g. AMF/SMSF/SMF/NEF, the UDM may include the UDR recovery indication, the recovery time of the UDR, the impacted user identifier ranges e.g. SUPI ranges in a response header to NF service consumers; 3GPP Page 18, Section 6.5.4 discloses NRF: - Support indicating partial update indicator in the Nnrf_NFManagement_NFUpdate service operation and Notify the partial update indicator to the NFs which subscribed to the notify. AMF/SMF/SMSF/NEF: - Support receiving the UDR status data indicated by the UDM in HTTP header in response message and triggering the operations related to the data synchronization for impacted users).
Regarding claim 65, 3GPP in view of Bojeryd discloses:
The method as claimed in claim 57 further comprising (see claim 57).
registering, at a fifth network function, that the first network function is configured to receive potential inconsistent registration data notifications (3GPP, Page 17, Section 6.5.3 discloses When the NRF receives the Nnrf_NFManage_NFUpdate request from the UDR, the NRF shall notify the UDM of the changes if the UDM subscribed to the NFStatusNotify of this UDR, the NRF also include the received partial update indicator in the notification, but NRF won't store the partial update indicator as part of UDR NF profile. 4. When the UDM receives Nurf_NFManage_NFStatusNotify, if partial update indicator is received in the request and set to true, the UDM shall compare the received NF status data with the UDR NF profile locally stored, and then recognize out which data is changed. If the recovery time is changed, the UDM will store received recovery time and user identifier ranges e.g. SUPI ranges and/or GPSI ranges whose profile data is available in this UDR, if the user identifier ranges that are available in the UDR are changed, the UDM will recognize which user identifier ranges are changed e.g. which user data ranges are removed and which are added and store the changed user identifier ranges. 5. After step 4. when the UDM receives the first new request any request for any user from the NF service consumers e.g. AMF/SMSF/SMF/NEF, the UDM may include the UDR recovery indication, the recovery time of the UDR, the impacted user identifier ranges e.g. SUPI ranges in a response header to NF service consumers; 3GPP Page 18, Section 6.5.4 discloses NRF: - Support indicating partial update indicator in the Nnrf_NFManagement_NFUpdate service operation and Notify the partial update indicator to the NFs which subscribed to the notify. AMF/SMF/SMSF/NEF: - Support receiving the UDR status data indicated by the UDM in HTTP header in response message and triggering the operations related to the data synchronization for impacted users).
Regarding claim 66, 3GPP in view of Bojeryd discloses:
The method as claimed in claim 65 (see claim 65).
wherein the fifth network function comprises a network repository function, NRF, the first network function comprises a unified data management, UDM, and the second network function comprises a unified data repository, UDR (3GPP, Page 17, Section 6.5.3 discloses When the NRF receives the Nnrf_NFManage_NFUpdate request from the UDR, the NRF shall notify the UDM of the changes if the UDM subscribed to the NFStatusNotify of this UDR, the NRF also include the received partial update indicator in the notification, but NRF won't store the partial update indicator as part of UDR NF profile. 4. When the UDM receives Nurf_NFManage_NFStatusNotify, if partial update indicator is received in the request and set to true, the UDM shall compare the received NF status data with the UDR NF profile locally stored, and then recognize out which data is changed. If the recovery time is changed, the UDM will store received recovery time and user identifier ranges e.g. SUPI ranges and/or GPSI ranges whose profile data is available in this UDR, if the user identifier ranges that are available in the UDR are changed, the UDM will recognize which user identifier ranges are changed e.g. which user data ranges are removed and which are added and store the changed user identifier ranges. 5. After step 4. when the UDM receives the first new request any request for any user from the NF service consumers e.g. AMF/SMSF/SMF/NEF, the UDM may include the UDR recovery indication, the recovery time of the UDR, the impacted user identifier ranges e.g. SUPI ranges in a response header to NF service consumers).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL Y MAPA whose telephone number is (571)270-5540. The examiner can normally be reached Monday thru Thursday: 10 AM - 8 PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Anthony Addy can be reached at (571) 272 - 7795. 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.
/MICHAEL Y MAPA/Primary Examiner, Art Unit 2645
Prosecution Insights