DETAILED ACTION
This communication is in responsive to Application 18230871 filed on 8/7/2023. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims:
Claims 1-20 are presented for examination.
Election/Restrictions
Examiner called the undersigned, Mr. Lin Hymel to elect orally between group 1 (claims 1-13) and group 2 (claims 14-20). Mr. Lin elected group 1 (claims 1-13) without traverse on 12/03/2025.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-4, 6 and 9-12 are rejected under 35 U.S.C. 102 (a) (1) as being anticipated by Yeh et al. (hereinafter Yeh) US 2022/0014963 A1
Regarding Claim 1, Yeh teaches a system for sharing spectrum (¶0170 & ¶0432; sharing spectrum), computing resources, and Radio Access Network (RAN) elements in a wireless communication network (¶0259-¶0260; sharing computing resources and RAN elements), the system comprising:
a centralized service management and orchestration (SMO) entity (Figs. 20-21 & ¶0277; SMO 2002/2102 respectively), the SMO including an optimization engine for determining one or more resource allocation policies responsive to one or more received tenant requests (Fig. 21 & ¶0294; the SMO 2002, 2102 that enables non-real-time control and optimization of RAN elements and resources; AI/machine learning (ML) workflow(s) including model training, inferences, and updates; and policy-based guidance of applications/features in the Near-RT RIC 2114.
¶0205 & Fig. 15 illustrate multiple tenants’ requests…to fulfill requests and responses for various client endpoints 1510 (e.g., smart cities/building systems, mobile devices, computing devices, business/logistics systems, industrial systems, etc.) and based on network state information (¶0192; like resources available [state information] to edge locations) received from a radio access network (RAN) (Fig. 21 & ¶0281 & ¶0294; the SMO 2102 containing the non-RT RIC 2112, and may include the O-Cloud 2106. The O-Cloud 2106 is a cloud computing platform including a collection of physical infrastructure nodes to host the relevant O-RAN functions (e.g., the near-RT RIC 2114, O-CU-CP 2121, O-CU-UP 2122, and the O-DU 2115), supporting software components (e.g., OSs, VMMs, container runtime engines, ML engines, etc.), and appropriate management and orchestration functions… SMO 2002, 2102 that enables non-real-time control and optimization of RAN elements and resources; AI/machine learning (ML) workflow(s) including model training, inferences, and updates; and policy-based guidance of applications/features in the Near-RT RIC 2114) and deploying the determined resource allocation policies on the network (same citation is preceding limitation. See also ¶0084; where the deployed networks are disparate in various features, such as access technology (RAT), coverage area per access network node, deployed frequency band and bandwidth, and backhaul capabilities);
a plurality of edge datacenters configured to instantiate virtualized networking services in response to the deployed resource allocation policies from the optimization engine (¶0192, ¶0259-¶0260; edge cloud architecture that instantiate deploying resources based on a request and policies);
and a plurality of cell sites, the cell sites operating the network in response to instructions from the edge datacenters consistent with the deployed resource allocation policies (Fig. 11 & ¶0188; the edge servers 1136 may be deployed at cell aggregation sites or at multi-RAT aggregation points that can be located either within an enterprise or used in public coverage areas. In a fourth example, the edge servers 1136 may be deployed at the edge of CN 1142. These implementations may be used in follow-me clouds (FMC), where cloud services running at distributed data centers follow the UEs 1121 as they roam throughout the network).
Regarding Claim 2, Yeh teaches the system of claim 1, wherein each received tenant request describes at least one of a service required, a resource needed, a fault-recovery policy, or combinations thereof (¶0205 & Fig. 15; Specifically, FIG. 15 depicts coordination of a first edge node 1522 and a second edge node 1524 in an edge computing system 1500, to fulfill requests and responses for various client endpoints 1510 (e.g., smart cities/building systems, mobile devices, computing devices, business/logistics systems, industrial systems, etc.), which access various virtual edge instances. Here, the virtual edge instances 1532, 1534 provide edge compute capabilities and processing in an edge cloud, with access to a cloud/data center 1540 for higher-latency requests for websites, applications, database servers, etc. However, the edge cloud enables coordination of processing among multiple edge nodes for multiple tenants or entities).
Regarding Claim 3, Yeh teaches the system of claim 1, wherein the network state information includes at least one of infrastructure availability, spectrum availability, or both (¶0192; like resources available [state information] to edge locations).
Regarding Claim 4, Yeh teaches the system of claim 1, wherein the resource allocation policies specify at least one of carrier frequency, bandwidth, cell site infrastructure, edge datacenter computing resources, or combinations thereof allocated to each tenant or tenant request (¶0084; where the deployed networks are disparate in various features, such as access technology (RAT), coverage area per access network node, deployed frequency band and bandwidth, and backhaul capabilities).
Regarding Claim 6, Yeh teaches the system of claim 1, wherein the edge datacenters instantiate the virtualized networking services in one or more near-real-time (near-RT) RAN intelligent controllers (RICs), non-RT RICs, 5G Next Generation Node Bases (gNBs), or combinations thereof (see ¶0034 & FIGS. 1a, 1b, and 1c; RAN intelligent controller (RIC) (e.g., Non-RT RIC 2012 and/or Near-RT RIC 2014 of FIG. 20 or the like).
Regarding Claim 9, Yeh teaches a method of sharing spectrum, computing resources, and Radio Access Network (RAN) elements in a wireless communication network among a plurality of tenants (¶0259-¶0260; sharing computing resources and RAN elements), the method comprising:
receiving a plurality of tenant requests for network resources at a centralized service management and orchestration (SMO) entity (¶0205 & Fig. 15 illustrate multiple tenants’ requests…to fulfill requests and responses for various client endpoints 1510 (e.g., smart cities/building systems, mobile devices, computing devices, business/logistics systems, industrial systems, etc. Fig. 21 & ¶0294; the SMO 2002, 2102 that enables non-real-time control and optimization of RAN elements and resources; AI/machine learning (ML) workflow(s) including model training, inferences, and updates; and policy-based guidance of applications/features in the Near-RT RIC 2114);
determining, by an optimization engine of the SMO, one or more resource allocation policies responsive to the tenant requests (Fig. 21 & ¶0294; the SMO 2002, 2102 that enables non-real-time control and optimization of RAN elements and resources; AI/machine learning (ML) workflow(s) including model training, inferences, and updates; and policy-based guidance of applications/features in the Near-RT RIC 2114.
¶0205 & Fig. 15 illustrate multiple tenants’ requests…to fulfill requests and responses for various client endpoints 1510 (e.g., smart cities/building systems, mobile devices, computing devices, business/logistics systems, industrial systems, etc.), the policies based on the tenant requests and network state information (¶0192; like resources available [state information] to edge locations) received from a radio access network (RAN) (Fig. 21 & ¶0281 & ¶0294; the SMO 2102 containing the non-RT RIC 2112, and may include the O-Cloud 2106. The O-Cloud 2106 is a cloud computing platform including a collection of physical infrastructure nodes to host the relevant O-RAN functions (e.g., the near-RT RIC 2114, O-CU-CP 2121, O-CU-UP 2122, and the O-DU 2115), supporting software components (e.g., OSs, VMMs, container runtime engines, ML engines, etc.), and appropriate management and orchestration functions… SMO 2002, 2102 that enables non-real-time control and optimization of RAN elements and resources; AI/machine learning (ML) workflow(s) including model training, inferences, and updates; and policy-based guidance of applications/features in the Near-RT RIC 2114);
deploying the one or more resource allocation policies from the SMO to one or more edge datacenters instantiating virtualized networking services in response to the deployed resource allocation policies from the optimization engine (same citation is preceding limitation. See also ¶0084; where the deployed networks are disparate in various features, such as access technology (RAT), coverage area per access network node, deployed frequency band and bandwidth, and backhaul capabilities. ¶0192, ¶0259-¶0260; edge cloud architecture that instantiate deploying resources based on a request and policies);
dispatching instructions from the edge datacenters to the cell sites in order to carry out the resource allocation policies (¶0227; edge computing system 1700 transmitting software instructions (e.g., code, scripts, executable binaries, containers, packages, compressed files, and/or derivatives thereof) to other computing devices. Component(s) of the example edge provisioning node 644 may be located in a cloud, in a local area network, in an edge network, in a wide area network, on the Internet, and/or any other location communicatively coupled with the receiving party(ies). The receiving parties may be customers, clients, associates, users, etc. of the entity owning and/or operating the edge provisioning node 1744. For example, the entity that owns and/or operates the edge provisioning node 1744 may be a developer, a seller, and/or a licensor (or a customer and/or consumer thereof) of software instructions such as the example computer readable instructions 2782 of FIG. 27. The receiving parties may be consumers, service providers, users, retailers, OEMs, etc., who purchase and/or license the software instructions for use and/or re-sale and/or sub-licensing.
Fig. 11 & ¶0188; the edge servers 1136 may be deployed at cell aggregation sites or at multi-RAT aggregation points that can be located either within an enterprise or used in public coverage areas. In a fourth example, the edge servers 1136 may be deployed at the edge of CN 1142. These implementations may be used in follow-me clouds (FMC), where cloud services running at distributed data centers follow the UEs 1121 as they roam throughout the network);
and providing network services by the cell sites according to the resource allocation policies (Fig. 11 & ¶0188; the edge servers 1136 may be deployed at cell aggregation sites or at multi-RAT aggregation points that can be located either within an enterprise or used in public coverage areas. In a fourth example, the edge servers 1136 may be deployed at the edge of CN 1142. These implementations may be used in follow-me clouds (FMC), where cloud services running at distributed data centers follow the UEs 1121 as they roam throughout the network).
Regarding Claim 10, Yeh teaches the method of claim 9, the step of determining the one or more resource allocation policies further comprising specifying at least one of carrier frequency, bandwidth, cell sites, edge datacenter computing resources, or combinations thereof allocated to each tenant or tenant request (¶0084; where the deployed networks are disparate in various features, such as access technology (RAT), coverage area per access network node, deployed frequency band and bandwidth, and backhaul capabilities).
Regarding Claim 11, Yeh teaches the method of claim 9, further comprising monitoring the provided network services by the edge datacenters and/or the SMO (¶0115-¶0117, ¶192 & ¶0259-¶0260; monitoring performance or violations).
Regarding Claim 12, Yeh teaches the method of claim 11, further comprising recovering the provided network services responsive to detection of a failure or potential failure in the provision of the network services (¶0397-¶0400; control failure).
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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
Claims 5, 7-8 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Yeh in view of Shankaranarayanan et al. (hereinafter Shankaranarayanan) US 2023/0318794 A1.
Regarding Claim 5, Yeh teaches the system of claim 1, wherein the optimization engine is executable as an rAPP deployed in a non-real-time (non-RT) RAN intelligent controller (RIC) hosted in the SMO (see ¶0034 & FIGS. 1a, 1b, and 1c; RAN intelligent controller (RIC) (e.g., Non-RT RIC 2012 and/or Near-RT RIC 2014 of FIG. 20 or the like).
Yeh does not expressly teach rAPP. Shankaranarayanan teaches rAPP (¶0009 & ¶0070; optimizing Physical Cell ID (PCI) assignment in an Open Radio Access Network (O-RAN). In particular, the method comprises the steps of deploying an optimization service in an rApp and registering the optimization service as a PCI-rApp within a Service Management and Orchestration Framework (SMO), and assigning a listing of unique predefined PCIs (Physical Cell IDs) to operating cells of a selected range after satisfying one or more constraints. Moreover, the operating cells have neighbour relations. Furthermore, the rApp is in connection with a Non-Real Time RAN Intelligent Controller (Non-RT-RIC) through an interface).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed limitation to incorporate the teachings of Shankaranarayanan into the system of Yeh in order to improve communication capacity, speed, flexibility and/or efficiency may present certain problems (¶0008). Utilizing such teachings enable the rApp consumes network data having CM notification of new cell deployment or neighbor relation change, FM about PCI conflict(s) and PM. Particularly, the rApp determines a PCI for newly deployed cell or PCI changes to resolve flagged PCI conflicts (¶0016).
Regarding Claim 7, Yeh teaches the system of claim 6, wherein the near-RT RIC (see ¶0034 & FIGS. 1a, 1b, and 1c; RAN intelligent controller (RIC) (e.g., Non-RT RIC 2012 and/or Near-RT RIC 2014 of FIG. 20 or the like).
Yeh does not expressly teach includes at least one xApp configured to instruct each of the cell sites to operate the network consistent with the deployed resource allocation policies.
includes at least one xApp configured to instruct each of the cell sites to operate the network consistent with the deployed resource allocation policies (¶0062; Near-Real Time RAN Intelligent Controller (Near-RT-RIC) (108) may host one or more xApps using E2 interface to collect near real-time information and provide value added services. xAPP is an independent software plug-in to the Near-Real Time RAN Intelligent Controller (Near-RT-RIC) (108) to provide functional extensibility to the RAN by third parties. The Near-Real Time RAN Intelligent Controller (Near-RT-RIC) (108) may be provided with different functionalities by using programmable modules as xAPPs, from different operators and vendors).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed limitation to incorporate the teachings of Shankaranarayanan into the system of Yeh in order to improve communication capacity, speed, flexibility and/or efficiency may present certain problems (¶0008).
Regarding Claim 8, Yeh teaches the system of claim 6, wherein the near-RT RIC (see ¶0034 & FIGS. 1a, 1b, and 1c; RAN intelligent controller (RIC) (e.g., Non-RT RIC 2012 and/or Near-RT RIC 2014 of FIG. 20 or the like).
Yeh does not expressly teach includes at least one xApp for monitoring the operation of the network.
includes at least one xApp for monitoring the operation of the network (¶0062; Near-Real Time RAN Intelligent Controller (Near-RT-RIC) (108) may host one or more xApps using E2 interface to collect near real-time information and provide value added services. xAPP is an independent software plug-in to the Near-Real Time RAN Intelligent Controller (Near-RT-RIC) (108) to provide functional extensibility to the RAN by third parties. The Near-Real Time RAN Intelligent Controller (Near-RT-RIC) (108) may be provided with different functionalities by using programmable modules as xAPPs, from different operators and vendors).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed limitation to incorporate the teachings of Shankaranarayanan into the system of Yeh in order to improve communication capacity, speed, flexibility and/or efficiency may present certain problems (¶0008).
Claim 13 is substantially similar to claim 5, thus the same rationale applies.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MAHRAN ABU ROUMI whose telephone number is (469)295-9170. The examiner can normally be reached Monday-Thursday 6AM-5PM.
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, Emmanuel Moise can be reached at 571-272-3865. 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.
MAHRAN ABU ROUMI
Primary Examiner
Art Unit 2455
/MAHRAN Y ABU ROUMI/Primary Examiner, Art Unit 2455