DETAILED ACTION
The amendment to Application Ser. No. 18/472,485 filed on November 13, 2025, has been entered. Claims 1-4 are cancelled. Claims 5, 7 and 9-11 are currently amended. New Claim 12 is added. Claims 5-12 are pending and are examined.
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 .
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 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.
Response to Arguments
The amendment of Claim 5 has obviated the claim interpretation of Claims 5-8 set forth in the Non-Final Office Action mailed October 13, 2025, by requiring occurrence of the condition on which the claim limitations are contingent.
The amendment to Claims 5 and 11 has overcome the objection to the claims for minor informalities set forth in the Non-Final Office Action mailed August 13, 2025. The objection to the claims for minor informalities is hereby withdrawn.
The amendment to Claims 5, 7 and 9 has overcome the rejection of Claims 5-11 under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or joint inventor regards as the invention set forth in the Non-Final Office Action mailed August 13, 2025. New grounds of rejection under 35 U.S.C. 112(b), necessitated by the amendment, are set forth in this Office Action.
The amendment to Claim 5 has overcome the rejection of Claims 5-11 under 35 U.S.C. 103 set forth in the Non-Final Office Action mailed August 13, 2025. New grounds of rejection under 35 U.S.C. 103, necessitated by the amendment, are set forth in this Office Action.
Claim Rejections - 35 USC § 112(b)
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 9-11 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 9 recites the limitation “the fifth generation core network (5GC)” in line 3. While “a fifth generation core network (5GC) procedure (emphasis added)” is introduced in Claim 5, there is insufficient antecedent basis for the term “the fifth generation core network (5GC)” in the claims.
Additionally, Claim 9 recites the limitation “the EAS that is resident in the EDN for performing server functions” in line 11. There is insufficient antecedent basis for the term “the EAS that is resident in the EDN for performing server functions” in the claims.
Dependent Claims 10 and 11 are rejected for the reasons presented above with respect to rejected Claim 9 in view of their dependence thereon.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 5-8 and 12 are rejected under 35 U.S.C. 103 as being unpatentable Yao et al., Pub. No. US 2024/0187303 A1, hereby “Yao”, in view of Xu, Pub. No. US 2025/0310740 A1, and in further view of 3rd Generation Partnership Project (3GPP) Technical Requirement 23.700-98 V.18.0.0, hereby “3GPP”.
Regarding Claim 1, Yao discloses “A method for enabling multi-operator edge environment (Yao fig. 3 and paragraphs 7 and 121-122: a method for obtaining an edge service), the method comprising:
running an Application Client (AC) on a User Equipment (UE) and sending application context of the AC to an Edge Enabler Client (EEC) via an EDGE 5 reference point (Yao figs. 2 and 3 and paragraphs 114-118 and 133-134: an AC residing on a UE communicates with an EEC via an EDGE-5 interface to obtain EAS information – while not explicitly stated, it is readily understood by one of ordinary skill that the obtaining includes providing information about a requested application, i.e., application context, to the EEC);
adding EEC context via the EEC before sending a service provisioning request to an Edge Configuration Server (ECS) (Yao paragraphs 17, 118 and 132-134: a service provisioning request includes at least one of a PLMN identifier, an edge computing service provider (ECSP) identifier, and location information of the UE, i.e., EEC context – while not explicitly stated, it is readily understood by one of ordinary skill that this information is added to the service provisioning request by the EEC);
performing ECS discovery by sending the application context and the EEC context to a first Edge Configuration Server (ECS1) for service provisioning, wherein an address of the ECS1 is preconfigured with the EEC or provisioned by a Mobile Network Operator (MNO) through a fifth generation core network (5GC) procedure (Yao fig. 2 and paragraphs 3-4, 16, 115 and 117: the EEC obtains address information of a first ECS that has been preconfigured with the ECC or provided to the EEC by the network operator during session establishment);
sending the service provisioning request from the EEC to the ECS1 via an EDGE 4 reference point, wherein the ECS1 searches for an appropriate Edge Data Network (EDN) in order to support an AC requirement, which comprises service needs of the AC (Yao figs. 2 and 3 and paragraph 16, 115-118, 132-133 and 171: the first device, i.e., the EEC, sends a service provisioning request to the first ECS via the EDGE-4 interface in step S101);
determining, by the ECS1, that the AC requirement is not fulfilled by the ECS1 (Yao fig. 3 and paragraphs 12, 15, 114, 122-130 and 135: the first ECS determines that the first ECS cannot provide the requested edge service to the UE); and
in response to the AC requirement being unable to be fulfilled by the ECS1, implementing a federated edge configuration process (Yao fig. 3 and paragraphs 12, 123, 130, 135, 141 and 149-154: in response to the determination that the first ECS cannot provide the requested edge service, the first ECS initiates an ECS discovery function provided by a federation control network element, i.e., an F-ECS), which comprises:
contacting a Federated Edge Configuration Server (F-ECS) via the ECS1, wherein an Edge Service Provider (ESP) associated with the ECS1 has a service agreement with the F-ECS, and wherein the F-ECS maintains service agreements with other ECS provider networks (Yao fig. 3 and paragraphs 11-12 and 149-154: the first ECS sends queries the federation control network element for a second ECS by sending first request information to a federation control network element with which the first ECS and other ECS have registered); and
“returning, by the F-ECS, an address of the ECSn with the suitable EDN, to the ECS1 (Yao fig. 3 and paragraphs 11, 114, 123, 135, 149-154 and 159: the federation control network element sends response information including information about the second ECS that can provide the requested edge service to the first ECS);
forwarding the service provisioning request from the EEC to the ECSn via the ECS1, wherein the ECSn sends suitable EDN information to the EEC via the EDGE 4 reference point (Yao fig. 3 and paragraphs 14, 114, 162-166 and 170-171: the first ECS sends second request information to the second ECS requesting information of an EES that can provide the requested edge service, and the second ECS sends second response information including information about a first EES that can provide the requested edge service to the first ECS, and the first ECS provides information of the second ECS to the EEC of the terminal device);
transferring the EEC to the ECSn, wherein the EEC sends a request to a suitable Edge Enabler Server (EES) within the suitable EDN information provided by the ECSn via an EDGE 1 reference point (Yao fig. 3 and paragraphs 3, 118 and 171: the EEC sends a request to the second ECS to obtain the information about the first EES that can provide the requested edge service); and
registering the EEC onto the suitable EES, and sending, by the EEC, an Edge Application Server (EAS) discovery request, which enables the EEC to establish a QoS session and data traffic with a suitable EAS to serve the service needs of the AC (Yao fig. 3 and paragraphs 3, 118 and 171: after receiving information about the first EES, the EEC sends an EAS discovery request to the first EES to obtain address information of the EAS providing the requested edge service in order to access the edge service).”
However, while Yao discloses that the federation control network element performs an ECS discovery function to identify information about a second ECS that can provide the requested edge service (Yao paragraphs 11-12, 141 and 149-159), Yao does not explicitly disclose “searching, by the F-ECS, for another ECS provider network via an EDGE 20 reference point;
iteratively contacting additional ECS provider networks by the F-ECS until locating an ECSn with a suitable EDN that fulfills the AC requirement”.
In the same field of endeavor, Xu discloses “searching, by the F-ECS, for another ECS provider network... (Xu figs. 6 and 9 and paragraphs 81, 105-108 and 128-134: using the edge service federation, a first ECS, i.e., ECS 103 of OP-B, discovers another ECS of a partner operator platform, i.e., ECS 603 of OP-A) that may have a suitable EES for providing the requested service – while not explicitly stated, it is readily understood by one of ordinary skill that the T-EES discovery shown in Figure 9 involves contacting the partner ECS);
iteratively contacting additional ECS provider networks by the F-ECS until locating an ECSn with a suitable EDN that fulfills the AC requirement (Xu figs. 6 and 9 and paragraph 135: the first ECS may have SLA with multiple other operator platforms and may perform T-EES discovery repeatedly with more than one partner operator platform to discover an ECS having a suitable EES for providing the requested service)”.
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the method of Yao to contact, by the federation control network element, partner ECSs until a partner ESC having a EES that can provide the requested edge service is found as taught by Xu because doing so constitutes a simple substitution of one known element (searching profiles of registered ECS for a suitable ECS) for another (contacting partner ECSs until a partner ECS having a suitable EES is found) to obtain predictable and desirable results (identifying an ECS having an EES that can provide the requested edge service). See KSR International Co. v. Teleflex Inc., 82 USPQ2d 1385 (U.S. 2007).
However, while Yao discloses a federation control network element in communication with one or more ECS (Yao fig. 3 and paragraphs 11-12 and 149-159) and Xu discloses contacting partner ECSs until a partner ECS having an EES that can provide a requested service is found (Xu paragraphs 134-135), the combination of Yao and Xu does not explicitly disclose “searching, by the F-ECS, for another ECS provider network via an EDGE 20 reference point (emphasis added)”.
In the same field of endeavor, 3GPP discloses an edge application architecture an independent server hosting Central AC Association Repository (CAAR) functionality communicates with multiple ECSs via EDGE-20 interface (3GPP fig. 6.11.1-1 and § “6.11 Option #11: EDGEAPP architecture enhanced with Central AC Association Repository”).
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the method of Yao, as modified by Xu, to communicate, by the federation control network element, with a plurality of ECS via EDGE-20 interface as taught by 3GPP because doing so constitutes applying a known technique (using EDGE-20 interface for communication between ECS and independent server hosting repository functionality) to known devices and/or methods (a federation control network element) ready for improvement to yield predictable and desirable results (enabling communication between the federation control network element and ECS). See KSR International Co. v. Teleflex Inc., 82 USPQ2d 1385 (U.S. 2007).
Regarding Claim 6, the combination of Yao, Xu and 3GPP discloses all of the limitations of Claim 5.
Additionally, Xu suggests “determining a list of all available ECS of Edge Service Providers (ESPs) (Xu paragraphs 113-114 and 134-135: “Note that, the ECS 103 of the OP-B may have SLA with other multiple OPs and thus may perform step 3 repeatedly with more than one partner OP in order to discover the T-EES.” – while not explicitly stated, it is readily understood by one of ordinary skill that a set or list of ECSs to contact is necessarily determined by the first ECS in order for the first ECS to repeat T-EES discovery with the ECS of each of the partner OP).”
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the method of Yao to contact, by the federation control network element, partner ECSs until a partner ESC having a EES that can provide the requested edge service is found as taught by Xu for the reasons set forth in the rejection of Claim 5.
Regarding Claim 7, the combination of Yao, Xu and 3GPP discloses all of the limitations of Claim 5.
Additionally, Yao discloses “wherein a target ECS is selected based on the service needs of the AC (Yao paragraphs 154 and 158: the second ECS is determined by matching the feature information of the EES requested by the EEC with an EES managed by the second ECS).”
Regarding Claim 8, the combination of Yao, Xu and 3GPP discloses all of the limitations of Claim 5.
Additionally, Yao discloses “further comprising obtaining an IP address of a selected ECS (Yao paragraph 172: the information of the second ECS provided to the first ECS by the federation control network element may be an IP address).”
Regarding Claim 12, the combination of Yao, Xu and 3GPP discloses all of the limitations of Claim 5.
Additionally, Yao discloses “determining, by the ECS1, that the AC requirement is fulfilled by the ECS1 (Yao paragraphs 3 and 118: while not explicitly stated, it is readily understood by one of ordinary skill that the first ECS may determine that the first ECS can provide the requested edge service to the UE);
in response to the AC requirement being fulfilled by the EVS1, sending information associated with the EDN to the AC (Yao paragraphs 3 and 118: while not explicitly stated, it is readily understood by one of ordinary skill that the first ECS provides address information of the EES that can provide the requested edge service to the AC when the first ESC has an EES that can provide the requested service).”
Claims 9-11 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Yao, Xu and 3GPP in further view of the paper authored by Patel et al., titled “Standardization aspects of Tactile applications on Multi-access Edge Computing”, hereby “Patel”.
Regarding Claim 9, the combination of Yao, Xu and 3GPP discloses all of the limitations of Claim 5.
Additionally, Yao discloses “A system adapted to perform the method for enabling multi-operator edge environment according to claim 5 (Yao figs. 1-3 and paragraphs 91-92 and 114: edge service architecture 200 implemented within network system architecture 100), wherein the system comprises:
the fifth generation core network (5GC) (Yao figs. 1 and 2 and paragraphs 93-94 and 116: system architecture 100 may comprise a 5G core network);
the Mobile Network Operator (MNO) that provides wireless network services (Yao figs. 1 and 2 and paragraphs 3-4 and 89-104: while not explicitly stated, it is readily understood by one of ordinary skill that the elements comprising network system architecture 100 are owned, managed and/or controlled by a mobile network operator);
a RAN-radio access network (RAN) that connects individual network devices through radio connections (Yao fig. 1 and paragraphs 93-94: a RAN);
an evolved Global System for Mobile communication (GSM) core network infrastructure (Yao paragraphs 89, 94 and 116: system architecture 100 may comprise a GSM system);” and
“User Equipment (UE) that allows a user access to network services having no access to the 5GC (Yao figs. 1 and 2 and paragraphs 104 and 114: a UE comprising an application client);
the EAS that is resident in the EDN for performing server functions (Yao fig. 2 and paragraphs 110 and 114: an EDN including an EES and a plurality of EAS);
a plurality of Edge Configuration Servers (ECS) (Yao figs. 2-3 and paragraphs 109, 114 and 121-123: a plurality of ECS); and
the Federated Edge Configuration Server (F-ECS) (Yao fig. 3 and paragraph 151: the federation control network element).”
However, while Yao discloses that the edge service network may be applied to machine-to-machine communication, device-to-device (D2D) networks, an Internet of Things (IoT) network or another network and that the devices connected to the network may include a wireless terminal in telemedicine (Yao paragraphs 90 and 104), the combination of Yao, Xu and 3GPP does not explicitly disclose wherein the system comprises “a haptic glove that provides simulation of tactile sensations”.
In the same field of endeavor, Patel discloses MEC environment in which a robotic hand is controlled using a haptic glove (Patel figs. 1 and 2, Abstract, § "I. INTRODUCTION" and "III. HAPTICS: TELESURGERY USE CASE”)": haptic glove (HG) communicates with robotic hand (RH) using a 5G-MEC network)”.
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the system of Yao, as modified by Xu and 3GPP, to include a haptic glove and robotic hand in the edge service architecture as taught by Patel. One of ordinary skill in the art would have been motivated to combine utilizing a haptic glove and robotic hand in the edge service architecture to provide the ultra-low latency required by telesurgery and other next generation Tactile Internet applications (Patel § "I. INTRODUCTION" and "III. HAPTICS: TELESURGERY USE CASE”).
Regarding Claim 10, the combination of Yao, Xu, 3GPP and Patel discloses all of the limitations of Claim 9.
Additionally, Patel discloses “wherein the UE is implemented as a robotic hand (Patel figs. 1 and 2, Abstract, § "I. INTRODUCTION" and "III. HAPTICS: TELESURGERY USE CASE”)": a robotic hand (RH), which is a UE connected to the 5G-MEC network).
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the system of Yao, as modified by Xu and 3GPP, to include a haptic glove and robotic hand in the edge service architecture as taught by Patel for the reasons set forth in the rejection of Claim 9.
Regarding Claim 11, the combination of Yao, Xu, 3GPP and Patel discloses all of the limitations of Claim 10.
Additionally, Patel discloses “wherein the haptic glove is operatively connected to one of a plurality of Edge Application Servers (EAS) for providing simulation of tactile sensations for the robotic hand (Patel figs. 1 and 2, Abstract, § "I. INTRODUCTION" and "III. HAPTICS: TELESURGERY USE CASE”)": a haptic glove (HG), which provides tactile sensations for the robotic hand).”
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the system of Yao, as modified by Xu and 3GPP, to include a haptic glove and robotic hand in the edge service architecture as taught by Patel for the reasons set forth in the rejection of Claim 9.
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WILLIAM C MCBETH whose telephone number is (571)270-0495. The examiner can normally be reached on Monday - Friday, 8:00AM - 4:30PM ET.
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, Vivek Srivastava can be reached on 571-272-7304. 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.
/WILLIAM C MCBETH/Examiner, Art Unit 2449
/VIVEK SRIVASTAVA/Supervisory Patent Examiner, Art Unit 2449