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 Remarks/Arguments
This Office Action is in response to the communications for the present US application number 18/285,509 last filed on December 24th, 2025.
Claims 1-23 were previously cancelled.
Claims 24 and 32 were amended.
Claims 24-37 remain pending and have been examined, directed to NETWORK NODES AND METHODS THERIEN FOR FACILITATING APPLICATION CONTEXT RELOCATION.
Upon further review of the latest claim amendments along with the applicant’s representative’s response, the examiner reviewed the applied references and respectfully remains unpersuaded.
The amendments to the Specifications dated December 24th, 2025 were reviewed and found acceptable.
With respect to the 35 U.S.C. § 103 rejection, using Yao in view of Kim, and using amended independent claim 24 for discussion purposes, the applicant’s representative primarily argued the first three limitations in claim 24.
First, due to the amendments, specifying each of the steps to be carried out by a source EAS, communicating to the source EES, regarding a discovery of target EASs, the Examiner reviewed and updated the response to focus on the embodiments that most closely reflect this change, so the emphasis on Yao’s Figs. 9, 10, and 13 were still applicable here, because those embodiments more specifically highlight the source application server and the source enabler server. The representative argued that there were no clear or reasonable teachings of requesting for a discovery of edge application servers (EASs) to be a new target EAS, between the two source EAS and the source EES components.
In response, the Examiner respectfully disagrees, because Yao’s Figs. 9, 10, and 13 specifically had at least those two components (source AS <-> source ES), and while the request was related to location information, this was still reasonably related to determining the most suitable target EASs, given that location information. This is aligned with the overall consideration of the claim as a whole aspect. The present application is also concerned with facilitating application (client) relocations, as those UE/EEC connections change across different EASs and EESs (e.g., See filed Specifications page 1). The various extra details about the EDN for context and background were also updated and removed, since the present application also relies in the understanding and definition of what an EDN encompasses (e.g., See filed Specifications page 1). The Examiner had previously explained at length how a request from a UE can traverse through various components, with respect to Yao’s Figs. 2-4, but those are minimized as well now. The Examiner has updated the response to more clearly reflect how a source EAS and a source EES are communicating with each other, and whether a discovery request for new target EASs is there. Those concepts are taught between Yao’s examples and what Kim’s example can overlap and supplement to reinforce Yao’s teachings. Because Yao had many variations, Yao ¶ 151 also further explains that the names and labels are not limiting, and so that’s why a request can originate from various starting components. Also, Yao’s ¶¶ 511-512 and expanding a little more for context, by ¶ 533 the information on a target AS is returned back to the UE. Yao’s ¶ 151 would explain that even when the example was described as starting with the UE, it can be easily understood by one of ordinary skill in the art that the request can travel to the next component(s) until it involves a starting source EAS or relabel the source of the request at the source EAS, to find any suitable target (E)ASs, given new location information that’s also happening.
The representative also argued that Kim’s teachings were not clearly conveyed to teach and/or suggest of any new target EASs discovered, when Kim’s example related to context relocation request. The Examiner reviewed and updated the response to re-emphasize how Kim specifically identifies these different entities with the source EAS and source EES and target EAS and target EES components. And, to re-iterate that the claim as a whole was considered, and with some context regarding what the system is doing with “context relocation request” information, it should be reasonable for one of ordinary skill in the art, before the effective filing date of the present application, to understand that with new relocation information in a request, a new (target) EAS might also be needed. For example, earlier on, for more definitions and context, Kim discloses about determining relocation and discovering new target EAS/EES (e.g., Kim: ¶¶ 62 and 256). Also, a lot of this example would overlap and reinforce with the overall layout such as from Yao’s Fig. 3, where if the UE relocations far enough, it might cause the connection to change EDNs and in turn that would mean changing to a different EAS within the new/different EDN. It should also be clear to one of ordinary skill in the art that Kim’s specific identification of the source EAS/EES and target EAS/EES can be incorporate within one of Yao’s various examples as it relates to a UE moving around and updating location information finding a suitable target EAS/EES.
Next the applicant’s representative further argued the second and third limitations in claim 24, focusing on whether any EASs were discovered and provided back and whether any were selected.
In response, the Examiner has updated each section following the first limitation step, between the combined teachings from Yao and Kim, Yao’s Figs. 9, 10, and 13 and ¶¶ 511-512 and 534 examples, along with Kim’s supplemental teachings with the specific source EAS and source EES looking to discover new target EAS (from Kim ¶¶ 62 and 256), it should now be clear that in the combined system, a source EAS would have gotten back information from the source EES, not just relocation related information on the UE, but also target EAS information that can be selected.
For at least these reasons, the Examiner remains unpersuaded at this time. Please consider further amendments, given the multiple variations and overlapping concepts between these references’ teachings. See also an additional prior art for any reconsiderations, listed in the 892 form.
Independent claim 36 was similarly amended and argued following claim 24 and thus was similarly rejected under the same rationale.
Independent claims 29 and 37 were written and directed to the EES, and since the source EES was also clearly identified to be in communication with the source EAS while complementing or performing the same steps but from the opposite perspective as already covered in claims 24 and 36, therefore, these two claims were also similarly rejected under the same rationale.
The remaining dependent claims were not specifically argued at this time.
Applicant's arguments were considered but they were not found persuasive. See the following claim rejections for further clarifications with added emphasis on the points previously disclosed.
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.
Claims 24-37 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Publication No. US 2023/0188965 A1 to Yao et al. (referred to hereafter as “Yao”) in view of U.S. Patent Publication No. US 2023/0053805 A1 to Kim et al. (referred to hereafter as “Kim”).
As to claim 24, Yao discloses a method in a source Edge Application Server (EAS), the method comprising:
transmitting, by the source EAS, a request for EAS discovery to a source Edge Enabler Server (EES) (Yao discloses of an overall system that discloses within certain embodiments of an overall process involved with a user’s equipment (UE) that’s moving and trying to establish a connection by finding and discovering other discovered application servers as a target EAS (by the third limitation step).
Starting with Yao’s Figs. 2-4, Yao discloses of examples where a UE can move around discover, and if needed, connect to different (target) EASs that might be a part of a different EDN (e.g., Yao: ¶¶ 139-144 and 151 serves as an overall starting point of the claimed steps, with definitions for the EAS and EES components). The concept with the EDN and the two components it encompasses are also similarly described in the present application’s filed Specifications (on page 1).
So, in a scenario supposing a UE is moving around and can connect to possibly different EDNs, with different target EASs within them (see Yao Fig. 3 again). The discovery request for other additional EASs within a network can be sent from any suitable computing entity, such as from the UE (or EEC component within the UE), or a source (edge) application server (or S(E)AS). Yao’s Figs. 9, 10, and 13 offer multiple variations, but they all specifically include the source AS and the source ES components (e.g., Yao: ¶ 151). In these variation embodiments, the steps involve how a source like S-(E)AS can send out a request to a S-(E)ES to discover any new location information (via subscriptions). From there, the location information would therefore translate into potentially new connects to new target or new target ASs for the UE to connect to as it relates to preserving the user connection or PDU session(s).
Yao does not disclose about any requests from a source edge AS to a source EES, requesting for new EAS discoveries. A close variation was however described as Yao discloses and considers a request, from a UE, can be for an “application server discovery request message”, and given what Yao established in ¶ 151 with respect to the labeling of the various components, it would have been reasonable to one of ordinary skill in the art, before the effective filing date of the present application, to consider how the request while it started with the UE, would have been passed along to other components, such that it can then involve a source AS that the UE is connected to within the initial EDN, and then awaiting the response to the “application server discovery request message” for any new target application servers afterwards following this example, (e.g., Yao: ¶¶ 511-512 and 151).
To further supplement this feature concept and step, focusing on the portion with a source EAS and source EES, Kim more expressly discloses of this concept, wherein all the entities are present (i.e., S-EAS, S-EES, T-EES, and T-EAS), and Kim describes of a similar scenario wherein the system is trying to identify/determine new target EESs and target EASs in a possible new location, based on location information. In at least one embodiment example, Kim discloses a request is triggered by either an EEC (within a UE) or a source EAS, where the source EES receives the request (related to a UE/EEC relocation request), and new target EES/EAS may need to be identified/determined based on the location information (e.g., Kim: Fig. 14, step 2B, ¶¶ 256-258, 261 and related ¶¶ 62 and 167-168 regarding step 2B a context relocation request from the source EAS, because the request is asking for other target EASs and EESs as part of the relocation procedure of finding/discovering a new target EAS/EES).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the present application, to combine and incorporate Kim’s more explicit teachings with the different components/entities (e.g., source EAS and source EES and target EAS and target EES) and their capabilities (e.g., requesting for available target AS, given known or new location information), which can overlap when incorporated altogether within Yao’s overall system and teachings, because then the resulting combined system can handle any transitions, if necessary, to different target ASs (which can be in different EDNs) and maintain proper session connections or transitions for a moving UE);
receiving, at the source EAS, from the source EES, a response containing information indicating one or more discovered EASs (Following the previous step and interpretations, Yao discloses that the Source-(E)ES can make some determinations based on the received notifications information and send that back to the Source-(E)AS, again with respect to Figs. 9, 10, or 13’s examples, that explicitly disclose of the specific source (E)AS and source (E)ES components. The notifications information relates to the first location information which is tracking the UE’s location and/or movement. Additionally, it would have been obvious that in response to the specific “application server discovery request message” from Yao’s ¶¶ 511-512, the message can be passed along, until a response is sent back to the source ES (Yao: ¶¶ 519-526) regarding any discovered target ES and target AS, along with ¶ 151’s understanding of labeling.
Kim further supplements Yao’s example and concept by explicitly disclosing of the distinct entities including the source EAS/EES and target EAS/EES entities while also similarly disclosing of the step related to providing back to the source EAS, the new information regarding any discovered target EASs. Kim discloses of this in the context of new location information being focused on, which further translates into identifying and determining possibly new target EASs/EESs according to the new location as a UE/EEC moves around (e.g., Kim: Fig. 15 variation, step 6 example and related ¶ 281 and also related ¶¶ 62 and 256, following the prior step).
Once again, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the present application, to combine and incorporate Kim’s more explicit teachings with the different components/entities, which can overlap with Yao’s overall system and teachings, to ensure and maintaining proper session connections or transitions for a moving UE);
selecting, by the source EAS, one of the one or more discovered EASs as a target EAS (Following the previous steps and interpretations, Yao discloses within its variation embodiments, where a source AS (or S-(E)AS) can make a determination on a new target (E)AS. (e.g., Examples like S907, S1009, and/or S1307 were applicable to the concept). Also, in Fig. 17’s embodiment, a source ES was able to select and provide the connection information for a selected target AS (e.g., ¶¶ 531-533 given ¶ 151’s labeling).
While these examples were close but not exact, such as with a different source EES and not a source EAS, this can still be supplemented by Kim’s teachings as Kim also more clearly discloses of the distinct entities including the source EAS/EES and target EAS/EES entities and more expressly discloses of selecting a target EAS, depending on what was found in the earlier discovery phase, (e.g., Kim: Fig. 15, step 7 and ¶¶ 62, 167-168, 256-258, 261 and 281).
In following what was previously established earlier, the response back would have included information on the new target EASs, which is what would have been incorporated and overlapping with Yao’s teachings and example.
See the previously stated reasons for combining and incorporating Kim’s teachings within Yao’s overall system and teachings); and
transmitting information indicating the selected target EAS to the source EES (Following the previous steps and interpretations, this step is similar to the above step, right after the system determines and selects a target, that information would be transmitted and passed along as a form of notification and/or confirmation. While Yao does not expressly disclose of this specific step, it would still have been obvious to one of ordinary skill in the art that whatever target (E)AS gets selected, the source S-(E)ES would be kept apprised as it manages the connections (e.g., Yao: ¶ 382).
Kim further supplements Yao’s example and concept here, because in Kim’s example, like Fig. 15, step 7 again, the source EAS is specifically sending information on the target EAS back to the S-EES components.
See the previously stated reasons for combining and incorporating Kim’s teachings within Yao’s overall system and teachings).
As to claim 25, Yao further discloses the method of claim 24, wherein the step of transmitting the information indicating the selected target EAS comprises including an identifier of the selected target EAS and/or an endpoint of the selected target EAS (Following claim 24, the transmitting step refers to letting the Source EES know about the (new) selected target EAS information, which would have been obvious that some identifying information (or “identifier”) is used to indicate the selection.
Similar to claim 24’s last step, while Yao does not expressly disclose of this specific step, Kim more expressly discloses and reinforces the concept within its own variations, like Fig. 15, step 7 again, wherein a source S-EAS is specifically sending information back to the S-EES components.
See the similarly stated reasons for combining and incorporating Kim’s teachings within Yao’s overall system and teachings).
As to claim 26, Yao further discloses the method of claim 24, wherein the information indicating the selected target EAS is transmitted in a request to notify the source EES of the selected target EAS (Following claim 24, similar to claim 25, while Yao does not expressly disclose of this specific step between the source S-(E)AS and the source S-(E)ES, it would still have been obvious as the source S-(E)ES is kept apprised as it manages the connections (e.g., Yao: ¶ 382).
Kim more expressly discloses and reinforces the concept within its own variations, like Fig. 15, step 7 again, wherein a source S-EAS is specifically sending information back to the S-EES components.
See the similarly stated reasons for combining and incorporating Kim’s teachings within Yao’s overall system and teachings).
As to claim 27, Yao further discloses the method of claim 26, further comprising:
receiving, from the source EES, a response to the request to notify the source EES of the selected target EAS (Following claims 24 and 26, while Yao does not expressly disclose of a specific step for this concept, it is still interpreted as confirmation by the Source S-(E)ES, which would have been obvious to one of ordinary skill in the art, before the effective filing date of the present application, as the S-(E)ES manages the connections and also handles any transitional connections to any new targets, (e.g., Yao: ¶ 382).
Kim also more expressly reinforces and discloses about responses back from a Source EES, like Fig. 14, step 8.
See the similarly stated reasons for combining and incorporating Kim’s teachings within Yao’s overall system and teachings).
As to claim 28, Yao further discloses a non-transitory computer-readable storage medium comprising, stored thereupon, computer-readable instructions stored, the computer-readable instructions being configured so that, when executed by a processor of a network node, the computer-readable instructions configure the network node to, when implementing a source Edge Application Server (EAS), perform the method of claim 24 (e.g., Yao: ¶¶ 562 and 566).
As to claim 29, Yao further discloses a method in a source Edge Enabler Server (EES), the method comprising:
(Examiner’s Note: See the similar interpreted response in claim 24 which focused in the same steps in terms of concept, but here written in the opposite perspective of the source EES. The exchanges happen between the source EAS [Wingdings font/0xDF][Wingdings font/0xE0] source EES regarding any discovered target EASs. )
receiving, from a source Edge Application Server (EAS), a request for EAS discovery (See the similar interpreted response in claim 24 as this is the complement in the opposite perspective meaning it’s the same first step, described in the other opposite perspective);
transmitting, to the source EAS, a response containing information indicating one or more discovered EASs (See the similar interpreted response in claim 24 as this is the complement in the opposite perspective, meaning it’s the same second step, described in the other opposite perspective regarding a response back); and
receiving, from the source EAS, information indicating a selected target EAS, the selected target EAS being selected from the one or more discovered EASs (See the similar interpreted response in claim 24 as this is the complement in the opposite perspective, meaning it’s the same third step, described in the other opposite perspective regarding a selection for a target EAS).
As to claim 30, Yao further discloses the method of claim 29, wherein the step of receiving the information indicating the selected target EAS comprises receiving an identifier of the selected target EAS and/or an endpoint of the selected target EAS (See the similar interpreted response in claim 25 as this is the complement in the opposite perspective).
As to claim 31, Yao further discloses the method of claim 29, wherein the information indicating the selected target EAS is received in a request to notify the source EES of the selected target EAS (See the similar interpreted response in claim 26 as this is the complement with notifying the source EES component).
As to claim 32, Yao further discloses the method of claim 31, further comprising:
determining that the source EAS is authorized to transmit the request to notify the source EES of the selected target EAS (see below); and
transmitting, to the source EAS, a response to the request to notify the source EES of the selected target EAS (For both of these two steps, see the similar interpreted response in claims 26 and 27 as this is a slight variation, but involving the same two entity components as the source EAS and source EES are communicating back and forth with the new target EAS/transitions).
As to claim 33, Yao further discloses the method of claim 29, further comprising:
transmitting the information indicating the selected target EAS to an Edge Enabler Client (EEC) (Following claim 29, Yao discloses that the UE can have the EEC component, which can be interpreted as the originating source of the request(s), and now the UE/EEC is getting notified about a determined target EAS, for a new connection as the UE moves around with new location information, e.g., Yao: ¶ 538).
As to claim 34, Yao further discloses the method of claim 33, further comprising:
determining information indicating a target EES based on the information indicating the selected target EAS (Following claims 33 and 29/24, Yao was already established to disclose about EDNs that encompass EES and EASs (e.g., Yao: Figs. 2-4 and corresponding ¶¶ 139-140, 142-144, 147-149, and 151). Therefore, for any suitable targets or Target T-(E)ASs, a corresponding Target T-(E)ES is also involved as it handles connection information (e.g., Yao: ¶ 382)); and
transmitting the information indicating the target EES to the EEC (Similar to claim 33, any potential target connection changes would be sent back to the source UE/EEC, e.g., Yao: ¶ 538).
Kim also more expressly reinforces and discloses about EECs getting notified of changes involving any new target EES and/or target EASs (e.g., Kim: Figs. 14 and 15).
See the similarly stated reasons for combining and incorporating Kim’s teachings within Yao’s overall system and teachings).
As to claim 35, Yao further discloses a non-transitory computer-readable storage medium comprising, stored thereupon, computer-readable instructions stored, the computer-readable instructions being configured so that, when executed by a processor of a network node, the computer- readable instructions configure the network node to, when implementing a source Edge Enable Server (EAS), perform the method of claim 29 (e.g., Yao: ¶¶ 562 and 566).
As to claim 36, see the similar interpreted response of claim 24, as the “network node” can be similarly interpreted as any computing entity or considered as the S-EAS, communicating with the S-EES, which the Examiner was already considering.
As to claim 37, see the similar interpreted response of claim 29, as the “network node” can be similarly interpreted as any computing entity or considered as the S-EES, communicating back to the S-EAS, which the Examiner was already considering.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 Xiang Yu whose telephone number is (571)270-5695. The examiner can normally be reached M-F 9:30-3:00 (PST/PDT).
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, Emmanuel Moise can be reached at (571)272-3865. 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.
/X.Y./Examiner, Art Unit 2455
/DAVID R LAZARO/Primary Examiner, Art Unit 2455
Prosecution Insights