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
Rejections under 35 USC 102/103
Applicant’s Argument: Applicant argues there is no suggestion that receiver 216 in Lekutai for receiving intents are in the SMO, or that the intent interfaces exposes at least an API for intent determination. Finally, the intent specifies the policy implementation or the intended result which is not taught in Lekutai.
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. Applicant has amended the claim to specify the intent interface at the SMO via API and the intent specifying an intended result thus changing the scope of the invention. A new reference is applied in a new grounds of rejection following an updated search.
Claim Rejections - 35 USC § 102
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.
Claim(s) 1, 8, 15 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Ickin et al. (“Ickin”) (WO 2022074015 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].
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].
Regarding claim 15 see rejections for claim 8 which teach the physical structure.
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) 2-3, 9-10, 16-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ickin et al. (“Ickin”) (WO 2022074015 A1) in view of Lo et al. (“Lo”) (US 20200021482 A1).
Regarding claim 2, Ickin teaches:
The method of claim 1.
Ickin teaches intent but does not teach abstraction level.
Lo teaches further comprising determining an abstraction level of the intent policy, wherein the abstraction level comprises one of a business abstraction level and a system abstraction level [¶0019 business intent at a high level of abstraction corresponding to business abstraction level].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify that there is an abstraction level being a business abstraction level. Ickin teaches the non-RT RIC and it would have been obvious to include the business abstraction level 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 3, Ickin-Lo teaches:
The method of claim 2, 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].
Regarding claim 9, Ickin teaches:
The system of claim 8.
Ickin teaches intent but does not teach abstraction level.
Lo teaches wherein the at least one processor is further configured to execute the instructions to determine an abstraction level of the intent policy, and wherein the abstraction level comprises one of a business abstraction level and a system abstraction level [¶0019 business intent at a high level of abstraction corresponding to business abstraction level].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify that there is an abstraction level being a business abstraction level. Ickin teaches the non-RT RIC and it would have been obvious to include the business abstraction level 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-Lo teaches:
The system of claim 9, 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, see rationale for combination as in claim 9].
Regarding claim 16-17, see similar rejection for claim 9-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 Lekutai et al. (“Lekutai”) (US 20230199563 A1).
Regarding claim 4, Ickin 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 [¶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 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 [¶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 Curic et al. (“Curic”) (US 20240098568 A1).
Regarding claim 5, Ickin teaches:
The method of claim 1, wherein the obtaining of the input is performed by the intent interface termination [¶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 teaches:
The method of claim 1, wherein the NRT RIC comprises an rAPP on which a policy management function module is deployed [¶0123 rApps], wherein the obtaining of the input is performed by the intent interface termination [¶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 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 [¶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 teaches:
The system of claim 8, wherein the NRT RIC comprises an rAPP on which a policy management function module is deployed [¶0123], wherein the obtaining of the input is performed by the intent interface termination [¶0125-128], wherein the at least one processor is configured to execute the instructions to obtain the input by the intent interface termination [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 teaches:
The system of claim 8, wherein the NRT RIC comprises an rAPP [¶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 Ying et al. (“Ying”) (US 20240214272 A1).
Regarding claim 7, Ickin teaches:
The method of claim 1, wherein the NRT RIC comprises am rApp policy management function module deployed outside of the rApp [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 [¶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 teaches:
The system of claim 8, wherein the NRT RIC comprises a policy management function module deployed outside of the rApp [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 [¶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 Su et al. (“Su”) (US 20230189193 A1).
Regarding claim 23, Ickin 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 [¶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
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 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