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 .
DETALIED ACTION
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 10/14/2025 has been entered.
The amendment filed 10/14/2025 has been entered. Claims 61, 63-66, 70-77, 82, 86, 88-89, and 91-92 are pending. Claims 61, 65, 66, 70, 74, 77, 82, 88, 91 and 92 have been amended. No new claim is added.
Allowable Subject Matter
Claim 65 is 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 with respect to claim(s) 61, 63-64, 66, 70-77, 82, 86, 88-89, and 91-92 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
In addition, the applicant argued that MEC 5G does not teach or suggest " prepare a common API framework (CAPIF) publish service API including (i) a protocol data type to identify a protocol used by the MEC service API and (ii) a transport data type to identify a first transport protocol used to expose the MEC service API, the transport data type different from the protocol data type.”
In response to the applicant’s argument MEC 5G teaches in Table 5.6.2.4.1-1: MEC type "Servicelnfo" that includes the name of the protocol used and Clause 5.6.2.4 provides the relevant HTTP message body data types defined by CAPIF and MEC for API discovery, publication and announcement. Referenced named types are folded in to provide comprehensive information about the attribute sets that are available in each message body. This information can be used to define guidelines or provisions how MEC services can be published, discovered and announced using CAPIF replacing the service management part of ETSI GS MEC O 11 [i.10], page 31, paragraph 2) and in Table 5.6.2.4.1-1: MEC type "Servicelnfo" that includes Identifier of the platform-provided transport to be used by the service. Valid identifiers may be obtained using the "Transport information query" procedure), the transport data type different from the protocol data type (i.e. the name of the protocol and identifier of the transport used by the service are different).
In addition, MEC 5G teaches the MEC reference point Mpl supports publication of MEC services ("M-Publication"), discovery/announcement of MEC services ("M-Discovery") and further MEC application support ("Support") such as activation of traffic rules. The CAPIF core function supports publication ("C-Publication") and discovery ("C-Discovery") of CAPIF APis. The simplest integration possibility is to publish the MEC service APis via CAPIF, page 11, paragraph 2 and Fig. 4.3.2-1.
Therefore, MEC 5G prepares a CAPIF to publish service API such as MEC service API via CAPIF by including protocol and transport information.
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.
Claim(s) 61, 63-64, 66, 70-77, 82, 86, 88-89, and 91-92 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sophia Antipolis (Functional architecture and information flows to support Common API Framework for 3GPP Northbound APIs; 3GPP TS 23.222 v17.3.0 2020-12) hereinafter Sophia in view of Multi-access Edge Computing (MEC) MEC 5G Integration ETSI GR MEC 031 V2.1.1 (2020-10) hereinafter MEC 5G and RAJADURAI et al. (US 20190149576) hereinafter RAJADURAI and further in view of FILIPPOU et al. (US 20220353732) hereinafter FILIPPOU.
Regarding claim 61, Sophia teaches access, over a first reference point, information to advertise a plurality of application programming interfaces (APIs) exposed by a first edge computing platform (ECP), the first ECP to implement a first edge computing technology (ECT) including multi-access edge computing (MEC) (i.e. MEC, page 112, paragraph 1 and Table D-1, the API publishing function enables the API provider to publish the service APis information in order to enable the discovery of service APis by the API invoker. The API publishing function consists of the following capability: Publishing the service API information of the API provider to the CAPIF core function, page 27, paragraph 3 and the service API aspects of the 3 GPP network services and capabilities such as subscriber management, mobility management, transport and other communication services can be exposed for consumption by external 3rd party applications (e.g. API invoker), page 10, paragraph 4), the set of APIs including a MEC service API (i.e. API framework (CAPIF) is organized into functional entities to describe a functional architecture which enables an API invoker to access and invoke service APis, page 20, paragraph 4 and MEC API, page 112, paragraph 1).
However, Sophia does not explicitly disclose prepare a common API framework (CAPIF) publish service API including (i) a protocol data type to identify a protocol used by the MEC service API and (ii) a transport data type to identify a first transport protocol used to expose the MEC service API, the transport data type different from the protocol data type.
However, MEC 5G teaches prepare a common API framework (CAPIF) publish the service API including (i) a protocol data type to identify a protocol used by the MEC service API (i.e. in Table 5.6.2.4.1-1: MEC type "Servicelnfo" that includes the name of the protocol used and Clause 5.6.2.4 provides the relevant HTTP message body data types defined by CAPIF and MEC for API discovery, publication and announcement. Referenced named types are folded in to provide comprehensive information about the attribute sets that are available in each message body. This information can be used to define guidelines or provisions how MEC services can be published, discovered and announced using CAPIF replacing the service management part of ETSI GS MEC O 11 [i.10], page 31, paragraph 2) and (ii) a transport data type to identify a first transport protocol used to expose the MEC service API (i.e. in Table 5.6.2.4.1-1: MEC type "Servicelnfo" that includes Identifier of the platform-provided transport to be used by the service. Valid identifiers may be obtained using the "Transport information query" procedure), the transport data type different from the protocol data type (i.e. the name of the protocol and identifier of the transport used by the service are different). In addition, MEC 5G teaches the MEC reference point Mpl supports publication of MEC services ("M-Publication"), discovery/announcement of MEC services ("M-Discovery") and further MEC application support ("Support") such as activation of traffic rules. The CAPIF core function supports publication ("C-Publication") and discovery ("C-Discovery") of CAPIF APis. The simplest integration possibility is to publish the MEC service APis via CAPIF, page 11, paragraph 2 and Fig. 4.3.2-1. Therefore, MEC 5G prepares a CAPIF to publish service API such as MEC service API via CAPIF by including protocol and transport information.
Based on Sophia in view of MEC 5G, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of MEC 5G to the system of Sophia in order to support better operation while maintaining security and privacy of operator's network, (MEC 5G, page 9, paragraph 1).
However, Sophia in view of MEC 5G do not explicitly disclose at least one non-transitory computer readable medium comprising instructions to cause at least one processor circuit to at least: the plurality of APIs including a transport discovery API; based on the CAPIF publish service API, expose, to a second ECP over a second reference point, at least the MEC service API and the transport discovery API exposed by the first ECP, the second ECP to implement a second ECT including the CAPIF, the transport discovery API to provide access to a plurality of different transport protocols available to expose a plurality of service APIs, the plurality of different transport protocols including the first transport protocol associated with the MEC service API, the first transport protocol not supported by the second ECT.
However, RAJADURAI teaches at least one non-transitory computer readable medium comprising instructions to cause at least one processor circuit to at least (i.e. a non-transitory computer readable medium includes media where data can be permanently stored, one or more computer programs, software components, sets of instructions accessed by a computer [0022]): the plurality of APIs including a transport discovery API (i.e. subscribed APIs includes Interface details (such as IP address/port), Protocol between the AEF 108 and the API Invoker, [0103]); the second ECP to implement a second ECT including the CAPIF (i.e. one or more API invokers 102, 104, a CAPIF core function (CCF) 106, an application program interface exposing function (AEF) 108, API publishing function 110 and API management function 112. In an embodiment, the one or more API invokers 102, 104 can be at least one of, but not limited to a computer, laptop, mobile phone, personal digital assistants (PAD) and servers or any other device which tries to access the AEF 108 for one or more service API's, [0044]) based on the CAPIF publish service API, expose, to a second ECP over a second reference point, at least the MEC service API and the transport discovery API exposed by the first ECP, (i.e. The AEF 108 is the entity which can be configured for exposing the one or more service API's to the API invokers (i.e., for 102 and 104). The API invoker 102 can have a direct connection with the AEF 108 to invoke the service API's, [0044] and the API invoker 102 is pre-configured or provisioned by the CCF 106 or during a service discovery and obtains an information that is required for a particular service API, [0051]); the transport discovery API to provide access to the transport protocol identified in the service API, the transport protocol not supported by the second ECT (i.e. Type of service the API invoker 102 subscribed, Interface details (such as IP address/port), Protocol between the AEF 108 and the API Invoker 102, when requested for access to a particular service (when multiple services are subscribed), [0103] and API invoker for accessing the at least one service API on a CAPIF-2e interface, wherein the at least one security method includes at least one of a Transport Layers Security-Pre-Shared Key (TLS-PSK), a TLS-Public Key Infrastructure (TLS-PKI), an Internet Key Exchange version 2 (IKEv2), an Internet Protocol Security (IPsec) and an OAuth 2.0, [0012]).
Based on Sophia in view of MEC 5G and further in view of RAJADURAI, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of RAJADURAI to the system of Sophia and MEC 5G in order to support vast services with different architectural and performance requirements, (RAJADURAI, [0007]).
However, Sophia in view of MEC 5G and further in view of RAJADURAI do not explicitly disclose the plurality of different transport protocols including the first transport protocol associated with the MEC service API; the second ECP to implement a second ECT including the CAPIF, the transport discovery API to provide access to a plurality of different transport protocols available to expose a plurality of service APIs, the plurality of different transport protocols including the first transport protocol associated with the MEC service API, the first transport protocol not supported by the second ECT.
However, FILIPPOU teaches the plurality of different transport protocols including the first transport protocol associated with the MEC service API (i.e. transport protocols beyond TCP; exploitation of any information coming from MEC services deemed as useful to identify events, [0119] Mp1 provides service registration 2538, service discovery, and communication support for various services, such as the MEC services 2536 provided by MEC host 2502. Mp1 may also provide application availability, session state relocation support procedures, traffic rules and DNS rules activation, access to persistent storage and time of day information, [0257]); the transport discovery API to provide access to a plurality of different transport protocols available to expose a plurality of service APIs, the plurality of different transport protocols including the first transport protocol associated with the MEC service API (i.e. a transport protocol, such as Cyclic UDP (CUDP), Datagram Congestion Control Protocol (DCCP), Fibre Channel Protocol (FCP), Multi-Path TCP (MPTCP), Multi-Path UDP (MPUDP), QUIC, Reliable Data Protocol (RDP), Reliable UDP (RUDP), SCTP, Sequenced Packet Exchange (SPX), Structure Stream Transport (SST), TCP, UDP, UDP-Lite, Micro Transport Protocol (pTP), and/or the like. When the underlying transport layer protocol is TCP, the TPR may be referred to as a “TCP runtime” or the like. In embodiments, the TPRs at the server side (e.g., running on MEC servers), query MEC services, [0126] and he communication between the instantiated TPR entity and the available MEC services may take place using MEC APIs. MEC allows running MEC apps at the edge of the network to be exposed to location and up-to-date information, such as up-to-date RNI, [0145] and The MEC APIs support HTTP over TLS (also known as HTTPS), [0094]).
Based on Sophia in view of MEC 5G and RAJADURAI and further in view of FILIPPOU, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of FILIPPOU to the system of Sophia, MEC 5G, and RAJADURAI in order to facilitate accessing network resources and applications at locations closer to the edge of the network, (FILIPPOU, [0006]).
Regarding claim 63, Sophia teaches the instructions are to cause one or more of the at least one processor circuit to: authenticate and verify the first ECP based on an authentication and attestation mechanism; and (i.e. The CAPIF shall provide mechanisms for the event logging of API invoker interactions with the CAPIF (e.g. authentication, authorization, discover service APIs), page 17, paragraph 3).
However, Sophia in view of MEC 5G do not explicitly disclose authenticate and verify a request from the first ECP based on the authentication and attestation mechanism.
However, RAJADURAI teaches authenticate and verify a request from the first ECP based on the authentication and attestation mechanism (i.e. the API Invoker 102 sends a Service API invocation request with authentication to the AEF 108. Further, the API Invoker 102 information is obtained for the authentication. Further, the AEF identifies verification and authentication based on the PSK. Further, the AEF gives a Service API invocation response to the API Invoker, [0107]). Therefore, the limitations of claim 63 are rejected in the analysis of claim 61 above, and the claim is rejected on that basis.
Regarding claim 64, Sophia teaches the authentication and attestation mechanism is based on at least one of an Open Authorization (OAuth) protocol or a Transport Layer Security (TLS) protocol (i.e. security layer protocol(s), page 18, paragraph 1).
Regarding claim 66, Sophia in view of MEC 5G do not explicitly disclose teaches the instructions are to cause one or more of the at least one processor circuit to: update a list of applications having access to the list of exposed APIs to include the application; and cause the updated list of applications to be sent to the first ECP.
However, RAJADURAI teaches the instructions are to cause one or more of the at least one processor circuit to: update a list of applications having access to the list of exposed APIs to include the application (i.e. The CAPIF shall provide the capability to onboard new API invokers (applications invoking APIs), page 77, paragraph 5); and cause the updated list of applications to be sent to the first ECP (i.e. Onboarding new API invokers by provisioning the API invoker information at the CAPIF core function, requesting explicit grant of new API invokers onboarding and confirming onboarding success, page 29, paragraph 5). Therefore, the limitations of claim 66 are rejected in the analysis of claim 61 above, and the claim is rejected on that basis.
Regarding claim 70, Sophia teaches the first ECP is a MEC platform in a MEC framework (i.e. MEC API framework, page 112 line 1, MEC Multi-access Edge Computing, page 13 line 9).
However, Sophia does not explicitly disclose the third reference point is an Mpl interface.
However, MEC 5G teaches the third reference point is an Mpl interface (i.e. the MEC reference point Mpl supports publication of MEC services, page 11, paragraph 2). Therefore, the limitations of claim 70 are rejected in the analysis of claim 61 above, and the claim is rejected on that basis.
Regarding claim 71, Sophia teaches the second ECP is an Edge Enabler Server (EES) in a Third Generation Partnership Project (3GPP) Edge Computing framework, (i.e. a functional architecture which enables an API invoker to access and invoke service APIs. The CAPIF functional model can be adopted by any 3GPP functionality providing service APIs, page 20, paragraph 4), and the second edge app application is associated with an Edge Application Server (EAS) (i.e. The API invoker is typically provided by a 3" party application provider who has service agreement with a CAPIF provider, page 20, paragraph 1).
Regarding claim 72, Sophia teaches wherein the first ECP is an EES in a 3GPP Edge Computing framework (i.e. a functional architecture which enables an API invoker to access and invoke service APIs. The CAPIF functional model can be adopted by any 3GPP functionality providing service APIs, page 20, paragraph 4 and the CAPIF-3 reference point supports: - Authenticating the API invoker based on the identity and credentials of the API invoker, page 28, paragraph 5).
Regarding claim 73, Sophia teaches the second ECP is a MEC platform in a MEC framework, and the application is associated with an application server (i.e. , the first edge app is an EAS (i.e. The functional model for the common API framework (CAPIF) is organized into functional entities to describe a functional architecture which enables an API invoker to access and invoke service APIs. The CAPIF functional model can be adopted by any 3GPP functionality providing service APIs, page 20, paragraph 4), and the application is associated with an application server (i.e. The API invoker is typically provided by a 3" party application provider who has service agreement with a CAPIF provider, page 20, paragraph 1).
Regarding claim 74, Sophia teaches one or more of the at least one processor circuit is included in or connected with a gateway associated with the CAPIF (i.e. In a reference point based model, the API invoker within the PLMN trust domain interacts with the CAPIF via CAPIF-1 and CAPIF-2. The API invoker from outside the PLMN trust domain interacts with the CAPIF via CAPIF-1e and CAPIF-2e, page 21, paragraph 2).
Regarding claim 75, Sophia teaches the first ECP is to act as a CAPIF API Exposure Function (AEF) (i.e. The CAPIF core function 3 can be connected with the API exposing function(s) and API invokers, page 35, page 4), the first reference point is a first CAPIF reference point (i.e. The service API exposure function is connected to 3GPP network entity (s) via 3GPP internal interface(s). The API publishing function provides the service API information for publishing to the CAPIF core function, page 101, page 2 and the CAPIF-3e reference point, which exists between the API exposing function within the 3™ party trust domain and the CAPIF core function within the PLMN trust domain, page 101, page 4), and the second reference point is a second CAPIF reference point (i.e. The API exposing function, the API publishing function and the API management function of the API provider domain1 within the PLMN trust domain interacts with the CAPIF core function via CAPIF-3, page 24, paragraph 3).
Regarding claim 76, Sophia teaches gateway is part of a CAPIF Core Function (CCF) of the CAPIF (i.e. The CCF-A and the CCF-B may belong to the same CAPIF provider domain or different CAPIF provider domains. Page 77, paragraph 7).
Regarding claim 86, Sophia teaches wherein the gateway is outside of a CCF of the CAPIF (i.e. The 3GPP EPS can deploy the CAPIF core function, the SCEF-2 (API exposing function as a gateway) along with the SCEF-1 as illustrated in subclause 7.3, page 104, paragraph 1).
Regarding claim 92, Sophia teaches including sending a list of applications having access to the list of exposed APIs to the first ECP (i.e. Interface/Reference point for exposing framework services as APls to the applications, Table B.2.1-1).
Regarding claims 77, 82, 88, 91, and 89, the limitations of claims 77, 82, 88, 91, and 89 are similar to the limitations of claims 61, 65, and 6. RAJADURAI further teaches an apparatus comprising: interface circuitry to communicate over a first reference point and a second reference point; instructions; and at least one processor circuit to be programmed by the instructions (i.e. the system 100 includes one or more interfaces/reference points. The one or more interfaces includes a CAPIF-1, CAPIF-1e, CAPIF-2, CAPIF-2e, CAPIF-3, CAPIF-4 and CAPIF-5 interfaces, [0046]). Therefore, the limitations of claims 77, 82, 88, 91, and 89 are rejected in the analysis of claims 61, 65, and 66 above, and the claims are rejected on that basis.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AYELE F WOLDEMARIAM whose telephone number is (571)270-5196. The examiner can normally be reached M_F 8:30AM-5:00PM.
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, Joon H Hwang can be reached on 571-272-4036. 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.
/A W/
AYELE F. WOLDEMARIAM
Examiner
Art Unit 2447
12/16/2025
/SURAJ M JOSHI/Primary Examiner, Art Unit 2447