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 .
Response to Arguments
Applicant's arguments filed 03/24/2026 have been fully considered but they are not persuasive. Examiner has thoroughly reviewed applicant’s arguments but firmly believes the cited reference to reasonably and properly meet the claimed limitations i.e. that In particular, in response to the API call, indicate the one or more controllers to cause the one or more devices to adjust one or more settings of the one or more devices 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 at least the one or more cellular transport networks. Examiner respectfully direct the Application to paragraphs, 0023, 0032-0034, 0069, Abhigyan et al where discloses that 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. Also for example, if UE 210A requests a modification of a network feature within core network 230A, network API gateway 230C routes the request to core controller 220D which then makes the feature modification within core network 230A at 222D. In still further examples, server 240A may request a modification of a network feature within access network 220A and network API gateway 230C may route that request to access controller 210D. In addition, server 240A may request a modification of a network feature within core network 230A and network API gateway 230C may route that request to network controller 220D see detail inclaim1.
Further, in paragraphs 0046, 0052, Saha et al where discloses that EMS 330 (i.e., controller) can include various components, such as: QoS engine 332, latency engine 334, UE database 338 and core interface 336. Core interface 336 can communicate via requests and responses with core API 320 via a networks. A request can be transmitted by EMS 330 via core interface 336 that requests that a particular parameter maintained by cellular network 120 include cellular network components 128 include core 139 be modified, EMS 330 can transmit requests for an adjustment related to QoS, latency, or both to the cellular network 120 include cellular network components 128 include core 139 (i.e., cellular transport networks). In paragraph 0046, Saha et al also discloses, The request may be provided by a UE that determines for a service it is to perform that either a higher QoS is needed or a lower QoS is sufficient and evaluate the request to determine whether the QoS provided by cellular network 120 to a particular UE or group of UE should be adjusted to either increase or decrease the QoS. For instance, in some embodiments, QoS engine 332 may receive an indication of an application or function that is about to be performed by the UE. QoS engine 332 may evaluate the currently provided QoS of cellular network 120 to determine if and how the QoS provided should be adjusted and can transmit a request via core interface 336 to core API 320 requesting that a QoS parameter for the UE be modified. This request can be transmitted directly to core 139 of cellular network 120 via core API 320. In response to receiving the updated QoS level, core 139 can adjust how the UE (or group of UEs) are provided service. In paragraph 0054, Saha et al discloses, a UE itself may request an adjustment in QoS level via EMS 330. For example, a UE, such as UE 110-3, may determine that it is not receiving sufficient QoS from cellular network 120 in order to perform a particular task. This request can be transmitted via cellular network 120 (request via core API 320 to core API interface 336) (i.e., receive an application programming interface (API)) or via some other network connection via Internet 301, such as a WiFi connection to an Internet Service Provider (ISP). In paragraph 0055, Saha et al discloses
Additionally, the examiner has given the claim language its broadest reasonable interpretation. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Applicant always has the opportunity to amend the claims during prosecution, and broad interpreted by the examiner reduces the possibility that the claim, once issued, will be interpreted more broadly than is justified. In re Prater, 415 F.2d 1393, 1404-05, 162 USPQ 541, 550-51 (CCPA 1969).
In response to applicant's argument that there is no suggestion to combine the references, the examiner recognizes that obviousness can only be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988)and In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992).
One cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., Inc., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Examiner’s Note; The Examiner has pointed out particular references contained in the prior art of record within the body of this action for the convenience of the Applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply. "The use of patents as references is not limited to what the patentees describe as their own inventions or to the problems with which they are concerned. They are part of the literature of the art, relevant for all they contain." In re Heck, 699 F.2d 1331, 1332-33,216 USPQ 1038, 1039 (Fed. Cir. 1983) (quoting In re Lemelson, 397 F.2d 1006, 1009, 158 USPQ 275,277 (CCPA 1968)). A reference may be relied upon for all that it would have reasonably suggested to one having ordinary skill the art, including nonpreferred embodiments (see MPEP 2123). Therefore, Applicant, in preparing the response, must fully consider the entire disclosure of the cited references as potentially teaching all or part of the claimed invention, including the context of the cited passages as taught by the prior art disclosed by the Examiner.
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Abhigyan et al (20230018000) in view of Saha et al (20230284323).
Regarding claim 1, Abhigyan et al discloses, a processor comprising (abstract, fig. 1-3):
circuits to (fig. 5):
an application programming interface (API) call to indicate one or more controllers to control one or more devices within one or more cellular transport networks that are to control one or more devices within the one or more cellular transport networks (¶ 0023, 0032-0034, 0069, network API service 158 may provide many different types of APIs, 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. These and other embodiments are more fully described below with reference to later figures).
Abhigyan et al does not specifically disclose in detail, in response to the API call, indicate the one or more controllers to cause the one or more devices to adjust one or more settings of the one or more devices 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 at least the one or more cellular transport networks.
In the same field of endeavor, Saha et al discloses in more detail, in response to the API call, indicate the one or more controllers to cause the one or more devices to adjust one or more settings of the one or more devices 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 at least the one or more cellular transport networks (¶ 0049, 0052, 0055, 0073, fig. 1-5, a client, which may operate EMS 330 or may have permission to use EMS 330, can submit a request via client interface 331. The request may be provided by a UE that determines for a service it is to perform that either a higher QoS is needed or a lower QoS is sufficient. QoS engine 332 may receive the request via client interface 331 and evaluate the request to determine whether the QoS provided by cellular network 120 to a particular UE or group of UE should be adjusted to either increase or decrease the QoS. For instance, in some embodiments, QoS engine 332 may receive an indication of an application or function that is about to be performed by the UE. QoS engine 332 may evaluate the currently provided QoS of cellular network 120 to determine if and how the QoS provided should be adjusted. Alternatively, QoS engine 332 may simply receive the instruction from client interface 331 and enact the request, if permitted. QoS engine 332 may be able to send a request via core interface 336 and core API 320 to retrieve a parameter that indicates a QoS level currently being provided by cellular network 120 to a particular.
Saha et al also discloses receive an application programming interface (API) call indicating one or more controllers outside of one or more cellular transport networks ( (¶ 0054-0055).
Therefore, before the effective filing date of the claim invention, it would have been obvious to one of ordinary skill in the art at the time the invention was made to modify the device of Abhigyan et al by specifically adding feature in order to enhance system performance to allowing the entity significant control through interfacing with core to control parameters as taught by Saha et al.
Regarding claims 2, 9, 16, Abhigyan et al discloses, wherein the one or more controllers are external to the one or more 5G transport networks (¶ 0023, 0032-0034, 0069, 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. Also for example, if UE 210A requests a modification of a network feature within core network 230A, network API gateway 230C routes the request to core controller 220D which then makes the feature modification within core network 230A at 222D. In still further examples, server 240A may request a modification of a network feature within access network 220A and network API gateway 230C may route that request to access controller 210D. In addition, server 240A may request a modification of a network feature within core network 230A and network API gateway 230C may route that request to network controller 220D and also see claim 1).
Regarding claims 3, 10, 17, Abhigyan et al discloses, wherein the one or more controllers are to receive analytic information from the one or more 5G transport networks (¶ 0023, 0032-0034, 0069, network API service 158 may provide many different types of APIs, 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. These and other embodiments are more fully described below with reference to later figures and also see claim 1).
Regarding claims 4, 11, 18, Abhigyan et al discloses, wherein the one or more controllers are to receive analytic information from the one or more 5G transport networks, one or more 5G access networks, and one or more 5G core networks (¶ 0023, 0032-0034, 0069, The subject disclosure describes, among other things, illustrative embodiments of a system to expose both network guidance features and network control features to external applications. Low-level network data may be analyzed to produce metrics of interest to applications and future predictions of those metrics in real-time. The 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. Other embodiments are described in the subject disclosure, and also see claim 1).
Regarding claims 5, 12, 19, Abhigyan et al discloses, wherein the one or more controllers are to generate one or more control signals to transmit to the one or more 5G transport networks based, at least in part, on analytic information received from the one or more 5G transport networks (¶ 0023, 0032-0034, 0069, network API service 158 may provide many different types of APIs, 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. These and other embodiments are more fully described below with reference to later figures, and also see claim 1).
Regarding claims 6, 13, 20, Abhigyan et al discloses, wherein the one or more controllers are to generate one or more control signals to transmit to the one or more 5G transport networks based, at least in part, on analytic information received from one or more 5G access networks, the one or more 5G transport networks, and one or more 5G core networks (¶ 0023, 0032-0034, 0069, network API service 158 may provide many different types of APIs, 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. These and other embodiments are more fully described below with reference to later figures and also see claim 1).
Regarding claims 7, 14 Abhigyan et al discloses, wherein one or more controllers include one or more processors to perform a neural network to generate network settings of the one or more 5G access networks (¶ 0023, 0032-0034, 0069, network API service 158 may provide many different types of APIs, 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. These and other embodiments are more fully described below with reference to later figures and also see claim 1).
Regarding claims 8, 15, Abhigyan et al discloses, a system, comprising memory to store instructions that, as a result of performance by one or more processors, cause the system to perform an application programming interface (API) to indicate one or more controllers to control one or more devices within one or more 5G transport networks (¶ 0023, 0032-0034, 0058, 0069, network API service 158 includes network database 210C, analytics engine 220C, and network API gateway 230C. In some embodiments, network database 210C is a storage mechanism capable of storing network data collected from the various elements shown in FIG. 2C. For example network database 210C may include memory allocated in a virtual machine or on a server. Also for example, network database 210C may be distributed storage that stores network data in different locations and network API service 158 may provide many different types of APIs, 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. These and other embodiments are more fully described below with reference to later figures).
In the same field of endeavor, Saha et al discloses in more detail, in response to the API call, indicate the one or more controllers to cause the one or more devices to adjust one or more settings of the one or more devices 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 at least the one or more cellular transport networks (¶ 0049, 0052, 0055, 0073, fig. 1-5, a client, which may operate EMS 330 or may have permission to use EMS 330, can submit a request via client interface 331. The request may be provided by a UE that determines for a service it is to perform that either a higher QoS is needed or a lower QoS is sufficient. QoS engine 332 may receive the request via client interface 331 and evaluate the request to determine whether the QoS provided by cellular network 120 to a particular UE or group of UE should be adjusted to either increase or decrease the QoS. For instance, in some embodiments, QoS engine 332 may receive an indication of an application or function that is about to be performed by the UE. QoS engine 332 may evaluate the currently provided QoS of cellular network 120 to determine if and how the QoS provided should be adjusted. Alternatively, QoS engine 332 may simply receive the instruction from client interface 331 and enact the request, if permitted. QoS engine 332 may be able to send a request via core interface 336 and core API 320 to retrieve a parameter that indicates a QoS level currently being provided by cellular network 120 to a particular.
Saha et al also discloses receive an application programming interface (API) call indicating one or more controllers outside of one or more cellular transport networks ( (¶ 0054-0055).
Therefore, before the effective filing date of the claim invention, it would have been obvious to one of ordinary skill in the art at the time the invention was made to modify the device of Abhigyan et al by specifically adding feature in order to enhance system performance to allowing the entity significant control through interfacing with core to control parameters as taught by Saha et al.
Conclusion
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 KHAWAR IQBAL whose telephone number is (571)272-7909. The examiner can normally be reached M-F.
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, Jinsong Hu can be reached at 5712723965. 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.
/KHAWAR IQBAL/ Primary Examiner, Art Unit 2643