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 (IDS) submitted on 01/30/24 has been considered by the examiner.
Election/Restrictions
Applicant’s election without traverse of Invention Group l (i.e. corresponding to claims 57-66) in the reply filed on 03/09/26 is acknowledged.
Claims 67-77 are withdrawn from further consideration pursuant to 37 CFR 1.142(b) as being drawn to a nonelected Invention Group, there being no allowable generic or linking claim. Election was made without traverse in the reply filed on 03/09/26.
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 (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 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
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