DETAILED ACTION
Specification
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
The abstract is objected to because it is nearly identical in language and structure to claim 1 and is therefore interpreted to (a) not be in narrative form and/or (b) to use the form and legal phraseology often used in patent claims.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-4 and 11-14 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Kim et al (US 2020/0252837).
Regarding claim 1: Kim discloses a method comprising:
detecting, at a network function of a core network, a handover of a connection between a user equipment (UE) device and the core network from a first access network to a second access network (disclosed throughout; see step S221 of Figure 2, for example, which discloses detecting an event at a network function (the AMF 207); the event can be “a change in the terminal location, a change in the roaming state, reachability, availability after downlink data failure, and the like” [0039] or “an event for the access type or an event for the location and access type of the terminal” [0054]; as indicated in [0067], the AMF may deterring “the access type change between non3gpp and 3gpp to be a corresponding event condition”; see also [0068] and [0069]; this change between non3gpp access and 3gpp access is a handover from a first access network to a second access network);
issuing, at the network function to an application programming interface (API) of the core network, a handover notification associated with the detected handover (disclosed throughout; as indicated in [0049], the AMF provides APIs to provide functions to other network functions (such as location reporting); the notification of an event such as the handover from a non3gpp to/from a 3gpp access network is also provided via an API in the AMF; see also [0079], for example, which discloses “a third-party application service may make a request to the 5G system for using the MEC, which may use an API provided by the 5G system to the third-party application service through the NEF”; the event detection associated with the access type change disclosed in [0067], for example, is a handover notification);
determining, at the API, one or more service update messages to another one or more network functions of the core network, wherein each of said one or more service update messages relates to a respective one or more application features at one or more of the UE device and the core network, and is associated with a change from the first access network to the second access network (disclosed throughout; as indicated in [0070], when the AMF detects the handover/event, the AMF notifies the AF (either directly or via the NEF), which is a service update message; the message is sent to an application function and thus relates to one or more application features and is associated with a change from the first access network to the second access network (the result of the event including the current location and/or access type is indicated in the message); see [0022], for example, which provides some examples of how the AF/third-party AS uses changes to the access type to adjust application features to, for example, improve voice quality or save data fees for the terminal); and
issuing, at the API, the determined one or more service update messages to the other one or more network functions to facilitate the respective one or more application features at the one or more of the UE device and the core network in correspondence with the detected handover (disclosed throughout; as indicated in [0070], when the AMF detects the handover/event, the AMF notifies the AF (either directly or via the NEF), which is a service update message; the message is sent to an application function and thus relates to one or more application features and is associated with a change from the first access network to the second access network (the result of the event including the current location and/or access type is indicated in the message); see [0022], for example, which provides some examples of how the AF/third-party AS uses changes to the access type to adjust application features to, for example, improve voice quality or save data fees for the terminal).
Regarding claim 11: Kim discloses a system, comprising:
an interface adapted to communicate with one or more user equipment (UE) devices (disclosed throughout; see transceiver 510 of Figure 5 and [0122], for example);
a processor (disclosed throughout; see controller 520 of Figure 5 and [0123]-[0124], for example); and
a non-transitory computer-readable memory operatively connected to the processor and having stored thereon machine-readable instructions that cause, when executed, the processor to (disclosed throughout; see storage unit 530 of Figure 5 and [0033], for example):
detect, at a network function of a core network, a handover of a connection between a user equipment (UE) device and the core network from a first access network to a second access network (disclosed throughout; see step S221 of Figure 2, for example, which discloses detecting an event at a network function (the AMF 207); the event can be “a change in the terminal location, a change in the roaming state, reachability, availability after downlink data failure, and the like” [0039] or “an event for the access type or an event for the location and access type of the terminal” [0054]; as indicated in [0067], the AMF may deterring “the access type change between non3gpp and 3gpp to be a corresponding event condition”; see also [0068] and [0069]; this change between non3gpp access and 3gpp access is a handover from a first access network to a second access network);
issue, at the network function to an application programming interface (API) of the core network, a handover notification associated with the detected handover (disclosed throughout; as indicated in [0049], the AMF provides APIs to provide functions to other network functions (such as location reporting); the notification of an event such as the handover from a non3gpp to/from a 3gpp access network is also provided via an API in the AMF; see also [0079], for example, which discloses “a third-party application service may make a request to the 5G system for using the MEC, which may use an API provided by the 5G system to the third-party application service through the NEF”; the event detection associated with the access type change disclosed in [0067], for example, is a handover notification);
determine, at the API, one or more service update messages to another one or more network functions of the core network, wherein each of said one or more service update messages relates to a respective one or more application features at one or more of the UE device and the core network, and is associated with a change from the first access network to the second access network (disclosed throughout; as indicated in [0070], when the AMF detects the handover/event, the AMF notifies the AF (either directly or via the NEF), which is a service update message; the message is sent to an application function and thus relates to one or more application features and is associated with a change from the first access network to the second access network (the result of the event including the current location and/or access type is indicated in the message); see [0022], for example, which provides some examples of how the AF/third-party AS uses changes to the access type to adjust application features to, for example, improve voice quality or save data fees for the terminal); and
issue, at the API, the determined one or more service update messages to the other one or more network functions to facilitate the respective one or more application features at the one or more of the UE device and the core network in correspondence with the detected handover (disclosed throughout; as indicated in [0070], when the AMF detects the handover/event, the AMF notifies the AF (either directly or via the NEF), which is a service update message; the message is sent to an application function and thus relates to one or more application features and is associated with a change from the first access network to the second access network (the result of the event including the current location and/or access type is indicated in the message); see [0022], for example, which provides some examples of how the AF/third-party AS uses changes to the access type to adjust application features to, for example, improve voice quality or save data fees for the terminal).
Regarding claims 2 and 12: Kim discloses wherein the handover notification incorporates at least one information indicator on an application layer associated with the API, the at least one information indicator being selected from the group consisting of: a time of an event associated with the detected handover, a location of the event associated with the detected handover, a type of the handover, a direction of the handover, a Public Land Mobile Network (PLMN) identification (ID), a cell ID, an update counter, an initial attempt indicator for the handover or an update, and a handover attempt success indicator (disclosed throughout; see [0054], for example, which indicates that the event indicated in the handover notification may include “the location and access type of the terminal”; further, as indicated in [0067]-[0069], the event indicated in the handover notification may include the type of handover (whether the handover is from non3gpp to/from 3gpp and/or whether the handover is from a terminal connected through two access types and releasing one of the access types, etc.)).
Regarding claims 3 and 13: Kim discloses wherein the network function is an access and mobility management function (AMF) or a mobility management entity (MME) (see element 207 of Figure 2, for example), and the handover notification is issued to the API via a network exposure function (NEF) (see steps S223 and S225 of Figure 2 and [0070], for example, which show the handover notification is issued via an NEF (211)).
Regarding claims 4 and 14: Kim discloses wherein the another one or more respective network functions are selected from the group consisting of: a policy control function (PCF), a network function repository function (NRF), a session management function (SMF), a location management function (LMF), a gateway mobility location center (GMLC), a serving mobile location center (SMLC), a network exposure function (NEF), an application function (AF), a user plane function (UPF), and a network data analytics function (NWDAF) (disclosed throughout; see Figure 7, for example, which indicates that the another network function includes at least an application function (AF) – see element 213 of Figure 2).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 5-7 and 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Kim et al (US 2020/0252837) in view of Suxena (US 2019/0132903).
Regarding claims 5 and 15: Kim discloses the limitations of parent claims 1 and 11 as indicated above. Kim further discloses wherein at least one of the one or more application features relates to a UE device location service (LCS) (disclosed throughout; see [0054], for example, which indicates that the event indicated in the handover notification may include “the location and access type of the terminal”) and at least one of the one or more service update messages relates to a change from a first positioning determination scheme associated with the first access network to a second positioning determination scheme associated with the second access network (disclosed throughout; as indicated in [0067]-[0069], the event indicated in the handover notification may include the type of handover (whether the handover is from non3gpp to/from 3gpp and/or whether the handover is from a terminal connected through two access types and releasing one of the access types, etc.); the positioning determination scheme associated with a 3gpp access network is different from the positioning determination scheme associated with a non3gpp access network and thus the service update messages relate to a change in position determination schemes).
Kim does not explicitly disclose the limitation that the at least one service update message comprises a data request to a location management function (LMF) or a gateway mobility location center (GMLC). However, Suxena discloses “[w]hen the user calls E911, a gateway mobile location center (GMLC) system may cooperate with one or more other components of a mobile communications network to route the E911 call to a nearby public safety answering point (PSAP) based at least in part on location information of the UE from which the E911 call was placed” (disclosed throughout; see abstract, for example). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Kim to provide a service update message including the location information to a GMLC. The rationale for doing so would have been to ensure the latest location information is available to the GMLC in the event of the need for an emergency call as suggested by Suxena.
Regarding claims 6 and 16: Kim, modified, discloses the limitations of parent claims 5 and 15 as indicated above. Kim further discloses wherein the first access network comprises a wireless network conforming to a Wi-Fi standard protocol and the second access network comprises a radio access network conforming to a radio communication standard protocol (disclosed throughout; see [0067]-[0069], for example, which indicate that the event may correspond to a handover between a 3gpp access network and a non3gpp access network; as indicated in [0008], for example, the non3gpp access network may be a WiFi network). Kim does not explicitly disclose the limitations that the method further comprises: transmitting, at the API, location data received from the LMF or the GMLC to a public safety answering point (PSAP) for an ongoing emergency call that is initiated via the first access network. However, Suxena discloses that the GMLC may provide location information about the UE for routing the call to the nearest PSAP system (see [0033], for example). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Kim, modified to use the GMLC to transmit location information of the UE to a PSAP for an emergency call (that can be initiated via the first network). The rationale for doing so would have been to ensure the first responders are geographically relevant to the E911 caller as suggested by Suxena in [0001], for example.
Regarding claims 7 and 17: Kim, modified, discloses the limitations of parent claims 5 and 15 as indicated above. Kim further discloses wherein the first access network comprises a radio access network conforming to a radio communication standard protocol and the second access network comprises a wireless network conforming to a Wi-Fi standard protocol (disclosed throughout; see [0067]-[0069], for example, which indicate that the event may correspond to a handover between a 3gpp access network and a non3gpp access network; as indicated in [0008], for example, the non3gpp access network may be a WiFi network). Kim does not explicitly disclose the limitations that the method further comprises: transmitting, at the API, location data received from the LMF or the GMLC to a public safety answering point (PSAP) for an emergency call connected via the second access network. However, Suxena discloses that the GMLC may provide location information about the UE for routing the call to the nearest PSAP system (see [0033], for example). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Kim, modified to use the GMLC to transmit location information of the UE to a PSAP for an emergency call (that can be connected via the second network). The rationale for doing so would have been to ensure the first responders are geographically relevant to the E911 caller as suggested by Suxena in [0001], for example.
Claims 8, 9, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Kim et al (US 2020/0252837) in view of Yan et al (US 2023/0362620).
Regarding claims 8 and 18: Kim discloses the limitations of parent claims 1 and 11 as indicated above. Kim further discloses the limitations wherein at least one of the one or more application features relates to a (disclosed throughout; see Figure 3 and [0022] and [0096], for example, which disclose that the information related to the event is related to a voice application (such as voice over IP) and that the service updates include a message to the PCF regarding a request for changing network resources (such as the traffic steering request), which results in a change of network resources available to the voice application). Kim does not explicitly disclose the limitation that the application is a video display application of ongoing video being displayed at the UE device. However, Yan disclose that a PCF also governs network behavior for video services (see [0025], for example). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Kim to utilize the PCF for video display applications as suggested by Yan. The rationale for doing so would have been to enable the network in Kim to provide additional features to its subscribers such as video to improve the customer experience.
Regarding claims 9 and 19: Kim, modified, discloses the limitations of parent claims 8 and 18 as indicated above. Kim, modified, further discloses the limitations of issuing, at the API, at least one of a state change request and a time stamp request to the video display application (in Kim, modified, the traffic steering request (a state change request as the state of the ) is for the video display application).
Claims 10 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kim et al (US 2020/0252837) in view of Xiong et al (US 2025/0350942).
Regarding claims 10 and 20: Kim discloses the limitations of parent claims 1 and 11 as indicated above. Kim does not explicitly disclose the limitations of claims 10 and 20 that at least one of the one or more application features relates to one or more analytical processes associated with the core network, the one or more service update messages comprise analytical data for a network data analytics function (NWDAF), and the NWDAF comprises one or more of an analytics logical function (AnLF) and a model training logical function (MTLF). However, Xiong discloses adding an analytics function such as an NWDAF to the core network (see [0030], for example). Further, this NWDAF comprises an AnLF and an MTLF. Further, Xiong discloses that network exchanges AI/ML model-related information (analytical data) among numerous network functions (such as positioning accuracy information as suggested in [0039]). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Kim to include an NWDAF comprising one or more of an AnLF and an MLTF and to include information such as the location information in the service update messages to update the AI/ML model as suggested by Xiong. The rationale for doing so would have been to provide application layer and/or communications capabilities enhancements including position accuracy enhancements as suggested in Xiong in at least [0034].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Xiong (US 2023/0075987) discloses a method for notifying a QoS change.
Edge et al (US 2022/0007150) discloses a method for 5G location support using service based interfaces.
Guo et al (US 2020/0351724) discloses a method for efficient computing for application data in a mobile network.
Edge et al (US 2020/0053638) discloses a method for supporting unified location of a mobile device in a 5G network.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Robert C Scheibel whose telephone number is (571)272-3169. The examiner can normally be reached Monday-Friday 8:00 AM - 5:00 PM.
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, Hassan A Phillips can be reached at 571-272-3940. 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.
Robert C. Scheibel
Primary Examiner
Art Unit 2467
/Robert C Scheibel/Primary Examiner, Art Unit 2467 February 14, 2026