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 .
Remarks
The present Office Action is in response to Applicant’s amendment filed on 12/29/2025. Claims 1-3, 5-7, 9-12, 14-16, 18-20, , 22, 32, and 34 are still pending in the present application. This Action is made FINAL.
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.
Claim(s) 1-3, 5, 6, 9-11, 14-16, 18, 19, 22, 32 and 34 is/are rejected under 35 U.S.C. 103 as being unpatentable over ZAUS et al. -US 20220321673 A1- (hereinafter Zaus) in view of CHIBA et al. -US 20210100047 A1- (hereinafter Chiba).
Regarding claim 1, Zaus discloses a method performed by an edge enabler client, comprising:
detecting that application context relocation (ACR) is required (par. 0043, “Whenever one of the entities detects a need for ACR, the entity may attempt to initiate ACR.”);
setting an information element indicating (par. 0003, “a message comprising a first indication that the AC requires service continuity support”; par. 0005, “receiving, from an edge enabler client (EEC) of a user equipment (UE), a second message that an application client (AC) of the UE requesting service from one or more edge data networks (EDN) requires service continuity support from the one or more EDNs,”); and
sending the ACR request message to an edge enabler server (par. 0003, and par. 0005, “receiving, from an edge enabler client (EEC) of a user equipment (UE), a second message that an application client (AC) of the UE requesting service from one or more edge data networks (EDN) requires service continuity support from the one or more EDNs”).
However, Zaus fails to disclose setting an information element indicating a type of service continuity in a
In the same field of endeavor, Chiba discloses setting an information element indicating a type of service continuity in a request message (par. 0104, “the Mobility Type may be the information to indicate the type of Service Continuity, may be the information to indicate the type of Mobility to be supported…”).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate information to indicate the type of Service Continuity as taught by Chiba to the message comprising an indication requiring service continuity support for one or more application context relocation (ACR) methods as disclosed by Zaus for purpose of providing information to indicate the type of Service Continuity.
Regarding claim 2, as applied to claim 1 above, Zaus discloses wherein the edge enabler server is a source edge enabler server (par. 0021, “an ACR procedure may involve an AC of the UE, an edge enabler client (EEC) of the UE, a source edge enabler server (s-EES), a s-EAS, a target EES (t-EES) and a t-EAS”; FIG. 4 for s-EES 174, par. 0056).
Regarding claim 3, as applied to claim 2 above, Zaus discloses wherein the ACR is executed by the edge enabler client via the source edge enabler server, or wherein the ACR is executed by the source edge enabler server (par. 0021, “an ACR procedure may involve an AC of the UE, an edge enabler client (EEC) of the UE, a source edge enabler server (s-EES)…”; FIG. 4 for EEC 240, par. 0056).
Regarding claim 5, as applied to claim 1 above, Zaus discloses wherein the edge enabler server is a target edge enabler server (par. 0021, “an ACR procedure may involve an AC of the UE, an edge enabler client (EEC) of the UE, a source edge enabler server (s-EES)…”; FIG. 4 for t-EES 404, par. 0056).
Regarding claim 6, as applied to claim 5 above, Zaus discloses wherein the ACR is executed by the edge enabler client via the target edge enabler server (FIG. 4, par. 0053, “In 415b, the EES 404 registers with the ECS 180. Like in the example provided above, during EES registration, the EES 404 may send one or more messages to the ECS 180 comprising a service continuity supported indication, an indication of the supported ACR methods at the EES 404 itself and, optionally, an indication of supported EEC context transfer methods at the EES 404 itself.”).
Regarding claim 9, as applied to claim 1 above, Chiba discloses wherein the type of service continuity comprises at least one of: a service continuity planning, or a normal service continuity (par. 0191, “the Session and Service Continuity (SSC) mode may be a mode indicating the type of the Session and Service Continuity… the SSC mode may be a mode indicating the type of the Session and Service Continuity set for each PDU session. In addition, the SSC mode may include the following three modes: an SSC mode 1; an SSC mode 2; and an SSC mode 3.” Any of SSC mode 1, mode 2 and/or mode 3 can be considered as a service continuity planning, or a normal service continuity).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate information to indicate the type of Service Continuity as taught by Chiba to the message comprising an indication requiring service continuity support for one or more application context relocation (ACR) methods as disclosed by Zaus for purpose of providing information to indicate the type of Service Continuity.
Regarding claim 10, Zaus discloses a method performed by an edge enabler server (see FIG. 3 and FIG. 4 for edge enabler server (EES)), comprising:
determining that application context relocation (ACR) is required (par. 0043, “Whenever one of the entities detects a need for ACR, the entity may attempt to initiate ACR.”);
setting an information element indicating a (par. 0005, “from one or more edge enabler servers (EESs), a first message comprising a first indication indicating whether each EES supports service continuity and one or more application context relocation (ACR) methods supported by each of the EESs that support service continuity…”); and
sending the notify message for the ACR to an edge application server (par. 0058, “the s-EES 174 may send one or more messages to the t-EES 404 comprising a service continuity supported indication and an indication of the supported ACR methods at the AC 235, EEC 240, s-EES 174 and s-EAS 172.”).
However, Zaus fails to setting an information element indicating a type of service continuity in a notify message.
In the same field of endeavor, Chiba discloses setting an information element indicating a type of service continuity in a notify message (par. 0104, “the Mobility Type may be the information to indicate the type of Service Continuity, may be the information to indicate the type of Mobility to be supported…”).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate information to indicate the type of Service Continuity as taught by Chiba to the message comprising an indication requiring service continuity support for one or more application context relocation (ACR) methods as disclosed by Zaus for purpose of providing information to indicate the type of Service Continuity.
Regarding claim 11, as applied to claim 10 above, Zaus discloses wherein determining that ACR is required comprises: receiving an ACR request message comprising the information element indicating the type of service continuity from an edge enabler client; and determining that the ACR is required based on the ACR request message comprising the information element indicating the type of service continuity (par. 0057, “In response, the EES 174 may send a discovery response to the EEC 240 to provide information that explicitly or implicitly indicates an address for the EAS 172.”).
Chiba discloses the information element indicating a type of service continuity (par. 0104, “the Mobility Type may be the information to indicate the type of Service Continuity, may be the information to indicate the type of Mobility to be supported…”).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate information to indicate the type of Service Continuity as taught by Chiba to the message comprising an indication requiring service continuity support for one or more application context relocation (ACR) methods as disclosed by Zaus for purpose of providing information to indicate the type of Service Continuity.
Regarding claim 14, as applied to claim 10 above, Zaus discloses wherein determining that ACR is required comprises: detecting that the ACR is required; and determining that ACR is required based on the detection (“Whenever one of the entities detects a need for ACR, the entity may attempt to initiate ACR.”).
Regarding claim 15, as applied to claim 10 above, Zaus discloses wherein the edge enabler server is a source edge enabler server and the edge application server is a source edge application server (par. 0021 for source edge enabler server (s-EES) and s-EAS… ).
Regarding claim 16, as applied to claim 15 above, Zaus discloses wherein the ACR is executed by an edge enabler client via the source edge enabler server, or wherein the ACR is executed by the source edge enabler server (FIG. 4 par. 0058).
Regarding claim 18, as applied to claim 10 above, Zaus discloses wherein the edge enabler server is a target edge enabler server and the edge application server is a target edge application server (see FIG. 4).
Regarding claim 19, as applied to claim 18 above, Zaus discloses wherein the ACR is executed by an edge enabler client via the target edge enabler server (FIG. 4, par. 0058).
Regarding claim 22, as applied to claim 10 above, Zaus discloses herein the type of service continuity comprises at least one of: a service continuity planning, or a normal service continuity (par. 0191, “the Session and Service Continuity (SSC) mode may be a mode indicating the type of the Session and Service Continuity… the SSC mode may be a mode indicating the type of the Session and Service Continuity set for each PDU session. In addition, the SSC mode may include the following three modes: an SSC mode 1; an SSC mode 2; and an SSC mode 3.” Any of SSC mode 1, mode 2 and/or mode 3 can be considered as a service continuity planning, or a normal service continuity).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate information to indicate the type of Service Continuity as taught by Chiba to the message comprising an indication requiring service continuity support for one or more application context relocation (ACR) methods as disclosed by Zaus for purpose of providing information to indicate the type of Service Continuity.
Regarding claim 32, Zaus discloses an edge enabler client, comprising:
a processor; and a memory coupled to the processor, said memory containing instructions executable by said processor, whereby said edge enabler client is operative to (FIG. 2, par. 0097):
detect that application context relocation (ACR) is required (par. 0043, “Whenever one of the entities detects a need for ACR, the entity may attempt to initiate ACR.”);
set an information element indicating a (par. 0003, “a message comprising a first indication that the AC requires service continuity support”; par. 0005, “receiving, from an edge enabler client (EEC) of a user equipment (UE), a second message that an application client (AC) of the UE requesting service from one or more edge data networks (EDN) requires service continuity support from the one or more EDNs,”); and
send the ACR request message to an edge enabler server (par. 0003, and par. 0005, “receiving, from an edge enabler client (EEC) of a user equipment (UE), a second message that an application client (AC) of the UE requesting service from one or more edge data networks (EDN) requires service continuity support from the one or more EDNs”).
However, Zaus fails to disclose set an information element indicating a type of service continuity in a
In the same field of endeavor, Chiba discloses set an information element indicating a type of service continuity in a request message (par. 0104, “the Mobility Type may be the information to indicate the type of Service Continuity, may be the information to indicate the type of Mobility to be supported…”).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate information to indicate the type of Service Continuity as taught by Chiba to the message comprising an indication requiring service continuity support for one or more application context relocation (ACR) methods as disclosed by Zaus for purpose of providing information to indicate the type of Service Continuity.
Regarding claim 34, Zaus discloses an edge enabler server, comprising:
a processor; and a memory coupled to the processor, said memory containing instructions executable by said processor, whereby said edge enabler server is operative to (par. 0097):
determine that application context relocation (ACR) is required (par. 0043, “Whenever one of the entities detects a need for ACR, the entity may attempt to initiate ACR.”);
set an information element indicating a (par. 0005, “from one or more edge enabler servers (EESs), a first message comprising a first indication indicating whether each EES supports service continuity and one or more application context relocation (ACR) methods supported by each of the EESs that support service continuity…”); and
send the notify message for the ACR to an edge application server (par. 0058, “the s-EES 174 may send one or more messages to the t-EES 404 comprising a service continuity supported indication and an indication of the supported ACR methods at the AC 235, EEC 240, s-EES 174 and s-EAS 172.”).
However, Zaus fails to set an information element indicating a type of service continuity in a notify message.
In the same field of endeavor, Chiba discloses set an information element indicating a type of service continuity in a notify message (par. 0104, “the Mobility Type may be the information to indicate the type of Service Continuity, may be the information to indicate the type of Mobility to be supported…”).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate information to indicate the type of Service Continuity as taught by Chiba to the message comprising an indication requiring service continuity support for one or more application context relocation (ACR) methods as disclosed by Zaus for purpose of providing information to indicate the type of Service Continuity.
Allowable Subject Matter
Claim(s) 7, 12 and 20 is/are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Response to Arguments
Applicant's arguments filed 12/29/2025 have been fully considered but they are not persuasive.
On page 4 of the Applicant’s remarks, Applicant asserts, “Zaus teaches determining that ACR is needed and indicates that service continuity support is required. Zaus is only prior art based on a provisional application filed a few weeks before this present application. If the Patent Office continues to use this reference, Applicant respectfully requests that references to Zaus be to the priority document, or that references be provided to where the priority document supports the used sections.” Examiner provided the provisional application of Zaus as attachment to the current Office Action (see sections 8.5.2.2, 8.8.2.3, 8.8.3.7, 8.8.4) .
Applicant further argues, “Chiba's "Mobility Type" is part of a network-level mobility context used to manage PDU session continuity. This is fundamentally different from the application-level service continuity for an application context as claimed. As such, this fails to teach the claimed features. As such, the combination of Zaus and Chiba fails to teach the claimed features. Therefore, claim 1 is allowable over the combination of Zaus and Chiba.” Examiner respectfully disagrees. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Applicant further argues, “the combination of Zaus and Chiba is an improper combination of non-analogous art. Zaus is directed to application-layer signaling for Edge Computing. Chiba is directed to network-layer mobility and Core Network session management. These documents use similar terms. But they do not refer to the same concepts. Gluing these separate concepts together appears to be using the Applicant's Specification as a roadmap. This is a form of impermissible hindsight reasoning. As such, the combination of Zaus and Chiba is improper. Therefore, claim 1 is allowable over the combination of Zaus and Chiba.” Examiner respectfully disagrees.
In response to applicant's argument that Chiba is nonanalogous art, it has been held that a prior art reference must either be in the field of the inventor’s endeavor or, if not, then be reasonably pertinent to the particular problem with which the inventor was concerned, in order to be relied upon as a basis for rejection of the claimed invention. See In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 1992). In this case, Chiba discloses a message (such as a handover message) to include information to indicate the type of Service Continuity. Zaus discloses a message that includes different indications. Thus, it would it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate information to indicate the type of Service Continuity as taught by Chiba to the message comprising an indication requiring service continuity support for one or more application context relocation (ACR) methods as disclosed by Zau for purpose of providing information to indicate the type of Service Continuity. See MPEP 2143 for:
Examples of rationales that may support a conclusion of obviousness include:
(A) Combining prior art elements according to known methods to yield predictable results;
(B) Simple substitution of one known element for another to obtain predictable results;
(C) Use of known technique to improve similar devices (methods, or products) in the same way;
(D) Applying a known technique to a known device (method, or product) ready for improvement to yield predictable results;
(E) “Obvious to try” – choosing from a finite number of identified, predictable solutions, with a reasonable expectation of success;
(F) Known work in one field of endeavor may prompt variations of it for use in either the same field or a different one based on design incentives or other market forces if the variations are predictable to one of ordinary skill in the art;
(G) Some teaching, suggestion, or motivation in the prior art that would have led one of ordinary skill to modify the prior art reference or to combine prior art reference teachings to arrive at the claimed invention.
Applicant’s arguments with regards to other independent claims and dependent claims (see page 5 of the Applicant’s arguments/remarks) are not persuasive since claims is/are similar to or include(s) similar features of claim 1. Therefore, Examiner refers to the same reason(s) stated above for rejecting claim 1 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicant’s disclosure.
Hu et al. -US 20240040005 A1- disclose CONTEXT TRANSFER METHOD AND COMMUNICATION APPARATUS.
THIS ACTION IS MADE FINAL. 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 ALLAHYAR KASRAIA N whose telephone number is (571)270-1772. 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, RAFAEL PEREZ-GUTIERREZ can be reached at (571)272-7915. 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.
/ALLAHYAR KASRAIA N/Primary Examiner, Art Unit 2642