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 03/29/2024 and 07/07/2025 were filed. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner
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 pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3 and 7-18 are rejected under 35 U.S.C. § 103 as being unpatentable over Hall (US20210337043A1; “Hall”) in view of Kim (US20210352156A1; “Kim”).
Regarding claim 1, Hall discloses: (Currently Amended) An apparatus for performing a network function, the apparatus comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the apparatus to: a UE and an edge network device having memory and one or more processors configured to perform application-context-relocation operations between an edge enabler client and an edge enabler server. (Hall, paras. [0015]-[0016] and para. [0214]-[0216]).
Furthermore, Hall discloses: receive, from a detection entity, an event notification related to an adaption of a behavior of at least one user equipment (UE); the EES receiving from the EEC a trigger after the EEC detects an event, such as a handover, that could lead to transfer of an application context of the UE. (Hall, paras. [0095]-[0096]).
Moreover, Hall discloses: determine, in response of receiving the event notification, a trigger action for at least one application of the at least one UE, the EES determining whether to process the application-context relocation after receiving the trigger from the EEC, and the EEC determining that the EAS may be more suitable because the UE is moving outside a service area or other conditions are degrading support for the application. (Hall, paras. [0095] “. . . an edge enabler client (EEC) (or source EEC) of an edge network device may detect an event (e.g., handover) that could lead to a transfer of an application context. As shown by reference number 404, the EEC may trigger the edge enabler server (EES) to perform an application context relocation . . . [0096] . . . when the EAS information update occurs, the EAS 101 may transmit an EAS info change event notification to the EES 100. The corresponding notification to be transmitted may include the UE ID of the user equipment having been provided with the service of the EAS 101. . .”, also see para. [0099]-[0100]).
Moreover, Hall discloses: and transmit the trigger action to an application entity, a further application enablement entity, or a combination thereof to execute the trigger action based on the event notification. the EES transmitting a relocation request to the EAS and responding to the EEC that relocation can go forward, after which the EEC commands the EAC to transfer the application context. (Hall, paras. [0100]-[0101]).
With respect to claim 1, Hall does not explicitly disclose each of the recited trigger-action variants, although Hall teaches relocation decisioning, denial of a trigger, and period-of-time transfer with return of support. (Hall, paras. [0096], [0100], [0194]): wherein the trigger action comprises: an edge support service modification; an edge support service cancellation; an edge support service pause;
However, Hall in view of Kim teaches modification of edge application information and EAS profiles, stopping or changing service handling when an EAS becomes unavailable (i.e., “trigger action” as claimed), and time-limited control of updated EAS information through TTL-based handling, thereby teaching modification, cancellation, and pause-type edge-support-service actions within the recited alternatives. (Kim, paras. [0062]-[0070], [0096]-[0101], [0124]-[0130]).
Furthermore, Hall also does not explicitly disclose creation of a new candidate target application server, although Hall teaches obtaining location details for a target EES and/or a target EAS and relocating the application context to the edge network device. (Hall, paras. [0095], [0099]-[0101]): selection of an alternative application server; creation of a new candidate target application server; or a combination thereof;
PNG
media_image1.png
486
997
media_image1.png
Greyscale
However, Hall in view of Kim teaches selecting a currently available target EAS or triggering a new EAS instantiation by the target EES and returning target EAS information to the existing EES/EEC, thereby teaching selection of an alternative application server and creation of a new candidate target application server. (Kim, paras. [FIG. 5], [0013]-[0016], [0115]-[0119], [0128]-[0130]).
Therefore, it would have been obvious to modify Hall with Kim so that Hall’s EEC-to-EES relocation backbone used Kim’s explicit target-EES/target-EAS information exchange, EAS-profile updating, and target-EAS instantiation teachings when handling UE behavior changes and EAS-state changes.
Doing so would have predictably improved edge application continuity, reduced service delay, and reduced repeated discovery/signaling while preserving the application context during UE mobility or EAS unavailability. (Hall, paras. [0089]-[0101]; Kim, paras. [0013]-[0016], [0115]-[0119], [0124]-[0130]).
Regarding claim 2, (Currently Amended) Hall does not explicitly disclose the first recited family of expected-change parameters, although Hall teaches handover-triggered relocation and conditions at the UE that could lead to transfer of application context. (Hall, paras. [0095], [0110]-[0113]): The apparatus of claim 1, wherein the event notification comprises at least one parameter that is expected to change, and the at least one parameter comprises: an expected mobility of the at least one UE; a predicted mobility of the at least one UE; an expected location of the at least one UE; a predicted location of the at least one UE; an expected change of speed of the at least one UE; a predicted change of speed of the at least one UE; an expected direction of the at least one UE; a predicted direction of the at least one UE;
However, Hall in view of Kim teaches mobility-related event information including changed UE location, deviation from service area, and target DNAI information used to select a target EES/EAS for the moving UE, thereby teaching at least expected/predicted mobility and location parameters within the recited alternatives. (Kim, paras. [0013], [0113]-[0115], [0129]-[0130]).
Besides, Hall does not explicitly disclose the second recited family of expected-change parameters, although Hall teaches degradation in quality of service, performance thresholds, and maximum-latency constraints used in deciding whether to relocate or trigger a shadow context. (Hall, paras. [0110]-[0113], [0136]-[0139]): a change of a service profile of the at least one application of the at least one UE; a change of a service operation of the at least one application of the at least one UE; a confidence level of a predicted UE behavior; an expected quality of service of the at least one UE; an expected quality of service of a network device; a predicted quality of service of the at least one UE; a predicted quality of service of the network device; or a combination thereof.
However, Hall in view of Kim teaches changed EAS profile information, service-KPI updates, EAS service-area/status changes, and updated information delivered in response to monitored events, thereby teaching at least service-profile and quality-of-service parameters within the recited alternatives. (Kim, paras. [0068]-[0070], [0095]-[0100], [0124]-[0130]). Accordingly, the rationale to combine Hall and Kim is the same as described in claim 1 above.
Regarding claim 3, Hall does not explicitly disclose each of the recited failure or unavailability indications, although Hall teaches loss of connectivity and performance-threshold conditions that trigger relocation decisions. (Hall, paras. [0110]-[0113]): (Currently Amended) The apparatus of claim 1, wherein the event notification further comprises: a network failure, a network interface failure, an application interface failure, an edge data network unavailability indication, an edge data network failure indication, or a combination thereof. However, Hall in view of Kim teaches unavailable EAS status, inability to instantiate an additional EAS in the current platform, and service-area/DNAI-change conditions delivered in event notifications, which at least teach an edge-data-network unavailability/failure indication within the recited alternatives. (Kim, paras. [0096]-[0100], [0112]-[0115], [0125]-[0130]). Accordingly, the rationale to combine Hall and Kim is the same as described in claim 1 above.
Regarding claim 7, Hall discloses: (Currently Amended) The apparatus of claim 1, wherein the network function comprises an application enablement entity. Hall teaches the edge enabler client and edge enabler server performing the disclosed application-context-relocation functions between the UE and the edge network device. (Hall, paras. [0089]-[0096]).
Regarding claim 8, Hall discloses: (Original) The apparatus of claim 7, wherein the application enablement entity comprises an edge enabler client or an edge enabler server. Hall expressly teaches both the EEC and the EES as the entities performing the relocation-related application-enablement functions. (Hall, paras. [0089]-[0096]).
Regarding claim 9, (Original) Hall does not explicitly disclose the service-continuity wording, although Hall teaches the edge enabler server handling operations of the edge application server, deciding whether an application context is to be relocated, and coordinating context relocation between the UE and the edge network device. (Hall, paras. [0089]-[0101]): The apparatus of claim 7, wherein the application enablement entity is configured to control an edge application service continuity for the at least one application.
However, Hall in view of Kim teaches controlling continuity of the edge application service by relocating application context to a target EAS and transmitting the information necessary to guarantee service continuity for the UE. (Kim, paras. [0016], [0118]-[0121]). Accordingly, the rationale to combine Hall and Kim is the same as described in claim 1 above.
Regarding claim 10, Hall discloses: (Currently Amended) The apparatus of claim 1, wherein the at least one processor is configured to cause the apparatus to transmit the trigger action to the application entity, the further application enablement entity, or the combination thereof to execute the trigger action based on the event notification. Hall teaches the EES transmitting the relocation request to the EAS and the response/commanding information to the EEC/EAC so that the relocation action is executed based on the triggering event. (Hall, paras. [0100]-[0101]).
Regarding claim 11, Hall does not explicitly disclose translating the trigger action into edge-service parameters, although Hall teaches a relocation request, relocation response, target-EES/target-EAS details, and context-transfer control messaging. (Hall, paras. [0095]-[0101]): (Currently Amended) The apparatus of claim 1, wherein the at least one processor is configured to cause the apparatus to translate the trigger action to at least one edge service parameter for an application service of the at least one application of the at least one UE.
However, Hall in view of Kim teaches processing notifications and generating concrete delivery information including EAS ID/address, EAS profile information, target EES information, target EAS information, and TTL information, thereby translating the trigger action into edge-service parameters for the application service. (Kim, paras. [0096]-[0101], [0118]-[0121], [0126]-[0130]). Accordingly, the rationale to combine Hall and Kim is the same as described in claim 1 above.
Regarding claim 12, (Currently Amended) Hall does not explicitly disclose the recited update to edge-enabler-client context-relocation parameters, although Hall teaches coordinating relocation between the EEC and the EES, commanding transfer of application context, and acknowledging completion of relocation. (Hall, paras. [0096]-[0101]): The apparatus of claim 1, wherein the at least one processor is configured to cause the apparatus to determine, based on the trigger action, an update to edge enabler client context relocation parameters, an application context corresponding to the edge enabler client context relocation parameters, or a combination thereof.
However, Hall in view of Kim teaches updating the EEC with target EES/target EAS information, target EAS profile information, application-context-relocation completion information, and subsequent EEC registration using the updated EAS ID/address information, thereby teaching an update to EEC relocation parameters and corresponding application-context information. (Kim, paras. [0118]-[0121], [0130]-[0139]). Accordingly, the rationale to combine Hall and Kim is the same as described in claim 1 above.
Regarding claim 13, Hall does not explicitly disclose dynamic or proactive EAS instantiation, although Hall teaches triggering generation of a new or shadow application context to support relocation of application support. (Hall, paras. [0111]-[0113], [0204], [0211]-[0213]): (Currently Amended) The apparatus of claim 1, wherein the at least one processor is configured to cause the apparatus to trigger, based on the trigger action, a dynamic edge application server instantiation, a pro-active edge application server instantiation, or a combination thereof.
However, Hall in view of Kim teaches that the target EES may select a currently available target EAS or trigger a new EAS instantiation, and that the EES may request instantiation in the same edge hosting environment or, when appropriate, retrieve and transmit target EES/target EAS information for another environment, thereby teaching dynamic and proactive edge application server instantiation. (Kim, paras. [0013]-[0016], [0097]-[0100], [0117]-[0130]). Accordingly, the rationale to combine Hall and Kim is the same as described in claim 1
Regarding claim 14, (Currently Amended) A method of performing a network function, the method comprising: receiving, from a detection entity, an event notification related to an adaption of a behavior of at least one user equipment (UE);determining, in response of receiving the event notification, a trigger action for at least one application of the at least one UE, wherein the trigger action comprises: an edge support service modification; an edge support service cancellation; an edge support service pause; selection of an alternative application server; creation of a new candidate target application server; or a combination thereof; and transmitting the trigger action to an application entity, a further application enablement entity, or a combination thereof to execute the trigger action based on the event notification.
Claim 14 is the method counterpart of claim 1 because claim 1 recites an apparatus configured to receive an event notification, determine a trigger action, and transmit the trigger action, while claim 14 recites the same receive/determine/transmit sequence as a method. Accordingly, claim 14 is analogous to claim 1, therefore, claim 14 is rejected for the same reasons set forth above with respect to claim 1 above.
Regarding claim 15, Hall discloses: (Currently Amended) An apparatus for performing a network function, the apparatus comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the apparatus to: a UE and an edge network device having memory and one or more processors configured to perform the disclosed context-relocation operations, and Kim likewise discloses an EES having a processor, transceiver, and memory for the corresponding monitoring and update functions. (Hall, paras. [0015]-[0016]; Kim, paras. [0015], [0133]-[0139]).
Further, Hall discloses: and transmit the event notification to a further application enablement entity. Hall teaches the EEC transmitting the relocation trigger message to the EES, and Kim teaches the EES transmitting the resulting dynamic-information notification/target-EES-target-EAS information to the EEC. (Hall, paras. [0095], [0099]-[0101]; Kim, paras. [0118]-[0121]).
With respect to claim 15, Hall does not explicitly disclose receiving the recited monitoring event from an application or second network entity, although Hall teaches the EEC having information about conditions at the UE and the application executing on the UE and receiving application-related information used for relocation decisions. (Hall, paras. [0095], [0110]-[0111]): receive a monitoring event from an application, a second network entity, or a combination thereof;
However, Hall in view of Kim teaches receiving monitored EAS-information-change events and dynamic-information-subscription monitoring messages from the EAS and through interworking with the 3GPP network, which are monitoring events from an application/server or second network entity. (Kim, paras. [0066]-[0070], [0090]-[0096], [0113]-[0115]).
Further, Hall does not explicitly disclose determining the recited event notification in response to the received monitoring event, although Hall teaches the EEC determining to trigger relocation or shadow-context generation based on handover, loss of connectivity, or performance-threshold conditions. (Hall, paras. [0095], [0110]-[0113]): determine, in response of receiving the monitoring event, an event notification related to an adaption of a behavior of at least one user equipment (UE);
However, Hall in view of Kim teaches using monitored UE-location/DNAI changes and EAS-information-change events to determine the corresponding notification/update information that reflects the UE’s changed behavior and service context. (Kim, paras. [0082]-[0083], [0111]-[0115], [0129]-[0130]).
Therefore, it would have been obvious to modify Hall’s event-detection and trigger architecture with Kim’s subscription-based monitoring-event notifications so that an application-enablement entity receives monitoring events from an application or network entity and emits the corresponding event notification to another application-enablement entity. Doing so would have predictably provided earlier notice of UE-mobility and EAS-state changes, thereby allowing the edge system to adapt service continuity with less delay and signaling overhead. (Hall, paras. [0095]-[0113]; Kim, paras. [0066]-[0070], [0090]-[0096], [0111]-[0121]).
Regarding claim 16, (New) A method of performing a network function, the method comprising: receiving a monitoring event from an application, a second network entity, or a combination thereof; determining, in response of receiving the monitoring event, an event notification related to an adaption of a behavior of at least one user equipment (UE); and transmitting the event notification to a further application enablement entity.
Claim 16 is the method counterpart of claim 15 because both recite receiving a monitoring event from an application, a second network entity, or a combination thereof, determining an event notification related to an adaption of UE behavior, and transmitting the event notification to a further application enablement entity, with claim 15 in apparatus form and claim 16 in method form. Accordingly, claim 16 is rejected for the same reasons set forth above with respect to claim 15.
Regarding claim 17, (New) The method of claim 14, wherein the event notification comprises at least one parameter that is expected to change, and the at least one parameter comprises: an expected mobility of the at least one UE; a predicted mobility of the at least one UE; an expected location of the at least one UE; a predicted location of the at least one UE; an expected change of speed of the at least one UE; a predicted change of speed of the at least one UE; an expected direction of the at least one UE; a predicted direction of the at least one UE; a change of a service profile of the at least one application of the at least one UE; a change of a service operation of the at least one application of the at least one UE; a confidence level of a predicted UE behavior; an expected quality of service of the at least one UE; an expected quality of service of a network device; a predicted quality of service of the at least one UE; a predicted quality of service of the network device; or a combination thereof.
Claim 17 is analogous to claim 2 and therefore, claim 17 is rejected for the same reasons set forth.
Regarding claim 18, (New) The method of claim 14, wherein the event notification further comprises: a network failure, a network interface failure, an application interface failure, an edge data network unavailability indication, an edge data network failure indication, or a combination thereof.
Claim 18 is analogous to claim 3 and therefore, claim 18 is rejected for the same reasons set forth.
Claims 4-6 and 19-20 are rejected under 35 U.S.C. § 103 as being unpatentable over Hall (US20210337043A1; “Hall”) in view of Kim (US20210352156A1; “Kim”) and further in view of Young (US10841974B1; “Young”).
Regarding claim 4, (Currently Amended) Hall in view of Kim does not explicitly disclose the full recited field set for the modification request, although Hall and Kim teach relocation/control requests carrying application/client identifiers, UE identifiers, target-EES/target-EAS information, application-context-relocation information, and completion-related information. (Hall, paras. [0100]-[0101]; Kim, paras. [0013]-[0016], [0115]-[0121]) Kim also does not explicitly disclose the full recited relocation-timing and session-field set: The apparatus of claim 1, wherein the edge support service modification comprises a request to an application entity, wherein the request comprises: an application identifier; a UE identifier; an edge support service modification type flag; an edge support service session identifier; an application context transfer start time; an application context transfer completion time; an edge enabler client context relocation start time; an edge enabler client context relocation completion time; a target edge application server identifier; a target edge application server address; an edge enabler server identifier; an edge enabler server address;
However, Hall in view of Kim and further in view of Young teaches carrying relocation-control parameters corresponding to application/client ID, UE ID, relocation/session identification, target EAS/EES identifiers and addresses, and relocation timing, including a timer set for a time for performing relocation of the application service session and context-transfer/completion handling between source and target edge functions. (Young, col. 14, lines 51-60; col. 17, lines 1-13).
Further, Hall in view of Kim does not explicitly disclose using network-slice-selection-assistance information and a target data network name in the recited request, although Hall and Kim teach target-EES/target-EAS selection using target-location and target-DNAI-related routing context. (Hall, para. [0095]; Kim, paras. [0013], [0115]-[0119]) Kim also does not explicitly disclose network slice selection assistance information and a target data network name in that request: a target single network slice selection assistance information; a target data network name;
However, Hall in view of Kim and further in view of Young teaches selecting/assigning relocation context based on a MEC network slice ID, a network slice selection assistance information (NSSAI), and a data network name (DNN). (Young, col. 13, line 64-col. 14, line 8; col. 14, lines 51-60; col. 17, lines 39-41; col. 19, lines 26-30).
Further, Hall in view of Kim does not explicitly disclose an update of a predictive timer per event notification and an update of a time range per event notification, although Hall and Kim teach maximum-latency constraints, EAS-information TTL as a time interval or timer duration, and timer operation for delivered EAS information. (Hall, paras. [0111], [0138], [0210]; Kim, paras. [0063], [0120]-[0121]) Kim also does not explicitly disclose the predictive-timer/time-range phrasing: an update of a predictive timer per event notification; an update of a time range per event notification; or a combination thereof.
However, Hall in view of Kim and further in view of Young teaches configurable relocation timers, timer values indicated by NSSAI-related information, and time-bounded relocation/release control, thereby teaching updated timer and time-range information for the event-driven relocation procedure. (Young, col. 14, lines 51-60; col. 17, lines 1-13).
Accordingly, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to further modify Hall in view of Kim with Young to include known slice/DNN-based session-relocation parameters and configurable relocation timers in the modification request so that the target edge relocation is executed with the proper network-slice/data-network context and time-controlled completion/release behavior.
Doing so would have predictably improved target-server selection accuracy, policy correctness, and safe completion or release of relocation resources. (Kim, paras. [0013]-[0016], [0115]-[0121]; Young, col. 13, line 64, col. 14, line 8; col. 14, lines 51-60; col. 17, lines 1-13, 39-41).
Regarding claim 5, (Currently Amended) Hall in view of Kim does not explicitly disclose the recited pause-request timing field set, although Hall and Kim teach transferring support for a period of time with return of support at the end of the period, TTL-based validity intervals, application-context-relocation completion, and notification of updated target-EES/target-EAS information. (Hall, para. [0194]; Kim, paras. [0063], [0118]-[0121]) Kim also does not explicitly disclose the specific pause-request timing fields: The apparatus of claim 1, wherein the edge support service pause comprises a request to the application entity comprising: an application identifier; a UE identifier; an edge support service session identifier; an event notification pause time start; an event notification pause end time; an event notification pause time duration; an event notification completion time; an application context transfer completion time; an edge enabler client context relocation pause start time; an edge enabler client context relocation end time;
However, Hall in view of Kim and further in view of Young teaches time-bounded relocation control, including a timer set for a time for performing relocation, maintaining the timer for a duration of the session-relocation service, transferring application context, and releasing or returning support when the timed period has elapsed, together with TTL/time-based validity handling. (Young, col. 14, lines 51-60; col. 17, lines 1-13).
Furthermore, Hall in view of Kim and further in view of Young teaches: a target edge application server identifier; a target edge application server address; an edge enabler server identifier; an edge enabler server address; because Kim teaches target EES information, target EAS information, target EAS profile information, target EAS address, target EAS identifier, and EES identifiers/addresses exchanged and delivered during the relocation/update procedure, while Young teaches the corresponding source/target AF context for timed relocation. (Kim, paras. [0013]-[0016], [0115]-[0121]; Young, col. 17, lines 1-13).
Also, Hall in view of Kim does not explicitly disclose the predictive-timer/time-range phrasing, although Hall and Kim teach maximum-latency and TTL/time-interval control of relocation-related information. (Hall, paras. [0111], [0138], [0210]; Kim, para. [0063]) Kim also does not explicitly disclose the predictive-timer/time-range phrasing: an update of a predictive timer per event notification; an update of a time range per event notification; or a combination thereof.
However, Hall in view of Kim and further in view of Young teaches configurable timer values, timer maintenance for the relocation-service duration, and timer-based end/release control, thereby teaching updated timer and time-range information for the pause procedure. (Young, col. 14, lines 51-60; col. 17, lines 1-13). Accordingly, the rationale to further modify Hall in view of Kim with Young is the same as described in claim 4 above.
Regarding claim 6, (Currently Amended) Hall in view of Kim does not explicitly disclose transmitting a resume trigger action to the application entity, although Hall teaches returning support of the application to the application context at the end of the period of time, and Kim teaches completion/notification messaging to the EEC after relocation and target-EES/EAS update. (Hall, para. [0194]; Kim, paras. [0118]-[0121]) Kim also does not explicitly disclose a resume trigger action to the application entity: The apparatus of claim 5, wherein the at least one processor is configured to cause the apparatus to transmit an event notification resume trigger action to notify the application entity that the event notification is required to resume.
However, Hall in view of Kim and further in view of Young teaches timed relocation control in which the relevant entities are notified when the timed relocation/pause window ends so that service resumes or is released at the appropriate context. (Young, col. 14, lines 51-60; col. 17, lines 1-13). Accordingly, the rationale to further modify Hall in view of Kim with Young is the same as described in claim 4 above.
Regarding claim 19, (New) The method of claim 14, wherein the edge support service modification comprises a request to an application entity, wherein the request comprises: an application identifier; a UE identifier; an edge support service modification type flag; an edge support service session identifier; an application context transfer start time; an application context transfer completion time; an edge enabler client context relocation start time; an edge enabler client context relocation completion time; a target edge application server identifier; a target edge application server address; an edge enabler server identifier; an edge enabler server address; a target single network slice selection assistance information; a target data network name; an update of a predictive timer per event notification; an update of a time range per event notification; or a combination thereof.
Claim 19 is analogous to claim 4 and therefore, claim 19 is rejected for the same reasons set forth.
Regarding claim 20, (New) The method of claim 14, wherein the edge support service pause comprises a request to the application entity comprising: an application identifier; a UE identifier; an edge support service session identifier; an event notification pause time start; an event notification pause end time; an event notification pause time duration; an event notification completion time; an application context transfer completion time; an edge enabler client context relocation pause start time; an edge enabler client context relocation end time; a target edge application server identifier; a target edge application server address; an edge enabler server identifier; an edge enabler server address; an update of a predictive timer per event notification; an update of a time range per event notification; or a combination thereof.
Claim 20 is analogous to claim 5 and therefore, claim 20 is rejected for the same reasons set forth.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHONGSUH (John) PARK whose telephone number is 408-918-7574. The examiner can normally be reached Monday - Friday 8:00-5:30 PST
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, Avellino, Joseph can be reached at 571-272-3905 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.
/CHONGSUH PARK/Examiner, Art Unit 2478
/JOSEPH E AVELLINO/Supervisory Patent Examiner, Art Unit 2478