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 .
Response to Arguments
Applicant’s arguments, filed November 24, 2025, with respect to the rejection of claims 1-20 under 35 USC § 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new grounds of rejection is made in view of 35 USC § 103.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Yu et al. (US 20230336269 A1) in view of Yuan et al. (US 20200329403 A1).
Regarding claim 1, Yu et al. teaches a service server switching control method, performed by a service scheduling server, the method comprising: receiving a notification message from a core network accessed by a user equipment, the notification message being used for indicating that a user plane path of the user equipment is to be changed (Paragraph 172, 173, explicitly discloses core-network-originated notification signaling that indicates a required change of the UE user plane path due to anchor UPF handover), the notification message being transmitted by a session management function (SMF) and forwarded via an application function (AF) to the service scheduling server, the SMF being deployed within the core network (Paragraph 81, 101, 104, teaches SMF-generated control signaling delivered from the core network to application-side control entities via AF/NEF interfaces); rescheduling a service server for the user equipment in response to the notification message (Paragraph 172, 121, 191, explicitly teaches selecting a new target application server and relocating the UE service context in direct response to SMF-initiated notification signaling); and transmitting a confirmation message to the core network, the confirmation message being used for triggering the core network to change the user plane path of the user equipment (Paragraph 192, 193, 176, explicitly teaches confirmation and completion signaling indicating successful service relocation, which enables the core network to finalize user plane path switching), wherein in response to the confirmation message, the IP address of the rescheduled service server is configured as an offloading address in an intermediate user plane function (I-UPF) (Paragraph 92, 172, 247, teaches re-anchoring user traffic through a target UPF after confirmation of relocation, functionally corresponding to configuring the relocated service endpoint as an offloading destination in an intermediate UPF).
Yu et al. does not explicitly teach transmitting an Internet Protocol (IP) address of a rescheduled service server to the user equipment, to trigger the user equipment to switch a currently accessed service server to the rescheduled service server according to the IP address.
However, Yuan et al. teaches transmitting an Internet Protocol (IP) address of a rescheduled service server to the user equipment, to trigger the user equipment to switch a currently accessed service server to the rescheduled service server according to the IP address (Paragraph 63, 65, 116, 134, 137, explicitly teaches transmitting an IP address of a newly selected application server to the UE, which the UE then uses to switch service access to that server).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide transmitting an Internet Protocol (IP) address of a rescheduled service server to the user equipment, to trigger the user equipment to switch a currently accessed service server to the rescheduled service server according to the IP address as taught by Yuan et al. in the system of Yu et al., so that it would enable the UE to promptly and reliably redirect ongoing service traffic to the newly selected service server after core-network-initiated user plane path change and service server rescheduling, thereby maintaining service continuity and reducing interruption during service relocation.
Regarding claim 2, Yu et al. teaches generating a timer according to a duration desirable for a path change carried in the notification message, a duration specified by the timer being greater than or equal to the duration desirable for the path change; and transmitting the timer to the user equipment, to trigger the user equipment to switch to the rescheduled service server for access after the timer expires (Paragraph 122, 137, 152, 175, 248, teaches determining and enforcing a controlled waiting duration for path switching by explicitly delaying UE traffic transition until relocation completion, old-path packet termination, and buffering conditions are satisfied, which collectively correspond to generating a timing constraint at least as long as the desired path-change duration and signaling that constraint to govern when the UE effectively switches to the rescheduled service server).
Regarding claim 3, Yu et al. teaches rescheduling the service server comprises: selecting a target data network access point identifier from data network access point identifiers carried in the notification message (Paragraph 101, 172, 173, 122, These passages collectively teach selecting a target DNAI from available DNAIs signaled in control/notification messaging (e.g., relocation request/trigger messages) and using that selected DNAI to drive service server (AS/MEC) relocation and rescheduling decisions).
Regarding claim 4, Yu et al. teaches rescheduling the service server comprises: selecting a service server corresponding to the target data network access point identifier as the rescheduled service server (Paragraph 101, 122, 191, Together, these passages teach that when rescheduling a service server, the system selects (i.e., determines and uses) a target application/service server that corresponds to the target DNAI).
Regarding claim 5, Yu et al. teaches the confirmation message carries the target data network access point identifier, or carries the target data network access point identifier and the IP address of the rescheduled service server (Paragraph 101, 119, 133, The passages disclose a confirmation/trigger message that explicitly includes a target data network access point identifier).
Regarding claim 6, Yu et al. teaches rescheduling the service server comprises: selecting a service server deployed in a center network as the rescheduled service server in response to a determination that no data network access point identifier is carried in the notification message, the service server currently accessed by the user equipment being deployed in an edge network, and the center network corresponding to the edge network (Paragraph 93, 95, 100, 101, 172, These passages collectively teach that when a UE is currently served by an edge-deployed service (MEC/AS at a local data center) and a handover occurs such that no edge-specific access identifier is available or applicable, a centrally deployed service server (AS controlled by a central data center with SMF/PCF) is selected and used as the rescheduled service server corresponding to that edge network).
Regarding claim 7, Yu et al. teaches transmitting the IP address comprises: transmitting the IP address to the service server currently accessed by the user equipment, to forward the IP address to the user equipment via the service server currently accessed by the user equipment (Paragraph 81, 174, 101, 172–174, The passage teaches that an IP address of the UE is provided by the SMF and transmitted to the currently accessed service server (source AS/MEC), which forwards that IP address as UE-identifying information for continued communication with the UE via the service server currently accessed by the UE).
Regarding claim 8, Yu et al. teaches a service server switching control apparatus, implemented at a service scheduling server, comprising: a memory storing computer program instructions; and a processor coupled to the memory and configured to execute the computer program instructions and perform: receiving a notification message from a core network accessed by a user equipment, the notification message being used for indicating that a user plane path of the user equipment is to be changed (Paragraph 172, 173, explicitly discloses core-network-originated notification signaling that indicates a required change of the UE user plane path due to anchor UPF handover), the notification message being transmitted by a session management function (SMF) and forwarded via an application function (AF) to the service scheduling server, the SMF being deployed within the core network (Paragraph 81, 101, 104, teaches SMF-generated control signaling delivered from the core network to application-side control entities via AF/NEF interfaces); rescheduling a service server for the user equipment in response to the notification message (Paragraph 172, 121, 191, explicitly teaches selecting a new target application server and relocating the UE service context in direct response to SMF-initiated notification signaling); and transmitting a confirmation message to the core network, the confirmation message being used for triggering the core network to change the user plane path of the user equipment (Paragraph 192, 193, 176, explicitly teaches confirmation and completion signaling indicating successful service relocation, which enables the core network to finalize user plane path switching), wherein in response to the confirmation message, the IP address of the rescheduled service server is configured as an offloading address in an intermediate user plane function (I-UPF) (Paragraph 92, 172, 247, teaches re-anchoring user traffic through a target UPF after confirmation of relocation, functionally corresponding to configuring the relocated service endpoint as an offloading destination in an intermediate UPF).
Yu et al. does not explicitly teach transmitting an Internet Protocol (IP) address of a rescheduled service server to the user equipment, to trigger the user equipment to switch a currently accessed service server to the rescheduled service server according to the IP address.
However, Yuan et al. teaches transmitting an Internet Protocol (IP) address of a rescheduled service server to the user equipment, to trigger the user equipment to switch a currently accessed service server to the rescheduled service server according to the IP address (Paragraph 63, 65, 116, 134, 137, explicitly teaches transmitting an IP address of a newly selected application server to the UE, which the UE then uses to switch service access to that server).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide transmitting an Internet Protocol (IP) address of a rescheduled service server to the user equipment, to trigger the user equipment to switch a currently accessed service server to the rescheduled service server according to the IP address as taught by Yuan et al. in the system of Yu et al., so that it would enable the UE to promptly and reliably redirect ongoing service traffic to the newly selected service server after core-network-initiated user plane path change and service server rescheduling, thereby maintaining service continuity and reducing interruption during service relocation.
Regarding claim 9, Yu et al. teaches generating a timer according to a duration desirable for a path change carried in the notification message, a duration specified by the timer being greater than or equal to the duration desirable for the path change; and transmitting the timer to the user equipment, to trigger the user equipment to switch to the rescheduled service server for access after the timer expires (Paragraph 122, 137, 152, 175, 248, teaches determining and enforcing a controlled waiting duration for path switching by explicitly delaying UE traffic transition until relocation completion, old-path packet termination, and buffering conditions are satisfied, which collectively correspond to generating a timing constraint at least as long as the desired path-change duration and signaling that constraint to govern when the UE effectively switches to the rescheduled service server).
Regarding claim 10, Yu et al. teaches rescheduling the service server includes: selecting a target data network access point identifier from data network access point identifiers carried in the notification message (Paragraph 101, 172, 173, 122, These passages collectively teach selecting a target DNAI from available DNAIs signaled in control/notification messaging (e.g., relocation request/trigger messages) and using that selected DNAI to drive service server (AS/MEC) relocation and rescheduling decisions).
Regarding claim 11, Yu et al. teaches rescheduling the service server includes: selecting a service server corresponding to the target data network access point identifier as the rescheduled service server (Paragraph 101, 122, 191, Together, these passages teach that when rescheduling a service server, the system selects (i.e., determines and uses) a target application/service server that corresponds to the target DNAI).
Regarding claim 12, Yu et al. teaches the confirmation message carries the target data network access point identifier, or carries the target data network access point identifier and the IP address of the rescheduled service server (Paragraph 101, 119, 133, The passages disclose a confirmation/trigger message that explicitly includes a target data network access point identifier).
Regarding claim 13, Yu et al. teaches rescheduling the service server includes: selecting a service server deployed in a center network as the rescheduled service server in response to a determination that no data network access point identifier is carried in the notification message, the service server currently accessed by the user equipment being deployed in an edge network, and the center network corresponding to the edge network (Paragraph 93, 95, 100, 101, 172, These passages collectively teach that when a UE is currently served by an edge-deployed service (MEC/AS at a local data center) and a handover occurs such that no edge-specific access identifier is available or applicable, a centrally deployed service server (AS controlled by a central data center with SMF/PCF) is selected and used as the rescheduled service server corresponding to that edge network).
Regarding claim 14, Yu et al. teaches transmitting the IP address includes: transmitting the IP address to the service server currently accessed by the user equipment, to forward the IP address to the user equipment via the service server currently accessed by the user equipment (Paragraph 81, 174, 101, 172–174, The passage teaches that an IP address of the UE is provided by the SMF and transmitted to the currently accessed service server (source AS/MEC), which forwards that IP address as UE-identifying information for continued communication with the UE via the service server currently accessed by the UE).
Regarding claim 15, Yu et al. teaches a non-transitory computer-readable storage medium storing computer program instructions executable by at least one processor to perform: receiving a notification message from a core network accessed by a user equipment, the notification message being used for indicating that a user plane path of the user equipment is to be changed (Paragraph 172, 173, explicitly discloses core-network-originated notification signaling that indicates a required change of the UE user plane path due to anchor UPF handover); rescheduling a service server for the user equipment in response to the notification message (Paragraph 172, 121, 191, explicitly teaches selecting a new target application server and relocating the UE service context in direct response to SMF-initiated notification signaling), the notification message being transmitted by a session management function (SMF) and forwarded via an application function (AF) to a service scheduling server, the SMF being deployed within the core network (Paragraph 81, 101, 104, teaches SMF-generated control signaling delivered from the core network to application-side control entities via AF/NEF interfaces); and transmitting a confirmation message to the core network, the confirmation message being used for triggering the core network to change the user plane path of the user equipment (Paragraph 192, 193, 176, explicitly teaches confirmation and completion signaling indicating successful service relocation, which enables the core network to finalize user plane path switching), wherein in response to the confirmation message, the IP address of the rescheduled service server is configured as an offloading address in an intermediate user plane function (I-UPF) (Paragraph 92, 172, 247, teaches re-anchoring user traffic through a target UPF after confirmation of relocation, functionally corresponding to configuring the relocated service endpoint as an offloading destination in an intermediate UPF).
Yu et al. does not explicitly teach transmitting an Internet Protocol (IP) address of a rescheduled service server to the user equipment, to trigger the user equipment to switch a currently accessed service server to the rescheduled service server according to the IP address.
However, Yuan et al. teaches transmitting an Internet Protocol (IP) address of a rescheduled service server to the user equipment, to trigger the user equipment to switch a currently accessed service server to the rescheduled service server according to the IP address (Paragraph 63, 65, 116, 134, 137, explicitly teaches transmitting an IP address of a newly selected application server to the UE, which the UE then uses to switch service access to that server).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide transmitting an Internet Protocol (IP) address of a rescheduled service server to the user equipment, to trigger the user equipment to switch a currently accessed service server to the rescheduled service server according to the IP address as taught by Yuan et al. in the system of Yu et al., so that it would enable the UE to promptly and reliably redirect ongoing service traffic to the newly selected service server after core-network-initiated user plane path change and service server rescheduling, thereby maintaining service continuity and reducing interruption during service relocation.
Regarding claim 16, Yu et al. teaches generating a timer according to a duration desirable for a path change carried in the notification message, a duration specified by the timer being greater than or equal to the duration desirable for the path change; and transmitting the timer to the user equipment, to trigger the user equipment to switch to the rescheduled service server for access after the timer expires (Paragraph 122, 137, 152, 175, 248, teaches determining and enforcing a controlled waiting duration for path switching by explicitly delaying UE traffic transition until relocation completion, old-path packet termination, and buffering conditions are satisfied, which collectively correspond to generating a timing constraint at least as long as the desired path-change duration and signaling that constraint to govern when the UE effectively switches to the rescheduled service server).
Regarding claim 17, Yu et al. teaches selecting a target data network access point identifier from data network access point identifiers carried in the notification message (Paragraph 101, 172, 173, 122, These passages collectively teach selecting a target DNAI from available DNAIs signaled in control/notification messaging (e.g., relocation request/trigger messages) and using that selected DNAI to drive service server (AS/MEC) relocation and rescheduling decisions).
Regarding claim 18, Yu et al. teaches rescheduling the service server includes: selecting a service server corresponding to the target data network access point identifier as the rescheduled service server (Paragraph 101, 122, 191, Together, these passages teach that when rescheduling a service server, the system selects (i.e., determines and uses) a target application/service server that corresponds to the target DNAI).
Regarding claim 19, Yu et al. teaches the confirmation message carries the target data network access point identifier, or carries the target data network access point identifier and the IP address of the rescheduled service server (Paragraph 101, 119, 133, The passages disclose a confirmation/trigger message that explicitly includes a target data network access point identifier).
Regarding claim 20, Yu et al. teaches rescheduling the service server includes: selecting a service server deployed in a center network as the rescheduled service server in response to a determination that no data network access point identifier is carried in the notification message, the service server currently accessed by the user equipment being deployed in an edge network, and the center network corresponding to the edge network (Paragraph 93, 95, 100, 101, 172, These passages collectively teach that when a UE is currently served by an edge-deployed service (MEC/AS at a local data center) and a handover occurs such that no edge-specific access identifier is available or applicable, a centrally deployed service server (AS controlled by a central data center with SMF/PCF) is selected and used as the rescheduled service server corresponding to that edge network).
Allowable Subject Matter
Regarding claim 1, 8, & 15, some amendments that could be made to potentially make these claims allowable would be to include explicit sequencing between UE server switching and core-network user plane path change. Concept: require that the UE is triggered to switch service servers before the core network performs the user plane path change. Decoupling service server reselection from user plane path switching. Concept: service server reselection and UE switching occur independently of, and prior to, network-side path reconfiguration. Confirmation message as a gating mechanism. Concept: the confirmation message authorizes or enables the core network to perform the user plane path change only after server reselection actions are completed.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ma et al. (US 20240323787 A1)
PEDERSEN et al. (US 20220014981 A1)
Li et al. (US 20210105685 A1)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANDREW SHAJI KURIAN whose telephone number is (703)756-1878. The examiner can normally be reached Monday-Friday 8am-4pm.
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, Ricky Ngo can be reached at (571) 272-3139. 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.
/ANDREW SHAJI KURIAN/Examiner, Art Unit 2464
/IQBAL ZAIDI/Primary Examiner, Art Unit 2464