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 .
Claims 1-3, 5, 6, 9-11, 13-14, 17-19 and 22-23 are pending in this office action.
Claims 4, 7-8, 12, 15-16, 20-21 and 24 are cancelled.
Claims 1, 9 and 17 are amended.
Response to Arguments
Applicant's arguments filed 07/11/2025 have been fully considered but they are not persuasive.
Applicant’s argument:
The Office appears to rely on the VNF package described by Melkild to reject the repository structure recited by claim 1. However, this reliance is faulty. At column 14, Melkild describes that a VNF provider constructs a VNF…… However, nowhere does Melkild teach, suggest, or describe that the VNF package is a repository structure to hold pipelines. In fact, nowhere does Melkild appear to teach, suggest, or describe a repository structure created by a service provider system, as recited
by claim 1. Additionally, nowhere does Melkild teach, suggest, or describe a package from a vendor of a plurality of vendors that comprises at least one pipeline, as further recited by claim 1. Moreover, Melkild fails to teach, suggest, or describe a package comprising at least one pipeline that is parametrized to accept site-specific data provided by the service provider system.
Examiner response:
Melkild discloses a VNF package, as acknowledged by the applicant’s argument [page 8], but the applicant’s representative fail to address the issue described above in relation to repository, and parametrized pipeline.
The package as described in Melkild also include pipelines and the package is stored in an archive that is a catalog=database. This is the repository and you can refer to fig. 1 component 136:
Col 4lines14-18 “The SDC module 106 provides APIs which are usable by other modules for querying VNF/service artifacts, uploading artifacts, and retrieving artifacts. Service and VNF artifacts are stored in a catalog 136. In some embodiments, this catalog is a database.”;
The SDC includes a set of pipelines that provides the platform for service modeling, creation, testing and distribution.
the VNF package 400 may also contain any VNFC specific lifecycle script files 410 supplied by the VNF provider.
Additionally, a VNFC Descriptor 300 may also include an order attribute 310. An order attribute may be used to control the start/stop order of the VNFCs during VNF lifecycle operations such as instantiate and upgrade.
Additionally, any VNF specific lifecycle management (onboard, deploy, start, etc.) scripts 406 are included.
Those are steps included in the package. Those steps are pipeline stage.
In relation to Tejaprakash, the pipeline include site data, and let’s focus on testing:
Because the VNF can interacts with other VNF and uses an SDN, test controller will test this configuration(parameters in interacting with other VNF and SDN):
[0064] “In this case, test control device 220 can execute testing for a test package in connection with other VNFs and SDNs that are to be used for networking to ensure interoperability of current VNFs and SDNs and one or more VNFs or SDNs of the test package.”;
After testing, the package is certified and the configuration is linked to the package(pipeline):
[0082] “In some implementations, test controller 516 can perform one or more post reporting steps, such as package certification step 624 (e.g., certifying that the VNF satisfies one or more testing criteria for deployment), package acceptance step 626 (e.g., accepting the VNF for deployment step), VNF deployment step 628 (e.g., deploying the VNF), and/or the like. In some implementations, test controller 516 can perform one or more other post reporting steps, such as service chain configuration step 630 (e.g., configuring the VNF to operate with one or more other SDN functionalities in a service function chain (SFC)), service orchestration step 632 (e.g., dynamically provisioning and re-provisioning deployed NFVs in a service chain)”;
Applicant’s argument:
The Office acknowledges the failure of Melkild to teach this recitation and instead relies on the teachings of Tejaprakash. However, this reliance is faulty. Tejaprakash describes using a security verification tool to determine whether a set of security criteria are satisfied. However, using a set of security criteria, as described by Tejaprakash, fails to teach, suggest, or describe creating a secrets management structure for a network function, as recited by claim 1.
Examiner response:
The specification [0020] of this instant application outlines the following:[0020] “a secret management solution (e.g., store, transmit, and manage security authentication credentials)”;
Tejaprakash discloses the following:
[0043] “ In some implementations, test control device 220 can perform security validation procedures. For example, test control device 220 can authenticate the test package for testing (e.g., based on a user privilege, a user role, a package source, etc.).
[0062]”In this case, test control device 220 can import a test package into a sandbox environment (e.g., an instance of network devices 250) and utilize a security verification tool to determine whether a set of security criteria are satisfied, such as resilience to unauthorized access, authentication procedures, and/or the like.”;
Claim Rejections - 35 USC § 103
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.
Claims 1-3, 5-6, 9-11, 13-14, 17-19 and 22-23 are rejected under 35 U.S.C. 103 as being unpatentable over Melkild et al US11018899B1 in view of Tejaprakash et al US20190104047A1.
As per claim 1, Melkild discloses a method comprising:
creating, by a service provider system comprising a processor:
Col 12 lines 40-45” The components of computer system/server 702 may include, but are not limited to, one or more processors or processing units 704, a system memory 706, and a bus 708 that couples various system components including system memory 706 to processor 704”.
at least one repository structure to hold pipelines, artifacts, image and code used to create a network function for a plurality of vendors:
Col 3 lines 12-18 “Each VNF specifies its deployment and operational behavior in a deployment template known as a VNF Descriptor (VNFD). This descriptor along with the VNF software bundle are delivered to an NFV management system in an archive known as a VNF Package. A VNF may be implemented using one or more VNF Components (VNFCs). A VNFC is an internal component of a VNF that provides a subset of that VNF's functionality. The main characteristic of a VNFC is that it maps n:1 with a Virtualized Container (VC) when the function is deployed. The term Virtualized Container (VC) is used herein to describe a Virtual Machine (VM) or operating system container. VNFCs are in turn made up of one or more software modules. Each module may spawn one or more operating system processes when deployed”;
Col 4 lines 16-17 ”VNF Packages 400 are stored in an SDC Catalog 136 (See FIG. 1) in an NFV System 100 (See FIG. 1).”;
Examiner interpretation:
The archive is stored in a VNF system in a catalog(database see fig. 1(136)).
The archive includes component as image , artifact and code. The VNFC maps N:1 and deploy to container. Pipeline steps: map [Wingdings font/0xE0] deploy.
receiving, by the service provider a package from a vendor of the plurality of vendors:
Col 8 lines 3-9 “In accordance with one or more embodiments of the present application, the VNF package 400 may also contain any VNFC specific lifecycle script files 410 supplied by the VNF provider. Further, in accordance with one or more embodiments of the present application, the VNF package 400 may also contain any VNFC software loads 4102 supplied by the VNF provider”;
Col 6 lines17-20 “That software may vary by type of cloud (public/private), vendor (e.g., Amazon, Microsoft, etc.) and/or different distributions (e.g., standard OpenStack, Red Hat OpenStack, etc.).’;
wherein the package comprises at least one pipeline:
Fig. 4 and “Additionally, any VNF specific lifecycle management (onboard, deploy, start, etc.) scripts 406 are included”;
at least one artifact , code used to create a network function for the vendor:
Fig. 5 and col 50-53 “An artifacts directory 514 may be present to hold scripts and binary software images delivered in this package archive 500. Under the artifacts directory, a scripts directory 516 may be present to hold the VNF lifecycle management scripts 518”;
at least one image:
fig. 4 and Col 7 lines 64-65” The actual binary images for each VC (VDU) 408 are also supplied.”;
and a bill of material describing what the package is delivering to the service provider system:
Fig. 4 description :col 7 lines “Each package contains a manifest file 402 which specifies the list of contents it contains”;
defining, by the service provider system, a schema to support environment variables for a network function type of the network function:
Col 6 lines 1-9 “ In accordance with one or more embodiments of the present application, the Multi-VIM/Cloud Adapter 156 enables deployment and execution of VNFs on multiple infrastructure environments which may vary by vendor, cloud type (public or private) and/or software distribution. The Adapter 156 effectively provides a cloud mediation layer which prevents vendor lock-in and decouples the evolution of the NFV management system 108 from the underlying cloud infrastructures 104”;
and instructing, by the service provider system, the at least one repository structure to exhibit version control and change management behavior.
Col 8 lines 12-18 “It should be noted that in some embodiments, the VNFC software loads 412 are also included in the VC image binary file 408 in order to ease and expedite initial deployment. Further, in accordance with one or more embodiments of the present application, the VNF package 400 may also contain VC upgrade scripts 414 supplied by the VNF provider. These VC upgrade scripts 414 enable VC changes which may be required in order to run a newer version of one or more VNFCs. Additionally, the VNF package may include other files 416, which may consists of, but are not limited to, test files, license files and change log files”;
Examiner interpretation:
Melkild also discloses promoting the VNF package to production environment:
Col 14 lines 57-59In step 806, an SDC 648 (See FIG. 6) receives the VNF Package Archive 500 (See FIG. 5) from a VNF Provider which includes a VNF Package 400 (See FIG. 4).
Col 15 lines 52-55” In step 814, the VNFD in enabled in the SDC catalog 136 (See FIG. 1). In some embodiments, the SDC 648 (See FIG. 6)/106 (See FIG. 1) automatically enables the VNFD once the on-boarding process has completed.
But not explicitly:
wherein the at least one pipeline is parameterized to accept site-specific data provided by the service provider system; certifying, via a service provider lab network, that the at least one pipeline, the at least one artifact, the at least one image, and the code of the package generate deployment for the network function; after certifying that the at least one pipeline, the at least one artifact, the at least one image, and the code generate deployment for the network function, promoting, by the service provider system, the package to a service provider production network; and merging, by the service provider system, the at least one pipeline with the site-specific data;
creating, by the service provider system, a secrets management structure for the network function;
Tejaprakash discloses:
wherein the at least one pipeline is parameterized to accept site-specific data provided by the service provider system:
[0081]“For example, test controller 516 can use tests of test controller 516, tests of external tools 530, and/or functionalities of external tools 530 to cause traffic to be routed from source VM 524 to target VM 528 using tested VNF 526 (e.g., an instantiated instance of the VNF received for testing), which can correspond to test execution step 618”;
[0064] “In this case, test control device 220 can execute testing for a test package in connection with other VNFs and SDNs that are to be used for networking to ensure interoperability of current VNFs and SDNs and one or more VNFs or SDNs of the test package.”;
certifying, via a service provider lab network, that the at least one pipeline, the at least one artifact, the at least one image, and the code of the package generate deployment for the network function:
[0082] “ In some implementations, test controller 516 can perform one or more post reporting steps, such as package certification step 624 (e.g., certifying that the VNF satisfies one or more testing criteria for deployment), package acceptance step 626 (e.g., accepting the VNF for deployment step), VNF deployment step 628 (e.g., deploying the VNF), and/or the like.”
and merging, by the service provider system, the at least one pipeline with the site-specific data;
[0082]In some implementations, test controller 516 can perform one or more other post reporting steps, such as service chain configuration step 630 (e.g., configuring the VNF to operate with one or more other SDN functionalities in a service function chain (SFC)), service orchestration step 632 (e.g., dynamically provisioning and re-provisioning deployed NFVs in a service chain). “;
after certifying that the at least one pipeline, the at least one artifact, the at least one image, and the code generate deployment for the network function, promoting, by the service provider system, the package to a service provider production network:
[0068]” In some implementations, test control device 220 can certify a test package as satisfying one or more testing criteria (e.g., passing each test, passing a threshold quantity of tests, satisfying one or more performance criteria, etc.). In some implementations, test control device 220 can accept a test package. For example, if the test package satisfies one or more testing criteria, test control device 220 can automatically deploy the VNF into a network to perform SDN functionality.
creating, by the service provider system, a secrets management structure for the network function:
[0043] “ In some implementations, test control device 220 can perform security validation procedures. For example, test control device 220 can authenticate the test package for testing (e.g., based on a user privilege, a user role, a package source, etc.).
[0062]”In this case, test control device 220 can import a test package into a sandbox environment (e.g., an instance of network devices 250) and utilize a security verification tool to determine whether a set of security criteria are satisfied, such as resilience to unauthorized access, authentication procedures, and/or the like.”;
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Tejaprakash into teachings of Melkild to authenticate and authorize workloads in an efficient, flexible, and scalable manner. Furthermore, based on automating test generation, execution, and validation, test control device 220 can reduce errors relative to manual testing, and can enable thousands and/or millions of tests to be performed, which can be infeasible for a human, thereby improving a quality of VNFs that are deployed.[Tejaprakash 0085].
As per claim 2, the rejection of claim 1 is incorporated and furthermore Melkild discloses:
creating, by the service provider system, instance specific data to satisfy the schema required for the network function type:
Col 3 lines 25-33 “ A VNF instance (VNFI) is a run-time instantiation of the VNF software resulting from completing the instantiation of its VNFCs and the connectivity between them. As multiple instances of a VNF can exist in the same domain, the terms VNF and VNF Instance (VNFI) may be used interchangeably herein. Similarly, VNFC instance (VNFCI) is a run-time instantiation of a VNFC deployed in a particular VC. It has a lifecycle dependency with its parent VNFI. As multiple instances of a VNFC can exist in the same domain, the terms VNFC and VNFC Instance (VNFCI) may also be used interchangeably herein.”
Examiner interpretation: A VNF is the implementation of a network function that can be deployed in an NFV. A VNFD 200 includes the requirement for VNFC deployment and onboarding as in Fig. 2;
storing, by the service provider system, the at least one artifact into a framework defined during a design phase:
Col 4 lines24-26 “The management module 108 operates on a set of service and VNF artifacts which are stored in and retrieved from the SDC module 106.”
As per claim 3, the rejection of claim 1 is incorporated and furthermore Melkild discloses:
presenting a graphical user interface-based tool through which a user can instruct the service provider system to deploy the network function.:
Col 6 lines 20-24 “30) In accordance with one or more embodiments of the present application, UI module 110 provides multiple User Interfaces (UIs) into the NFV management module 108. “;
Col 5 lines 35-45 “In accordance with one or more embodiments of the present application, the Application Controller (APPC) 152 supports VNF lifecycle management operations which include, but are not limited to, deploy, scale, heal, migrate, start and stop.”
Examiner interpretation:
Fig. 1 include a module 110 that is used to manage the functionality of the management 108. Among the management function is deployment and module 110 that include a GUI 162.
As per claim 5, the rejection of claim 1 is incorporated and furthermore Melkild discloses:
wherein the network function comprises a virtual network function:
Col 1 lines 57-60 “these decupled software implementations are called Virtual Network Functions (VNFs). Each of these functions is made up of one or more software components which are known as VNF Components (VNFCs)”;
As per claim 6, the rejection of claim 1 is incorporated and furthermore Melkild discloses:
wherein the network function comprises a containerized network function:
Col 9 lines 20-25 “Both embodiments provide virtualization environments in which the VNF Component Instances (VNFCI) 626 and 628 reside. As the virtualization environment provided by both embodiments is sufficient for execution, the two embodiments should be considered interchangeable herein, and are referenced by the term Virtualized Container (VC). In accordance with one or more embodiments of the present application, the VNFCIs 626 and 628 execute in VC 606.”;
Claims 9, 10, 11, 13, 14 are the system claim corresponding to method claims 1, 2, 3, 5, 6 and rejected under the same rational set forth in connection with the rejection of claims 1, 2, 3, 5, 6, above.
Claims 17, 18, 19, 22, 23 are the computer storage medium claim corresponding to method claims 1, 2, 3, 5, 6 and rejected under the same rational set forth in connection with the rejection of claims 1, 2, 3, 5, 6 above.
Pertinent arts:
US 20190036869A1:
In the integrated cloud environment, the dynamic cloud capabilities are applied to applications-i.e., virtual network functions (VNFs)—thus applying the benefits of the cloud environment to virtual network elements.
US20210392056A1:
Resource requirements and configurations for VNFs and Networks are determined based on the network service model, VNF packages involved (IMS and DPI) and any related Policies (e.g., scaling and billing), and an optimized plan is generated for subsequent interactions.
Conclusion
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.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRAHIM BOURZIK whose telephone number is (571)270-7155. The examiner can normally be reached Monday-Friday (8-4:30).
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, Wei Zhen can be reached at 571-270-2738. 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.
/BRAHIM BOURZIK/ Examiner, Art Unit 2191
/WEI Y MUI/ Supervisory Patent Examiner, Art Unit 2191