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 .
1. This is in response to communication filed on 3/05/26 in which claims 1-10 and 12-14 are pending.
Response to Arguments
2. Applicant's arguments filed have been fully considered but they are not persuasive.
Applicant’s representative argues that Szilagyi teaches “the second entity determines the deployment information in response to the request”. However, Szilagyi clearly teaches “ The deployment of a self-learning CL commences on a request coming from an external entity above the orchestrator function (e.g., from the oper ator). The trigger should identify the CL and the deployment scope. The CL is represented by the list of automation logic micro-services, wherein each automation logic micro-service is represented by its implementation and the objective and input domain metadata (Figure 14). The first step of the self-learning CL deployment (Figure 15) is to collect the measurement micro-service dependencies of the self-learning” (See pages 190-192, Implementation and Benefits and Figure 15); One with ordinary skill in the art can confidently conclude that Szilagyi clearly teaches wherein the deployment information is determined in response to the request since the deployment scope and the Cl is triggered by an incoming request.
Claim Rejections - 35 USC § 102
3. 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.
4. Claims 1-2, 4, 10-14 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by I2BN: Intelligent Intent Based Networks to Szilagyi.
a. As per claim 1, Szilagyi teaches a method for configuring a system, the method comprising: a first entity obtaining function information identifying a Cloud-Native Network Function, CNF, to be provided by the system (See pages 191 and 193, Data management aspects, Cloud infra measurements from the on-premise or public cloud infrastructure hosting the network functions. With cloud native becoming the new standard in network function architecting, additional dimensions of operation such as the state of the supporting infrastructure and cloud orchestration actions have to be considered by network and service automation); using the obtained function information, the first entity identifying the CNF to be provided by the system (See page 177, Auto-generating the CL Hierarchy, Finding the right micro-services and chaining them in the right way to form a closed loop needs to happen automatically already during the intent fulfilment phase and should continue during intent assurance. Intent assurance may use the same or potentially changed closed loop chain compared to fulfilment – as assurance may need to onboard components in addition to fulfilment such as real time measurements; whereas assurance may not need components dedicated for one-time service onboarding, only useful during fulfilment…. closed loop may receive inputs from its hierarchically superior CL. This input is related to the fulfilment or assurance of an intent. Additionally, the CL may collect context and measurements from any other entity, such as domain controllers, or even other CLs. These inputs are used by the CL’s internal logic and may be implementation specific]); the first entity transmitting (s406) to a second entity a request for deployment information, wherein the deployment information is about a deployment of one or more microservices for providing the identified CNF (See page 173, Intent Life-Cycle and Interaction with Network Operations, The lifecycle of some intents may end at the fulfilment case, if the intent’s goal simply describes the availability or presence of a service. In that case, onboarding all necessary software artifacts (e.g., software images) and deploying the related (micro-)services (starting and scaling containers) completes the goal of the intent by definition. However, in other cases, the intent’s objective attributes certain operational criteria (related to availability, quality of service, end user experience, etc.) in addition to the need of existence of a service. Those intents have their lifecycle tied to the operation of the referred service and may require frequent recurring actions executed via the APIs of the available domain/resource controllers to keep those operational criteria achieved. As such actions need to be triggered automatically by the Intent Manager who is responsible for that (part of the) intent, Intent Managers will need to leverage closed loops [14] (Figure 6). The closed loops may be created purposefully by the IM or may exist anyways but are utilized by potentially multiple IMs. The closed loops have to address network and service state monitoring, analytics and actions. Monitoring may include collection of performance management (PM) or fault management (FM) counters; resource, network and service state modelling; application insight; collected across e2e, domain and individual resource scopes. Collected data is then analysed. The purpose of the analytics is to assess the system’s intent compliancy, that is, how much the intent’s objectives are met, and to derive potential actions that would bring the system closer (ideally, to meet) those objectives); the first entity receiving from the second entity the requested deployment information (See pages 173-174, Intent Life-Cycle and Interaction with Network Operations, IMs have to implement reporting towards the entity which ingested the intent they are working on. Reporting requires abstraction and aggregation and pages 177-178, Auto-generating the CL hierarchy]), wherein the second entity determines the deployment information in response to the request (See page 175, Design Principles and pages 190-192, Implementation and Benefits); and using the deployment information, triggering to deploy in the system said one or more microservices for providing the CNF (See page 190, Implementation And Benefits, The deployment of a self-learning CL commences on a request coming from an external entity above the orchestrator function (e.g., from the operator). The trigger should identify the CL and the deployment scope. The CL is represented by the list of automation logic micro-services, wherein each automation logic micro-service is represented by its implementation and the objective and input domain metadata ).
b. As per claim 12, Szilagyi teaches an apparatus for configuring a system, the apparatus being configured to: obtain (s402) function information identifying a Cloud-Native Network Function, CNF, to be provided by the system (See pages 191 and 193, Data management aspects, Cloud infra measurements from the on-premise or public cloud infrastructure hosting the network functions. With cloud native becoming the new standard in network function architecting, additional dimensions of operation such as the state of the supporting infrastructure and cloud orchestration actions have to be considered by network and service automation); using the obtained function information, identify the CNF to be provided by the system (See page 177, Auto-generating the CL Hierarchy, Finding the right micro-services and chaining them in the right way to form a closed loop needs to happen automatically already during the intent fulfilment phase and should continue during intent assurance. Intent assurance may use the same or potentially changed closed loop chain compared to fulfilment – as assurance may need to onboard components in addition to fulfilment such as real time measurements; whereas assurance may not need components dedicated for one-time service onboarding, only useful during fulfilment…. closed loop may receive inputs from its hierarchically superior CL. This input is related to the fulfilment or assurance of an intent. Additionally, the CL may collect context and measurements from any other entity, such as domain controllers, or even other CLs. These inputs are used by the CL’s internal logic and may be implementation specific]); transmit to a second entity a request for deployment information, wherein the deployment information is about a deployment of one or more microservices for providing the identified CNF (See page 173, Intent Life-Cycle and Interaction with Network Operations, The lifecycle of some intents may end at the fulfilment case, if the intent’s goal simply describes the availability or presence of a service. In that case, onboarding all necessary software artifacts (e.g., software images) and deploying the related (micro-)services (starting and scaling containers) completes the goal of the intent by definition. However, in other cases, the intent’s objective attributes certain operational criteria (related to availability, quality of service, end user experience, etc.) in addition to the need of existence of a service. Those intents have their lifecycle tied to the operation of the referred service and may require frequent recurring actions executed via the APIs of the available domain/resource controllers to keep those operational criteria achieved. As such actions need to be triggered automatically by the Intent Manager who is responsible for that (part of the) intent, Intent Managers will need to leverage closed loops [14] (Figure 6). The closed loops may be created purposefully by the IM or may exist anyways but are utilized by potentially multiple IMs. The closed loops have to address network and service state monitoring, analytics and actions. Monitoring may include collection of performance management (PM) or fault management (FM) counters; resource, network and service state modelling; application insight; collected across e2e, domain and individual resource scopes. Collected data is then analysed. The purpose of the analytics is to assess the system’s intent compliancy, that is, how much the intent’s objectives are met, and to derive potential actions that would bring the system closer (ideally, to meet) those objectives); receive from the second entity the requested deployment information (See pages 173-174, Intent Life-Cycle and Interaction with Network Operations, IMs have to implement reporting towards the entity which ingested the intent they are working on. Reporting requires abstraction and aggregation and pages 177-178, Auto-generating the CL hierarchy]) wherein the second entity determines the deployment information in response to the request (See page 175, Design Principles and pages 190-192, Implementation and Benefits); and using the deployment information, trigger to deploy in the system said one or more microservices for providing the CNF (See page 190, Implementation And Benefits, The deployment of a self-learning CL commences on a request coming from an external entity above the orchestrator function (e.g., from the operator). The trigger should identify the CL and the deployment scope. The CL is represented by the list of automation logic micro-services, wherein each automation logic micro-service is represented by its implementation and the objective and input domain metadata ).
c. As per claims 2 and 13, Szilagyi teaches the claimed invention as described above. Furthermore, Szilagyi teaches wherein the CNF is any one of the followings: User Plane Function, UPF, Session Management Function, SMF, Access and Mobility Management Function, AMF, Policy Control Function, PCF, Application Function, AF, IP Multimedia Subsystem, IMS, and Call Session Control Function, CSCF (See page 165, Challenges of Managing a Programmable Network).
d. As per claim 4, Szilagyi teaches the claimed invention as described above. Furthermore, Szilagyi teaches wherein said one or more microservices are for collectively providing the CNF, and the function information comprises one or more microservice identifiers identifying said one or more microservices (See page 176-178).
e. As per claim 10, Szilagyi teaches a computer program comprising instructions which when executed by processing circuitry cause the processing circuitry to perform the method of claim 1 (See pages 165 and 166 and figures 2 and 3).
f. As per claim 14, Szilagyi teaches the claimed invention as described above. Furthermore, Szilagyi teaches an apparatus (500) comprising: a processing circuitry (502); and a memory (541), said memory containing instructions executable by said processing circuitry, whereby the apparatus is operative to perform the method of claim 1 (See page 197 and figures 2 and 3).
Claim Rejections - 35 USC § 103
5. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
6. Claims 3, 5-9 are rejected under 35 U.S.C. 103 as being unpatentable over by I2BN: Intelligent Intent Based Networks to Szilagyi in view of U.S. Publication No. 2022/0035650 to Banerjee et al.
a. As per claim 3, Szilagyi teaches the claimed invention as described above. However, Szilagyi fails to explicitly teaches wherein the function information includes a CNF identifier identifying the CNF.
Banerjee et al teaches wherein the function information includes a CNF identifier identifying the CNF (See paragraph [0090-0091]).
It would have been obvious to one with ordinary skill in the art to incorporate the teaching of Banerjee et al in the claimed invention of Szilagyi in order to orchestrate distributed operations with multiple virtual infrastructures (See paragraph [0007]).
b. As per claim 5, Szilagyi teaches the claimed invention as described above. However, Szilagyi fails to teach based on analyzing the obtained function information, the first entity selecting a third entity from a group of entities, wherein the third entity is mapped to the CNF; the first entity transmitting to the third entity a request for information about one or more operational characteristics of the system to modify; and the first entity receiving from the third entity the requested information about said one or more operational characteristics to modify.
Banerjee et al teaches based on analyzing the obtained function information, the first entity selecting a third entity from a group of entities, wherein the third entity is mapped to the CNF (See paragraph [0008 and 0068], local orchestrator); the first entity transmitting to the third entity a request for information about one or more operational characteristics of the system to modify (See paragraph [0054 and 0068-0069]) ; and the first entity receiving from the third entity the requested information about said one or more operational characteristics to modify (See paragraph [0068-0069 and 0092-0093]).
c. As per claim 6, Szilagyi teaches the claimed invention as described above. However, Szilagyi fails to teach wherein the function information comprises one or more operational requirements related to providing the CNF, and the method further comprises: the third entity determining whether the system currently satisfies said one or more operational requirements; and as a result of determining that the system currently does not satisfy said one or more operational requirements, the third entity determining said one or more operational characteristics to modify.
Banerjee et al teaches wherein the function information comprises one or more operational requirements related to providing the CNF, and the method further comprises: the third entity determining whether the system currently satisfies said one or more operational requirements (See paragraph [0085-0086]); and as a result of determining that the system currently does not satisfy said one or more operational requirements, the third entity determining said one or more operational characteristics to modify (See paragraph [0093-0094]).
It would have been obvious to one with ordinary skill in the art to incorporate the teaching of Banerjee et al in the claimed invention of Szilagyi in order to orchestrate distributed operations with multiple virtual infrastructures (See paragraph [0007]).
d. As per claim 7, Szilagyi teaches the claimed invention as described above. However, Szilagyi fails to teach wherein the second entity is selected from a group of second entities based on said one or more operational characteristics to modify.
Banerjee et al teaches wherein the second entity is selected from a group of second entities based on said one or more operational characteristics to modify (See paragraph [0099 and 0102]).
e. As per claim 8, Szilagyi teaches the claimed invention as described above. However, Szilagyi fails to teach wherein the deployment information includes one or more references to one or more HELM files or charts.
Banerjee et al teaches wherein the deployment information includes one or more references to one or more HELM files or charts (See paragraph [0071-0072, 0074]).
It would have been obvious to one with ordinary skill in the art to incorporate the teaching of Banerjee et al in the claimed invention of Szilagyi in order to orchestrate distributed operations with multiple virtual infrastructures (See paragraph [0007]).
f. As per claim 9, Szilagyi teaches the claimed invention as described above. However, Szilagyi fails to teach further comprising: obtaining one or more deployment templates; and adding said one or more HELM files or charts into said one or more deployment templates.
Banerjee et al teaches obtaining one or more deployment templates; and adding said one or more HELM files or charts into said one or more deployment templates (See paragraph [0050]).
It would have been obvious to one with ordinary skill in the art to incorporate the teaching of Banerjee et al in the claimed invention of Szilagyi in order to orchestrate distributed operations with multiple virtual infrastructures (See paragraph [0007]).
Conclusion
7. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Publication No. 2020/0228605 to Dodd-Noble et al teaches Selecting A user Plane Function.
U.S. Publication No. 2021/0117360 to Kutch et al teaches Network and Edge Acceleration Tile Architecture.
8. THIS ACTION IS MADE FINAL. 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.
9. Any inquiry concerning this communication or earlier communications from the examiner should be directed to DJENANE BAYARD whose telephone number is (571)272-3878. The examiner can normally be reached 9-5.
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.
7. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John Follansbee can be reached at (571)272-3964. 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.
/DJENANE M BAYARD/Primary Examiner, Art Unit 2444
Prosecution Insights