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 05/04/2026 has been entered.
Response to Arguments
Rejections under 35 USC 102/103
Applicant’s Argument: Applicant argues the prior art cited fails to teach a plurality of abstraction levels. The levels may include a business and system abstraction level.
Examiner’s Response: Applicant’s arguments with respect to claim(s) 1 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. The amended portion including the plurality of abstraction levels changes the scope of the invention. An updated search was conducted and a new reference is applied, see the rejection below.
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, 8, 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ickin et al. (“Ickin”) (WO 2022074015 A1) in view of Szilagyi et al. (“Szilagyi”) (US 20190364457 A1).
Regarding claim 1, Ickin teaches:
A method of generating policies/configurations in an open radio access network (O-RAN) service management and orchestration (SMO) framework [¶0125, O-RAN with SMO framework], the SMO framework comprising an intent interface termination and a non-real-time RAN intelligent controller (NRT RIC) [¶0127-128 “the method uses SMO framework 1701 and non-real time RIC 1703 to receive intents” intent interface], the method comprising:
obtaining an input corresponding to an intent policy for at least one operation of the SMO framework [¶0127, receive intents, ¶0128 corresponding to intent policies, declarative policies], the obtained input being obtained via the intent interface termination that terminates an intent interface at the SMO [¶0127-128 intent interface at SMO for receiving intents], the intent interface exposing at least one application programming interface for intent determination available in at least one of the SMG and the NRT RIC [¶0128 entry “is an intent interface where intent policies are given either by an external component or by a third party applications” corresponding to application programming interface], and the obtained input specifying an intended result of a policy implementation [ ¶0128, Intents are higher-level declarative policies, “they need to be mapped to more low-level constructs. A low-level policy is a set of rules that are used to manage and control changes or to keep the state of one or more managed objects such as nodes in a network”];
determining the intent policy of the input [¶0128, intents mapped to low-level policy being set of rules to manage or control changes of nodes corresponding to intent policy of input];
generating an SMO policy/configuration based on the intent policy [¶0128, generate low level intents, “Low-level intents can be either imperative or declarative. Imperative low-level intents hold explicit information about what needs to be done for the desired state to be achieved while declarative intents only supply the expected state and then allow the system to decide on its own how that should be achieved.” Further Figure 19, ¶0134-135, at SMO, “the intents are converted to conditions to be used by a Conditional Variational Autoencoder (cVAE) (e.g., cVAE 302) that uses the dataset from operation 1907, and the input conditions to generate different CM attributes that will be used as actions to achieve what is expected” corresponding to generate policy]; and implementing the SMO policy/configuration on at least one of a near-real-time RIC (nRT RIC), at least one RAN node, and an O-RAN Cloud (O-Cloud) [¶0142 send actions (implementing the configuration) to RAN nodes based on intent being implementing the policy on RAN node O-DU, O-RU in Figure 19 step 1923].
wherein the method further comprises: determining, in the NRT RIC, information related to the intent policy [¶0128, intents mapped to low-level policy being set of rules to manage or control changes of nodes corresponding to intent policy of input].
Ickin teaches NRT RCI controller mapping intents to policies but does not teach determining an abstraction level.
Szilagyi teaches a network device determining an abstraction level of the intent policy from among a plurality of predetermined abstraction levels, and determining whether to generate an SMO policy or a direct configuration for at least one RAN node, and/or the O-RAN Cloud, based on the abstraction level [¶0026-27, intent associated with first level abstraction of a plurality of levels, used to determine QoS/QoE targets, considered direct configuration, associated with RAN, Figure 1].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify abstraction levels for determining an action as in Szilagyi who teaches this allows for defining QoE parameters and QoS parameters, such as e.g. a seamless experience for online services ¶0026 for efficient QoS/QoE management ¶0024-26.
Regarding claim 2, Ickin-Szilagyi teaches:
The method of claim 1, wherein the plurality of predetermined abstraction levels comprises one of a business abstraction level and a system abstraction level [Szilagyi teaches multiple abstraction levels, wherein intent level 1 may be business abstraction, and level 3 may be system level, as the claim does not further define these terms, see rationale for combination for claim 1].
Regarding claim 8, Ickin teaches:
A system for generating policies/configurations in an open radio access network (O-RAN) service management and orchestration (SMO) framework [¶0125 teaches SMO framework], the SMO framework comprising an intent interface termination [¶0125-127, intent interface termination] and a non-real-time RAN intelligent controller (NRT RIC) [¶0127-128], the system comprising: at least one memory storing instructions; and at least one processor configured to execute the instructions to:
obtain an input corresponding to an intent policy for at least one operation of the SMO framework [¶0127, receive intents, ¶0128 corresponding to intent policies, declarative policies], the obtained input being obtained via the intent interface termination that terminates an intent interface at the SMO [¶0127-128 intent interface at SMO for receiving intents], the intent interface exposing at least one application programming interface for intent determination available in at least one of the SMG and the NRT RIC [¶0128 entry “is an intent interface where intent policies are given either by an external component or by a third party applications” corresponding to application programming interface], and the obtained input specifying an intended result of a policy implementation [ ¶0128, Intents are higher-level declarative policies, “they need to be mapped to more low-level constructs. A low-level policy is a set of rules that are used to manage and control changes or to keep the state of one or more managed objects such as nodes in a network”];
determine the intent policy of the input [¶0128, intents mapped to low-level policy being set of rules to manage or control changes of nodes corresponding to intent policy of input];
generate an SMO policy/configuration based on the intent policy[¶0128, generate low level intents, “Low-level intents can be either imperative or declarative. Imperative low-level intents hold explicit information about what needs to be done for the desired state to be achieved while declarative intents only supply the expected state and then allow the system to decide on its own how that should be achieved.” Further Figure 19, ¶0134-135, at SMO, “the intents are converted to conditions to be used by a Conditional Variational Autoencoder (cVAE) (e.g., cVAE 302) that uses the dataset from operation 1907, and the input conditions to generate different CM attributes that will be used as actions to achieve what is expected” corresponding to generate policy]; and implement the SMO policy/configuration on at least one of a near-real-time RIC (nRT RIC), at least one RAN node, and an O-RAN Cloud (O-Cloud) [¶0142 perform actions based on intent being implementing the policy on RAN node O-DU, O-RU in Figure 19 step 1923],
the at least one processor is further configured to execute the instructions to determine, in the NRT RIC, information related to the intent policy [¶0128, intents mapped to low-level policy being set of rules to manage or control changes of nodes corresponding to intent policy of input].
Ickin teaches NRT RCI controller mapping intents to policies but does not teach determining an abstraction level.
Szilagyi teaches a network device configured to determine an abstraction level of the intent policy from among a plurality of predetermined abstraction levels, and to determine whether to generate an SMO policy or a direct configuration for at least one RAN node, and/or the O-RAN Cloud, based on the abstraction level [¶0026-27, intent associated with first level abstraction of a plurality of levels, used to determine QoS/QoE targets, considered direct configuration, associated with RAN, Figure 1].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify abstraction levels for determining an action as in Szilagyi who teaches this allows for defining QoE parameters and QoS parameters, such as e.g. a seamless experience for online services ¶0026 for efficient QoS/QoE management ¶0024-26.
Regarding claim 15 see rejections for claim 8 which teach the physical structure.
Claim(s) 3, 10, 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ickin et al. (“Ickin”) (WO 2022074015 A1) in view of Szilagyi et al. (“Szilagyi”) (US 20190364457 A1) and Lo et al. (“Lo”) (US 20200021482 A1).
Regarding claim 3, Ickin- Szilagyi teaches:
The method of claim 2.
Ickin teaches intent but does not teach translating intent to system level command.
Lo teaches further comprising, based on determining the abstraction level of the intent policy as the business abstraction level, translating the intent policy to correspond to at least one system level command [Lo ¶0019 translate to network intent corresponding to system level command, see rationale for combination as in claim 2].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify a translation between policy to system level command as in Lo who teaches this allows the controller to automate processes to render (e.g., translate, map, etc.) a network intent throughout datacenter network 100 and implement policies to enforce the network intent ¶0019.
Regarding claim 10, Ickin- Szilagyi-Lo teaches:
The system of claim 9.
Ickin teaches intent but does not teach translating intent to system level command.
Lo teaches wherein the at least one processor is further configured to, based on determining the abstraction level of the intent policy as the business abstraction level, translate the intent policy to correspond to at least one system level command [Lo ¶0019 translate to network intent corresponding to system level command 9].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify a translation between policy to system level command as in Lo who teaches this allows the controller to automate processes to render (e.g., translate, map, etc.) a network intent throughout datacenter network 100 and implement policies to enforce the network intent ¶0019.
Regarding claim 17, see similar rejection for claim 10.
Claim(s) 4, 11, 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ickin et al. (“Ickin”) (WO 2022074015 A1) in view of Szilagyi et al. (“Szilagyi”) (US 20190364457 A1) and Lekutai et al. (“Lekutai”) (US 20230199563 A1).
Regarding claim 4, Ickin-Szilagyi teaches:
The method of claim 1, wherein the obtaining of the input and the determining of the intent policy are performed by the intent interface termination [Ickin ¶0127-128 intent received and determined at intent interface termination in SMO].
Ickin teaches determining the policy at the intent interface termination but not generating at the NRT RIC.
Lekutai teaches and wherein the generating of the SMO policy/configuration is performed by the NRT RIC [NRT RIC ¶0075, data requirements (corresponding to “intent policy”) used to generate traffic steering policy (corresponding to “generating an SMO policy/configuration” as this is implemented through the non-RT RIC operating on the SMO].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify the generation of the policy at the NRT RIC. Ickin teaches generation at an SMO including NRT RCI ¶0125-128 and it would have been obvious to include NRT RIC generating the policy as in Lekutai for dynamically modifying policies of a core network ¶0075.
Regarding claim 11, Ickin-Szilagyi teaches:
The system of claim 8, wherein the at least one processor is configured to execute the instructions to obtain the input and determine of the intent policy are performed by the intent interface termination [Ickin ¶0127-128 intent received and determined at intent interface termination in SMO].
Ickin teaches determining the policy at the intent interface termination but not generating at the NRT RIC.
Lekutai teaches and wherein the at least one processor is configured to execute the instructions to wherein the at least one processor is configured to execute the instructions to generate of the SMO policy/configuration by the NRT RIC [NRT RIC ¶0075, data requirements (corresponding to “intent policy”) used to generate traffic steering policy (corresponding to “generating an SMO policy/configuration” as this is implemented through the non-RT RIC operating on the SMO].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify the generation of the policy at the NRT RIC. Ickin teaches generation at an SMO including NRT RCI ¶0125-128 and it would have been obvious to include NRT RIC generating the policy as in Lekutai for dynamically modifying policies of a core network ¶0075.
Regarding claim 18 see rejections for claim 11 which teach the physical structure.
Claim(s) 5-6, 12-13, 19-20, 22, 24, 26 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ickin et al. (“Ickin”) (WO 2022074015 A1) in view of Szilagyi et al. (“Szilagyi”) (US 20190364457 A1) and Curic et al. (“Curic”) (US 20240098568 A1).
Regarding claim 5, Ickin-Szilagyi teaches:
The method of claim 1, wherein the obtaining of the input is performed by the intent interface termination [Ickin ¶0125-128].
Ickin teaches the input at the intent interface but not determining intent policy at the NRT RIC.
Curic teaches the determining of the intent policy and the generating of the SMO policy/configuration is performed by the NRT RIC [¶0009 “receiving, by the non-RT RIC, one or more operational intents that specify desired operating ranges for one or more performance indicators. The policy is generated based on the activity log and the one or more operational intents”]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify NRT RIC determining the intent policy. Ickin teaches the NRT RIC may use the data requirements corresponding to intent policy and it would have been obvious to expressly specify the NRT RIC determining intent as in Curic for implementing O-Ran which “allows for increased flexibility over traditional RAN systems. O-RAN can be implemented with vendor-neutral hardware and software-defined technology based on open interfaces and industry-developed standards” ¶0002.
Regarding Claim 6, Ickin-Szilagyi teaches:
The method of claim 1, wherein the NRT RIC comprises an rAPP on which a policy management function module is deployed [Ickin ¶0123 rApps], wherein the obtaining of the input is performed by the intent interface termination [Ickin ¶0125-128].
Ickin teaches the input at the intent interface but not determining intent policy at the NRT RIC.
Curic teaches the determining of the intent policy and the generating of the SMO policy/configuration is performed by the NRT RIC [¶0009 “receiving, by the non-RT RIC, one or more operational intents that specify desired operating ranges for one or more performance indicators. The policy is generated based on the activity log and the one or more operational intents” ¶0053-54 rApps on NRT RIC performing determining of policy]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify NRT RIC determining the intent policy. Ickin teaches the NRT RIC may use the data requirements corresponding to intent policy and it would have been obvious to expressly specify the NRT RIC determining intent as in Curic for implementing O-Ran which “allows for increased flexibility over traditional RAN systems. O-RAN can be implemented with vendor-neutral hardware and software-defined technology based on open interfaces and industry-developed standards” ¶0002.
Regarding claim 12, Ickin- Szilagyi teaches:
The system of claim 8, wherein the at least one processor is configured to execute the instructions to obtain the input is performed by the intent interface termination [Ickin ¶0125-128].
Ickin teaches the input at the intent interface but not determining intent policy at the NRT RIC.
Curic teaches wherein the at least one processor is configured to execute the instructions to determine the intent policy and generate the SMO policy/configuration by the NRT RIC [¶0009 “receiving, by the non-RT RIC, one or more operational intents that specify desired operating ranges for one or more performance indicators. The policy is generated based on the activity log and the one or more operational intents”]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify NRT RIC determining the intent policy. Ickin teaches the NRT RIC may use the data requirements corresponding to intent policy and it would have been obvious to expressly specify the NRT RIC determining intent as in Curic for implementing O-Ran which “allows for increased flexibility over traditional RAN systems. O-RAN can be implemented with vendor-neutral hardware and software-defined technology based on open interfaces and industry-developed standards” ¶0002.
Regarding Claim 13, Ickin-Szilagyi teaches:
The system of claim 8, wherein the NRT RIC comprises an rAPP on which a policy management function module is deployed [Ickin ¶0123], wherein the obtaining of the input is performed by the intent interface termination [Ickin ¶0125-128], wherein the at least one processor is configured to execute the instructions to obtain the input by the intent interface termination [Ickin NRT RIC ¶0075, data requirements (corresponding to “intent policy”) used to generate traffic steering policy (corresponding to “generating an SMO policy/configuration” as this is implemented through the non-RT RIC operating on the SMO].
Ickin teaches the input at the intent interface but not determining intent policy at the NRT RIC.
Curic teaches wherein the at least one processor is configured to execute the instructions to determine the intent policy and generate the SMO policy/configuration by the policy management function module [¶0009 “receiving, by the non-RT RIC, one or more operational intents that specify desired operating ranges for one or more performance indicators. The policy is generated based on the activity log and the one or more operational intents”]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify NRT RIC determining the intent policy. Ickin teaches the NRT RIC may use the data requirements corresponding to intent policy and it would have been obvious to expressly specify the NRT RIC determining intent as in Curic for implementing O-Ran which “allows for increased flexibility over traditional RAN systems. O-RAN can be implemented with vendor-neutral hardware and software-defined technology based on open interfaces and industry-developed standards” ¶0002.
Regarding claim 19-20, see similar rejection for claim 12-13.
Regarding Claim 24, Ickin- Szilagyi teaches:
The system of claim 8, wherein the NRT RIC comprises an rAPP [Ickin ¶0123 rApps].
Ickin teaches the input at the intent interface but not determining intent policy at the rApp.
Curic teaches wherein at least one of the determining and the generating is performed by an rApp in the NRT RIC [¶0009 “receiving, by the non-RT RIC, one or more operational intents that specify desired operating ranges for one or more performance indicators. The policy is generated based on the activity log and the one or more operational intents” and ¶0053-54, rApps, “ rApps 130, which reside in the centralized non-RT RIC 102, are used for identifying (determining) network governing policies”]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify NRT RIC determining the intent policy. Ickin teaches the NRT RIC may use the data requirements corresponding to intent policy and it would have been obvious to expressly specify the rApps determining as in Curic for implementing O-Ran which “allows for increased flexibility over traditional RAN systems. O-RAN can be implemented with vendor-neutral hardware and software-defined technology based on open interfaces and industry-developed standards” ¶0002.
Regarding claim 22, 26, see similar rejection for claim 24.
Claim(s) 7, 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ickin et al. (“Ickin”) (WO 2022074015 A1) in view of Szilagyi et al. (“Szilagyi”) (US 20190364457 A1) and Ying et al. (“Ying”) (US 20240214272 A1).
Regarding claim 7, Ickin-Szilagyi teaches:
The method of claim 1, wherein the NRT RIC comprises am rApp policy management function module deployed outside of the rApp [Ickin Figure 17 shows NRT RIC 1703 and RAN management outside of rApp 1705a ¶0123-125], wherein the obtaining of the input is performed by the intent interface termination [Ickin ¶0125-128].
Ickin teaches the policy management function on the NRT RIC but does not teach it is deployed outside the rAPP.
Ying teaches wherein the NRT RIC comprises an rApp and a policy management function module deployed outside of the rApp, and wherein the determining of the intent policy and the generating of the SMO policy/configuration is performed by the policy management function module [Figure 1, A1 policy function corresponding to policy management function, outside of rApps, creates policies, subscribed data analytics , receives intent from RAN in repository ¶0040, ¶0046-50].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify rApp and the policy function for performing intent policy determination as in Ying who teaches this allows to enable the Non-RT (Non-Real-Time) RIC to guide its connected Near-RT (Near-Real-Time) RICs to fulfil the RAN intent via the A1 interface ¶0003.
Regarding claim 14, Ickin-Szilagyi teaches:
The system of claim 8, wherein the NRT RIC comprises a policy management function module deployed outside of the rApp [Ickin Figure 17 shows NRT RIC 1703 and RAN management outside of rApp 1705a], wherein the at least one processor is configured to execute the instructions to obtain the input by the intent interface termination [Ickin ¶0125-128].
Ickin teaches the policy management function on the NRT RIC but does not teach it is embodied as an rAPP.
Ying teaches wherein the NRT RIC comprises an rApp and a policy management function module deployed outside of the rApp, and determine the intent policy and the generate the SMO policy/configuration by the policy management function module [Figure 1, A1 policy function corresponding to policy management function, outside of rApps, creates policies, subscribed data analytics , receives intent from RAN in repository ¶0040, ¶0046-50].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify rApp and the policy function for performing intent policy determination as in Ying who teaches this allows to enable the Non-RT (Non-Real-Time) RIC to guide its connected Near-RT (Near-Real-Time) RICs to fulfil the RAN intent via the A1 interface ¶0003.
Claim(s) 21, 23, 25 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ickin et al. (“Ickin”) (WO 2022074015 A1) in view of Szilagyi et al. (“Szilagyi”) (US 20190364457 A1) and Su et al. (“Su”) (US 20230189193 A1).
Regarding claim 23, Ickin-Szilagyi teaches:
The system of claim 8.
Ickin teaches an intent interface but not expressly external to NRT RIC.
Su teaches wherein the intent interface termination is in the SMO and external to the NRT RIC [Ickin ¶0040, Figure 3, EMS receives intent from web service 312, external to NRT RIC 322].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify the intent interface external to the NRT RIC. Ickin teaches an intent interface and it would have been obvious to specify it is external to NRT RIC as in Su who teaches this allows connection to a web service for transmitting intent to the be converted into program instructions to trigger related actions and achieve adjustment and management ¶0040.
Regarding claims 21, 25, see similar rejection for claim 23 which teaches the physical structure performing the method.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAY L. VOGEL whose telephone number is (303)297-4322. The examiner can normally be reached Monday-Friday 8AM-4:30 PM MT.
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, Joseph Avellino can be reached at 571-272-3905. 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.
/JAY L VOGEL/Primary Examiner, Art Unit 2478
Prosecution Insights