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 .
Continued Examination Under 37 CFR 1.114
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 2/9/2026 has been entered.
Information Disclosure Statement
IDS filed 2/10/2026 has been received and considered.
Response to Arguments
Regarding Applicant’s arguments with respect to 112(a) and 112(b), as a result of amendment filed 2/9/2026, previous 112 rejections have been withdrawn.
Applicant’s arguments with respect to 102 rejections to claim(s) 1-20 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.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Abhigyan; Abhigyan Sharma (US PGPUB 20230018000, hereinafter Sharma) in view of Gupta et al. (US 20220311837, hereinafter Gupta).
Regarding claims 1, 8, 15. Sharma teaches one or more processors comprising: circuitry to perform an application programming interface (API) to indicate one or more controllers outside of one or more cellular access networks that are to control one or more devices within the one or more cellular access networks, (¶0033 see Network API service 158 may track these metrics separately for each user and may provide accurate estimates (e.g., wireless/cellular performance) for a given user. In some embodiments, control APIs utilize various controllers for access and core networks (e.g., radio access network (RAN) intelligent controller, 5G Network Exposure Function (NEF), etc.). These and other controllers may be exposed by network API service 158 to external applications (and users) for them to request features from the network in an on-demand manner. Also see Fig. 2D, network API service 158 being outside access network 220A, core network 230A.), and
indicate of the one or more controllers to cause the one or more devices to adjust one or more settings based at least on one or more control signals received from the one or more controllers, the one or more controllers generating the one or more control signals using at least information from the one or more cellular access networks (see [0048] “network API service 158 responds to requests from UE 210A and/or server 240A to provide the low-level network data. Further, in some embodiments, network API service 158 may analyze and/or synthesize the low-level network data previously collected and provide application-level data or metrics to UE 210A and server 240A. In some embodiments, network API service 158 provides the network data to provide guidance to UE 210A and/or server 240A so that they may make adaptations in accordance with the data provided. For example, UE 210A may request data that represents actual available bandwidth within access network 220A and core network 230A. In response to the available bandwidth information provided by network API service 158, UE 210A may modify a bitrate selection, a video quality, accelerate or delay a request for data, or may perform any other adaptation”. Also see [0068] “FIG. 2D is a block diagram illustrating an example, non-limiting embodiment of a network API service providing control functionality in accordance with various aspects described herein. FIG. 2D shows all of the elements of FIG. 2C with the addition of access controller 210D and core controller 220D. In embodiments represented by FIG. 2D, network API service 158 may modify network features within access network 220A using access controller 210D, and may modify network features within core network 230A using core controller 220D”).
Sharma does not specifically disclose “receiving an API call…and in response to the API call…”, even though Sharma discloses the concept of using the received information about the network to adjust one or more settings.
In a similar endeavor, Gupta discloses network information such as routing information may be exchanged via API calls, meaning that API calls are sent and received and network traffic is rerouted based on (in response to) the received routing information from the API calls (see Gupta, [0034] “…Alternatively, the routing information may be exchanged by API calls. Accordingly, network traffic on the network 121 that is directed to these blocks of addresses will be received at the elastic network interface 159a, e.g., by way of a network tunnel. The network prefixes to advertise and the endpoints to use may be configured in the route advertiser 156 by the tunnel control plane 162. In the event of a large scale outage that impairs a part of the networked environment 150 such as a region or zone, the route advertiser 156 may be configured to reroute the network traffic to a failover zone or region. This can be automated by health checks or triggered by an application programming interface (API) call”. Also see Gupta [0035], [0040] and Fig. 1B).
Therefore, it would be obvious to one of ordinary skilled in the art to modify the teachings of Sharma, to use API calls to get network information and based on the received network information to adjust or reroute network traffic, as taught by Gupta.
The motivation/suggestion for doing so would have been to provide an enhanced method to consistently send network traffic, as suggested by Gupta (see Gupta [0035]).
Regarding claims 2, 9, 16. Sharma teaches the one or more processors of claim 1, wherein the one or more controllers are external to the one or more 5G core networks (¶0069 user devices such as UE 210A or servers such as server 240A may request network feature modifications to meet various requirements (e.g., QoS, slicing, latency, etc.). When network API gateway 230C receives an API request to modify network features, the request is routed to the appropriate controller. For example, if UE 210A requests a modification of a network feature within access network 220A, network API gateway 230C routes the request to access controller 210D which then makes the feature modification within access network 220A at 212D [Access controllers are not part of the core controllers for the 5G networks]).
Regarding claim 3. Sharma teaches the one or more processors of claim 1, wherein the one or more controllers are to receive analytic information from one or more multi-access edge computing networks (MEC), and wherein the one or more controllers are to use the received analytic information to generate network settings of the one or more MECs. (0023 various embodiments combine data from multiple access and core networks to provide guidance to applications. The guidance enables client-side and server-side application adaptation. Various embodiments also expose control of both access network features and core network features to applications ¶0033 provide a complete view of the network, network API service 158 may tap into data sources from multiple access networks (e.g., cellular, fixed-access) as well as core networks (e.g., mobility core, IP backbone). Network API service 158 may also provide an analytics engine that ingests data streams from multiple sources and output metrics of interest to applications in real time.)
Regarding claim 4, 11, 18. Sharma teaches the one or more processors of claim 1, wherein the one or more controllers are to receive analytic information from the one or more 5G core networks, one or more 5G access networks, and one or more 5G transport networks (¶0023 combine data from multiple access and core networks to provide guidance to applications ).
Regarding claims 5, 12, 19. Sharma teaches the one or more processors of claim 1, wherein the one or more controllers are to generate one or more control signals to transmit to the one or more 5G core networks based, at least in part, on analytic information received from the one or more 5G core networks (¶0033 , network API service 158 may provide “guidance” APIs that analyze network data and provide insights to applications (e.g., predictions of future network performance) that enable applications to adapt based on the guidance. Also for example, network API service 158 may provide “control” APIs that provide applications (or users) control of aspects or features of the network (e.g. available bandwidth). To provide a complete view of the network, network API service 158 may tap into data sources from multiple access networks (e.g., cellular, fixed-access) as well as core networks (e.g., mobility core, IP backbone). Network API service 158 may also provide an analytics engine that ingests data streams from multiple sources and output metrics of interest to applications in real time. Network API service 158 may track these metrics separately for each user and may provide accurate estimates (e.g., wireless/cellular performance) for a given user. In some embodiments, control APIs utilize various controllers for access and core networks (e.g., radio access network (RAN) intelligent controller, 5G Network Exposure Function (NEF), etc.). These and other controllers may be exposed by network API service 158 to external applications (and users) for them to request features from the network in an on-demand manner).
Regarding claims 6, 13, 19. Sharma teaches the one or more processors of claim 1, wherein the one or more controllers are to generate one or more control signals to transmit to the one or more 5G core networks based, at least in part, on analytic information received from one or more 5G access networks, one or more 5G transport networks, and the one or more 5G core networks (¶0033 Network API service 158 may track these metrics separately for each user and may provide accurate estimates (e.g., wireless/cellular performance) for a given user. In some embodiments, control APIs utilize various controllers for access and core networks (e.g., radio access network (RAN) intelligent controller, 5G Network Exposure Function (NEF), etc.). These and other controllers may be exposed by network API service 158 to external applications (and users) for them to request features from the network in an on-demand manner).
Regarding claim 7 and as applied to claim 1. In a first embodiment, Sharma discloses wherein one or more controllers include one or more processors to perform a neural network (paragraph 177, read as employing artificial intelligence (AI) including neural networks to facilitate automating one or more features).
In this first embodiment, Sharma substantially discloses the claimed invention but fails to teach to generate network settings of the one or more 5G access networks.
However, in a second embodiment, Sharma teaches to generate network settings of the one or more 5G access networks (paragraphs 49, where the features include quality of service (QoS) settings, bandwidth reservation, charging services, or service insertion, which relate to the 5G network).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of applicant’s claimed invention to have incorporated the teachings of Sharma’s second embodiment into the invention of Sharma’s first embodiment in order to dynamically change features within a 5G network.
Regarding claims 14 and 20. Sharma teaches wherein the one or more controllers are to generate one or more control signals to transmit to the one or more 5G access networks based, at least in part, on analytic information received from the one or more 5G access networks, one or more 5G transport networks, and one or more 5G core networks. (¶0177 directed and undirected model classification approaches comprise, e.g., naïve Bayes, Bayesian networks, decision trees, neural networks, fuzzy logic models, and probabilistic classification models providing different patterns of independence can be employed. Classification as used herein also is inclusive of statistical regression that is utilized to develop models of priority).
Regarding claims 10, 17, Sharma teaches the system of claim 8, wherein the one or more controllers are to receive analytic information from the one or more 5G core networks (¶0023 combine data from multiple access and core networks to provide guidance to applications ).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KATHY W WANG-HURST whose telephone number is (571)270-5371. The examiner can normally be reached Monday-Friday, 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.
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.
/KATHY W WANG-HURST/Supervisory Patent Examiner, Art Unit 2644