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 .
Information Disclosure Statement
A plurality of IDS filed have been received and considered.
Response to Arguments
Applicant’s arguments with respect to 103 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 § 112
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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 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.
Specifically, claim 1 is amended as follows:
PNG
media_image1.png
327
799
media_image1.png
Greyscale
As such, “with a network address” is added to both one or more controllers and one or more devices. However, it is not clear if “a network address” in the first citation is the same as or different from “a network address” in the second citation, thus raising 112(b) being indefinite issue. For this reason, claim 1 is rejected.
Similarly, claims 8 and 15 are rejected for the same reasoning.
All the dependent claims are rejected as they are directly or indirectly dependent upon a rejected independent claim.
For the purpose of examination, “a network address” is interpreted as any address associated with a network or a node or a device or a controller.
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), and further in view of Jain et al. (US 20230199465, hereinafter Jain).
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]).
Sharma in view of Gupta does not explicitly disclose the one or more controllers and one or more devices with a network address.
However, in a similar endeavor, Jain discloses external controller 116 and various devices/controller with network address (see Jain, [0030][0035][0044][0049] exchange address, thus each device must have an address in order to be able to exchange).
Therefore, it would be obvious to one of ordinary skilled in the art to modify the teachings of Sharma in view of Gupta, to have controllers and other devices with address to exchange address information to verify each other’s identity.
The motivation/suggestion for doing so would have been to provide an enhanced capability to the core/fabric network by extending an enterprise access network or fabric to extended networks and external networks by allowing a fabric control plane or controller to communicate with controllers or control planes of extended networks and external networks, as suggested by Jain (see Jain, [0001]).
Regarding claims 2, 9, 16. Sharma teaches the one or more processors of claim 1, wherein the one or more controllers receive analytic information from at least one or more cellular networks including the one or more cellular access networks to generate the one or more control signals to cause the one or more devices to adjust the one or more settings. (see Sharma, as cited above in ¶0033, ¶0048, ¶0068, and ¶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 the 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 other 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
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 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 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
Prosecution Insights