DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant's arguments filed 3/4/2026 have been fully considered but they are not persuasive. The applicant’s amendments address some of the previous 112 issues but have created more complicated 112 issues. These new 112 issues, based on the applicant’s amendments are presented in this office action.
After reviewing the amendment, the Examiner did not find any prior art that would anticipate or make obvious the claimed invention. The Examiner is not indicating the claims as allowable because they are incoherent and the invention is not described in a manner that satisfies the written description requirement as described in section 2161.01(I) of the MPEP.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
The following is from section 2161.01(I) of the MPEP:
Similarly, original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved. For software, this can occur when the algorithm or steps/procedure for performing the computer function are not explained at all or are not explained in sufficient detail (simply restating the function recited in the claim is not necessarily sufficient). In other words, the algorithm or steps/procedure taken to perform the function must be described with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended the function to be performed. See MPEP §§ 2163.02 and 2181, subsection IV.
The level of detail required to satisfy the written description requirement varies depending on the nature and scope of the claims and on the complexity and predictability of the relevant technology. Ariad, 598 F.3d at 1351, 94 USPQ2d at 1172; Capon v. Eshhar, 418 F.3d 1349, 1357-58, 76 USPQ2d 1078, 1083-84 (Fed. Cir. 2005). Computer-implemented inventions are often disclosed and claimed in terms of their functionality. For computer-implemented inventions, the determination of the sufficiency of disclosure will require an inquiry into the sufficiency of both the disclosed hardware and the disclosed software due to the interrelationship and interdependence of computer hardware and software. The critical inquiry is whether the disclosure of the application relied upon reasonably conveys to those skilled in the art that the inventor had possession of the claimed subject matter as of the filing date. Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 682. 114 USPQ2d 1349, 1356 (citing Ariad Pharm., Inc. V. Eli Lilly & Co, 598 F.3d 1336, 1351, 94 USPQ2d 1161, 1172 (Fed. Cir. 2010) in the context of determining possession of a claimed means of accessing disparate databases).
When examining computer-implemented functional claims, examiners should determine whether the specification discloses the computer and the algorithm (e.g., the necessary steps and/or flowcharts) that perform the claimed function in sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor possessed the claimed subject matter at the time of filing. An algorithm is defined, for example, as "a finite sequence of steps for solving a logical or mathematical problem or performing a task." Microsoft Computer Dictionary (5th ed., 2002). Applicant may "express that algorithm in any understandable terms including as a mathematical formula, in prose, or as a flow chart, or in any other manner that provides sufficient structure." Finisar Corp. v. DirecTV Grp., Inc., 523 F.3d 1323, 1340, 86 USPQ2d 1609, 1623 (Fed. Cir. 2008) (internal citation omitted). It is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. See, e.g., Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681-683, 114 USPQ2d 1349, 1356, 1357 (Fed. Cir. 2015) (reversing and remanding the district court’s grant of summary judgment of invalidity for lack of adequate written description where there were genuine issues of material fact regarding "whether the specification show[ed] possession by the inventor of how accessing disparate databases is achieved"). If the specification does not provide a disclosure of the computer and algorithm in sufficient detail to demonstrate to one of ordinary skill in the art that the inventor possessed the invention a rejection under 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph, for lack of written description must be made.
Written Description Issue #1
The applicant claims the following in claims 1 and 17:
receiving, by the first near-RT RIC, from a non-Real-Time RAN Intelligent Controller (non-RT RIC), identification of a second near-RT RIC that controls a second domain, the first domain and the second domain having been identified by the non-RT RIC as having mutual impact;
The applicant claims the following in claim 11:
receive, from the non-RT RIC, identification of the second near-RT RIC that controls the second domain, the first domain and the second domain having been identified by the non-RT RIC as having mutual impact;
In paragraph 119, the applicant attempts to describe how “mutual impacts” are determined:
[0119] At block 704, the non-RT RIC 112 identifies domains 201 with mutual impact. The domains with mutual impact are determined using an artificial intelligence/machine learning (AI/ML) model(s) that identifies cross-domain conflict based on the control and user plane data captured over at least a predetermined duration (or a predetermined number of operations). In one or more embodiments of the present invention, conflict detection may identify patterns that indicate conflict occurrence based on the logged data. The AI/ML model(s) are pre-trained using a training dataset before being deployed on the non-RT RIC 112 in one or more embodiments of the present invention. The AI/ML model(s) can be continuously updated as the non-RT RIC 112 is used. In one or more embodiments of the present invention, the trained AI/ML model(s) can detect conflict-related patterns based on different conflict types, i.e., direct, indirect, and implicit. In one or more embodiments of the present invention, only the non-RT RIC 112 detects cross-domain or inter-domain conflicts. Each pair of domains 201 (and corresponding near-RT RICs 114) that has had a cross-domain conflict(s) with each other are identified as the mutually impacting domains/entities.
The applicant fails to disclose anything about the AI/ML models that are used in paragraph 119. The applicant’s disclosure fails to define what a “mutual impact” is in any technical context. See paragraphs 3, 13, 14, and 119. Paragraph 119 references identifying patterns in logged data but does not provide any description of what the logged data actually comprises or how patterns would be identified. The applicant has failed to describe how the function of identifying a mutual impact is performed according to the standards of written description described in section 2161.01(I) of the MPEP.
Written Description Issue #2
Claims 1, 11, and 17 feature the following limitations:
generating, by the first near-RT RIC using a cross-domain policy generator and instructions of the awareness module, a policy for the first near-RT RIC and the second near-RT RIC by analyzing the first border state and the second border state, the analyzing comprising evaluating, for each of the first and second border states, at least impacted KPIs, impacted E2 nodes and criticality measures included in the respective border state, and the policy comprising one or more rules that specify whether a requesting xApp is permitted to update a parameter of the RAN;
The applicant is claiming a function that takes, as inputs, border states that include impacted KPIs, impacted E2 nodes, and criticality measures and somehow generates, as outputs, a policy comprising one more rules that specify whether a requesting xApp is permitted to update a parameter of the RAN. The applicant has not disclosed how such function is actually performed in a way that meets the written description requirement as described in section 2161.01(I) of the MPEP.
The applicant does not disclose how the first near-RT RIC actually generates a policy by analyzing the first border state and the second border state. The applicant discloses the use of a cross-domain policy generator 202 for the purpose of generating policy. This generator is depicted in Figures 2, 5, 8, and 9. The applicant does not disclose how the policy generator performs the function of generating a policy by analyzing a first border state and a second border state.
Paragraph 103 states the following:
[0103] Referring to FIG. 2, the cross-domain policy generator 202 identifies cross-domain policies when conditions that need attention are identified (e.g., inter-domain conflict detected, operations support requested, etc.). For that purpose, the cross-domain policy generator 202 leverages the instructions INST3 from the awareness module 204. The cross-domain policy generator 202 automatically generates a policy for the near-RT RIC 114. A “policy” is a set of conditions that have to be satisfied before the near-RT RIC 114, or an xApp 132 of the near-RT RIC 114 can perform an operation, and the operation cannot be performed if the condition(s) are not satisfied. The conditions are based on one or more neighboring near-RT RICs 114 in one or more embodiments of the present invention. In one or more embodiments of the present invention, the near-RT RIC 114, upon generating a policy in this manner, shares the policy with one or more neighboring near-RT RICs 114.
The applicant did not disclose anything about INST3 or how it is used. The applicant used the term INST3 in paragraph 98, 101, 103, and 128 but did not provide any description of what such an instruction actually does or what it would mean for a policy generator to “leverage” such an instruction for the purpose of identifying cross-domain policies, as described in the first two sentences of paragraph 103. It is not clear what identifying “cross-domain policies” referenced in the first sentence has to do with the automatic generation of a policy referenced in the third sentence of paragraph 103. Paragraph 103 does not provide a coherent disclosure of generating a policy with respect to INST3 from an awareness module.
Paragraphs 125-128 state the following:
[0125]As described herein, the non-RT RIC 112 creates the awareness module 204 in the near-RT RIC A 114 (first near-RT RIC) that is identified to handle cross-domain conflicts with another near-RT RIC B 114 (second near-RT RIC) (802). For example, the non-RT RIC 112 initiates, in the near-RT RICs 114, INST1 used for the creation of neighboring domains and border states. The near-RT RIC A 114, using the awareness module 204, accumulates the border state information, including E2 nodes, KPIs, xApps 132, etc., of the neighboring near-RT RIC B 114 (804). The near-RT RIC A 114 also shares its own border state information with the near-RT RIC B 114.
[0126]The border and state tracker 206 creates the border digital twin 402 and updates the border state and activity register 208 based on the control plane and user plane information captured in this manner (806).
[0127]The non-RT RIC 112 further triggers INST2 to analyze the border digital twin that is captured to identify potentially mutually impacting domains and cross-domain conflicts (808). The INST2 may trigger one or more scripts to be run at the near-RT RICs A, B 114 to analyze the respectively captured digital twins 401 (810). One or more of the conditions detected by the scripts are forwarded to the cross-domain policy generator 202 (812).
[0128]The non-RT RIC 112 triggers INST3 to analyze the generated cross-domain conflict policies to determine prioritization and consequent leader proclamation (814). The near-RT RICs A, B 114 perform a criticality analysis and priority analysis on the policies to compare them (816). As described herein, several other parameters from the border state data structure 300 can be used to break a tiebreaker between the policies. The generated policies are shared among the near-RT RICs A, B 114 using direct communication via the NX1 interface (818).
These paragraphs provide literal support for the concept of analysis of border states but they do not describe how the analysis is performed or how such analysis would be used to generate a policy. Paragraph 125 states that the near-RT RIC uses the awareness module to accumulate border state information and share it with other near RT-RICs. Paragraph 126 states that a border and state tracker 206 creates a border digital twin and updates the boarder state and activity register 208 based on control and user plane information captured in this manner; the applicant is not clear what “in this manner” refers to. Paragraph 127 requires that the non-RT RIC 112 further triggers INST2 to analyze the border digital conflicts. INST2 is presumed to a second instruction from the non-RT RIC. INST2 is described as triggering one or more scripts to be run at the near-RT RIC to analyze the captured digital twins. There is no description of these scripts or what functions they perform to analyze the digital twins. Conditions detected by the scripts are forwarded to the policy generator 202. There is no description of what these conditions comprise. Paragraph 128 then references “the generated cross-domain policies” even though there is no description previously in paragraph 127 of generating a policy. Paragraph 128 then appears to analyze such polices to compare them but there is no description of this comparison. The final sentence of paragraph 128 references “the generated policies” but there is no description of actually generating policies with respect to Figure 8.
Paragraphs 138-142 state the following:
[0138]In one or more embodiments of the present invention, operational intents received from the operator are essential for conflict mitigation as they reflect the operator’s desires regarding network operation and therefore are used to identify the optimal xApp behavior for each network state. In general, the xApp actions at any time must be such that they maintain satisfactory KPIs or improve the degraded KPIs while keeping intent into consideration. The cross-domain conflict generator 202 is aware of the optimization goals of each xApp 132 and the parameters that each xApp 132 can affect. Only then the cross-domain conflict generator 202 can tune the xApp activity according to the intent requirements.
[0139]In one or more embodiments of the present invention, the cross-domain conflict generator 202 uses reinforcement learning to determine the policies.
[0140]Reinforcement learning is a subfield of machine learning and is also a general-purpose formalism for automated decision-making and AI. The goal of reinforcement learning is to take suitable action to maximize reward in a particular situation. Reinforcement learning (RL) is not strictly supervised as it does not rely only on a set of labeled training data but is not unsupervised learning because an agent is trained to maximize a reward. The agent needs to find the “right” actions to take in different situations to achieve its overall goal. There are three basic concepts in reinforcement learning: state, action, and reward. The algorithm (agent) evaluates a current situation (state), takes action, and receives feedback (reward) from the environment after each act. Positive feedback is a reward, and negative feedback is a punishment for making a mistake. Markov Property: requires that “the future is independent of the past given the present.” RL relies on the state transition probability, which indicates, given a present state, what is the probability the next state will occur. Further, in RL, all state transitions can be defined in terms of a State Transition Matrix P, where each row provides the transition probabilities from one state to all possible successor states. When an agent is transitioned from the current state to the next state, it is either rewarded positively or negatively based on the actions of the agent following a particular policy.
[0141]For example, the cross-domain conflict generator 202 can generate a policy:xApp1 may update param1 to val1 or val2 on E2 node CU/DU1, xApp2 must be blocked from changing param2 but can change param3 on the CU/DU1 and CU/DU2.
[0142]Cross-domain conflict generator 202 leverages the policies when responding to E2 guidance request that causes an update to one or more xApps 132. For example, in the above policy example, if xApp2 attempts to update the param2 on the E2 node CU/DU1, the cross-domain conflict generator 202 responds with rejection. On the other hand, the cross-domain conflict generator 202 does not block xApp2 from making changes on the param3 on the same E2 node.
[0143]In one or more embodiments of the present invention, the cross-domain conflict generator 202 is able to record the instructions received in the individual policies and retrieve these when xApps 132 call E2 guidance requests and verify the requested xApp activity.
In these paragraphs, the applicant is attempting to state that generator 202 uses reinforcement learning to determine policies. Paragraph 138 makes it clear that in order to implement reinforcement learning operations, intents received by the operator and optimization goals would be necessary in order to implement reinforcement learning. Paragraph 140 provides a generic description of reinforcement learning but paragraph 140 does not describe the applicant’s specific algorithm (agent) that evaluates the current situation, takes action, and receives feedback. Paragraph 140 is the equivalent of telling a cook that they need a recipe without providing the actual recipe for generating policy. Paragraph 141 states that generator 202 can generate policy and provides an example of what a result of implementing a policy might look like but does not describe how the policy is actually generated. Paragraphs 142 and 143 imply that the policy generator does not generate policies at all but instead implements existing policies.
In each independent claim, the applicant is claiming the function of generating a policy for the first near-RT RIC and the second near-RT RIC by analyzing the first border state and the second border state but the applicant has failed to disclose how this function is actually performed. The applicant has not disclosed how the analyzing is performed or how it affects the generation of a policy. Paragraphs 54-65 and 110 of the applicant’s specification explain that these are not well-known concepts so there is an expectation that the applicant would explain how they are performed in their disclosure. The applicant has failed to do this, as explained. Consequently, the applicant has failed to comply with the written description requirement based on the guidance given in sections 2161.01(I) and 2163.03(V) of the MPEP.
The following amended language from claims 1, 11, and 17 was not disclosed at all:
evaluating, for each of the first and second border states, at least impacted KPIs, impacted E2 nodes and criticality measures included in the respective border state,
The applicant did not describe any evaluation of “impacted KPIs” and “impacted E2 nodes” that are included in a respective border state where the first border state is created in some way that is “represents attributes” (second “creating” limitation) and where the second border state that in some way “represents attributes” (second “receiving” limitation). There is no description of what the currently claimed “impacted” KPIs and E2 nodes would comprise and no way to infer how they are evaluated to analyze the first and second border states to generate a single policy for the first and second near-RT RICs, as claimed in each independent claims. Paragraph 77 references a “criticality measure” used for logging operational criticality but makes not attempt to define what such a measure is or how it is somehow evaluated to generate a policy.
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.
Claim 1 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being incomplete for omitting essential steps, such omission amounting to a gap between the steps. See MPEP § 2172.01. The omitted steps are:
Claims 1 is amended as follows:
receiving, by the first near-RT RIC, from a non-Real-Time RAN Intelligent Controller (non-RT RIC), identification of a second near-RT RIC that controls a second domain, the first domain and the second domain having been identified by the non-RT RIC as having mutual impact;
The claimed action of identifying the first and second domains as having mutual impact, performed by the non-RT RIC, is referred to in the claim as having happened in the past tense, presumably at some point prior to the execution of the method of claim 1. This action is important enough that the applicant has inserted it in the claim, yet the action does not appear to be part of the claim scope since it is referred to in the past tense while the rest of the actions are referred to in the present tense. The action of identifying domains having mutual impact appears to be essential, because the applicant is describing it in the claim. The scope of the claim, however, omits this step. The applicant needs to amend the claim to explicitly state that the non-RT RIC identifies a first and second domain having mutually impact in order to clearly cover this limitation as it is disclosed in paragraphs 117-119. Paragraphs 119 and 120 indicate that that block 704 is essential in order to perform the first “creation” limitation of claim 1.
Claims 11 and 17 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being incomplete for omitting essential elements, such omission amounting to a gap between the elements. See MPEP § 2172.01. The omitted elements are:
Claim 11 is amended to have the first near RT-RIC performing the following action:
receive, from the non-RT RIC, identification of the second near-RT RIC that controls the second domain, the first domain and the second domain having been identified by the non-RT RIC as having mutual impact;
Claims 17 is amended as follows:
receiving, by the first near-RT RIC, from a non-Real-Time RAN Intelligent Controller (non-RT RIC), identification of a second near-RT RIC that controls a second domain, the first domain and the second domain having been identified by the non-RT RIC as having mutual impact;
As pointed out in the rejection of claim 1 for omitting essential steps, the claim language features language which covers an action performed by the non-RT RIC. The system of claim 11 does not cover the non-RT RIC and its essential functionality, despite the claim language stating that the non-RT RIC performs the action of identifying mutual impact. The computer program product of claim 17 covers instructions which are claimed as being executed by the first near-RT RIC since the actions of claim 17 are claimed as being performed by the first near-RT RIC. The computer program product of claim 17 does not cover the non-RT RIC and its essential functionality, despite the claim language stating that the non-RT RIC performs the action of identifying mutual impact.
Claims 1, 11, and 17 recite the limitation "the one or more xApps being executed by the first near-RT RIC" in the second creating limitation of each claim. There is insufficient antecedent basis for this limitation in the claim. The claims do not specify any “xApp” or that the first near-RT RIC executes anything.
Claims 1, 11, and 17 recite the limitation "the one or more xApps being executed by the second near-RT RIC" in the second receiving limitation of each claim. There is insufficient antecedent basis for this limitation in the claim. The claims do not specify any “xApp” or that the second near-RT RIC executes anything.
Claims 1, 11, and 17 recite the limitation "the border state tracker" in the final “when” condition of the final limitation. There is insufficient antecedent basis for this limitation in the claim.
Claims 1, 11, and 17 recite the limitation "the operational intents specified in the policy" in the final line of each claim. There is insufficient antecedent basis for this limitation in the claim. The claim previously states that the border state tracker stores operational intents but there is not recitation that the policy specifies operation intents.
The term “consistent with” in claims 1, 11, and 17 is a relative term which renders the claim indefinite. The term “consistent with” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. In the final line of each independent claim, the applicant claims “ensuring the parameter remains consistent with the operation intents specified in the policy”. The applicant did not describe what it means for a parameter to be consistent with an operation intent specified in a policy and thus it is not clear what such claimed consistency would comprise.
Specification
The amendment filed 3/4/2026 is objected to under 35 U.S.C. 132(a) because it introduces new matter into the disclosure. 35 U.S.C. 132(a) states that no amendment shall introduce new matter into the disclosure of the invention. The added material which is not supported by the original disclosure is as follows: The specification appears to be amended to correspond to the new claim language. The applicant’s remarks regarding written description support for the new claim language show that the new language was contrived from multiple parts of the disclosure that were not originally disclosed together to form a coherent process. The clarity rejections show that the new claim language is not event coherent or clear. The particular incoherence shown in the clarity rejections was not explicitly reflected in the original disclosure and thus constitutes new matter. The rejections of the new claims based on written description also show the amendments to the specification to cover new matter.
Applicant is required to cancel the new matter in the reply to this Office Action.
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 DOUGLAS B BLAIR whose telephone number is (571)272-3893. The examiner can normally be reached Monday-Friday 9am-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, Glenton Burgess can be reached at 571-272-3949. 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.
/DOUGLAS B BLAIR/Primary Examiner, Art Unit 2454