DETAILED ACTION
This action is responsive to Pre-Appeal Brief Conference Request filed on May 27, 2026.
Claims 1-10 and 12-20 are pending and are presented to examination. Claim 11 has been previously canceled.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Response to Arguments
Applicant’s arguments set forth in the Pre-Appeal Brief Request for Review (Reasons for Review) have been fully considered but are not persuasive. Applicant traverses the rejections under 35 U.S.C. 103 on three grounds, each of which is addressed in turn below.
First, Applicant argues that paragraph [0076] of Tejaprakash, relied upon at page 11 of the prior Office Action (Final Action dated 03/04/2026), discloses only test modeling, test management, and test reporting and is “silent as to generating a template that comprises parameters to use when executing the test”, with no disclosure of “parameters to be used when executing the test, let alone having those parameters comprise a job template” (Pre-Appeal Brief Request for Review, Reasons for Review). This argument is not persuasive because the present rejection does not rely upon paragraph [0076] for the job-template limitation; that reliance has been withdrawn. As set forth in the rejection of claim 1 below, Tejaprakash teaches generating, via the application and based on a user input, a job template comprising parameters to use when executing the test by “configur[ing] a Jenkins based automation server” and generating a “testing workflow to organize a set of tests” ([0055]); the “configuration for tests” defines the parameters used to run the tests ([0013], [0041]); the generation is performed based on user-selected test cases received via the configurable interface ([0047], [0089]); and the test is thereafter “execute[d]… in an order based on a configured workflow” ([0058]). Under the broadest reasonable interpretation, a “job template comprising parameters to use when executing the test” is a preconfigured, reusable specification that organizes the parameters—e.g., the set and order of tests and their configuration—used to run the test; Tejaprakash’s generation of a configured testing workflow that organizes the set of tests and governs the order of test execution is such a job template, and the test is executed based on that configured workflow. Tejaprakash is therefore not silent as to this limitation.
Second, Applicant argues that the prior Response to Arguments (pages 5-6 of the prior Office Action) improperly equated the VNF Configuration 512 of FIG. 5 of Tejaprakash with the claimed job template, and that VNF onboarding and configuration 512—described as “adding a VNF into a test platform, configuring the VNF, etc.”—is “entirely separate” from the management and operation of tests. This argument is moot and, in any event, not persuasive. The present rejection does not rely upon VNF Configuration 512, or upon paragraph [0076], for the job-template limitation; that mapping has been withdrawn and replaced as set forth below. The present rejection is instead anchored to Tejaprakash’s disclosure of the management and operation of tests—namely, configuring a Jenkins-based automation server and generating a testing workflow that organizes the set of tests ([0055]) and executing the testing in an order based on the configured workflow ([0058]). Applicant’s own characterization concedes that Tejaprakash discloses “managing a test” and mapping requirements to test cases; the present mapping is directed precisely to that test-management and test-execution functionality, not to VNF onboarding. Applicant’s contention that VNF configuration is separate from test operation therefore does not reach—and indeed is consistent with—the present mapping, which relies on the test-operation functionality Applicant acknowledges Tejaprakash discloses.
Third, Applicant argues that the additional references (Hermoni, Lee, Shaikh, Prasad, Sidebottom, Zemlerub, Yeung, Jebbar, and Htay) fail to remedy the asserted deficiencies of Tejaprakash because none discloses the job-template limitation. This argument is premised on a deficiency in Tejaprakash that does not exist. As set forth below, Tejaprakash itself teaches the job-template limitation; the additional references are not relied upon to teach that limitation and need not remedy any deficiency with respect to it. Each additional reference is relied upon only for the specific further subject matter of its respective claim—Hermoni for downloading the image ([0110], [0146], [0151]), Lee for instantiating the service ([0026], [0029]-[0030]), Shaikh for the type of edge gateway device ([0044], [0036]), Prasad for the single-router service ([0030]-[0031]), Zemlerub for the HTTP test (column 15 lines 10-26), Yeung for the Netconf test ([0038]-[0039]), Jebbar for the Ansible test ([0091], [0005], [0051]), and Htay for presenting the recited image details ([0030], [0032]-[0035])—each combined with Tejaprakash for the articulated reasons set forth in the corresponding ground below. Because Tejaprakash is not deficient as to the job-template limitation, Applicant’s argument that the additional references fail to cure that limitation is not persuasive. With respect to claims 5 and 16, the present action further withdraws the prior ground based on Sidebottom and rejects those claims over Tejaprakash in view of Hermoni, in view of Lee, and further in view of Wang (US Pub. No. 2021/0224092), as set forth below.
For the foregoing reasons, the rejections under 35 U.S.C. 103 are maintained as reformulated and strengthened below, and Applicant’s request for withdrawal of the rejections is not persuasive.
Claim Objections
Claims 16-19 are objected to because of the following informalities: Claims 16-19 recites “wherein [[to execute]] executing the test is based on…”. The counterpart claims 5-8 use “wherein executing the test is based on”. For claim formalism replace “to execute” to –executing-- as indicated in bold. Appropriate correction is required.
Claim Rejections - 35 USC § 112
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 (and similar for claims 12 and 20) recites the limitation “generating, via the application, based on a fourth user input, a job template comprising parameters to use when executing the test;” in lines 15-16. There is insufficient antecedent basis for this limitation in the claim. For purpose of examination, “the test” will be interpreted as “a test”.
Claim 1 (and similar for claims 12 and 20) recites the limitation “executing, by the at least one processor, via the application, a test of the VNF with the edge gateway device using the image and the service based on the third user input, wherein executing the test is based on the job template.” in lines 17-19. It is unclear, whether “a test” is a new test different to the one mentioned in the previous limitation. In addition, the limitation does mention to “the test”, it’s unclear whether is related to the first test introduced in the “generating” step or in the test introduces in the “executing” step. For examination purpose, all of them will be interpreted as the same test. Clams 5-9 and16-19 have the same issue as above. It is unclear what test is referring to, the one in the “generating” step or the one in the “executing” step.
Claim 2 recites “a fourth user input” indicative of a checksum associated with verifying the image. However, claim 1, from which claim 2 depends, already recites “a fourth user input”, namely the user input on which the generation of the job template is based. It is therefore unclear whether the “fourth user input” of claim 2 is the same as, or different from, the “fourth user input” of claim 1. Because the ordinal designation “fourth” identifies a single, particular user input, the recitation of two different user inputs each designated as the “fourth” user input renders the claim indefinite, as one of ordinary skill in the art cannot ascertain whether the claim requires a single fourth user input performing both functions or two distinct user inputs. Appropriate correction is required.
Claim 3 recites “a fourth user input” indicative of a type of the edge gateway device, while claim 1, from which claim 3 depends, already recites “a fourth user input” on which the generation of the job template is based; claim 3 is therefore indefinite for the same reasons set forth above with respect to claim 2.
Claim 9 recites “a fourth user input” to authorize the image, while claim 1, from which claim 9 depends, already recites “a fourth user input” on which the generation of the job template is based; claim 9 is therefore indefinite for the same reasons set forth above with respect to claim 2.
Claim 13 recites “a fourth user input” indicative of a checksum associated with verifying the image, while claim 12, from which claim 13 depends, already recites “a fourth user input” on which the generation of the job template is based; claim 13 is therefore indefinite for the same reasons set forth above with respect to claim 2.
Claim 14 recites “a fourth user input” indicative of a type of the edge gateway device, while claim 12, from which claim 14 depends, already recites “a fourth user input” on which the generation of the job template is based; claim 14 is therefore indefinite for the same reasons set forth above with respect to claim 2.
Dependent claims 4, 10 and 15 do not overcome the deficiency of the base claim and, therefore, are rejected for the same reasons as the base claim.
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.
Claims 1-2, 9, 12-13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Tejaprakash et al. (US Pub. No. 2019/0104047, hereinafter Tejaprakash – previously presented) in view of Hermoni et al. (US Pub. No. 2018/0337931, hereinafter Hermoni – previously presented) and further in view of Lee et al. (US Pub. No. 2020/0344144, hereinafter Lee – previously presented).
With respect to claim 1 (Previously Presented), Tejaprakash teaches a method for remotely testing virtual network functions with edge gateway devices, the method comprising:
Examiner note: the recited first, second, third and fourth user inputs are interpreted under the broadest reasonable interpretation as user inputs received via the user interface of the application, which may be provided by one or more users interacting with the application.
providing, by at least one processor, an application associated with receiving user inputs for testing a virtual network function (VNF) with an edge gateway device remote from the VNF (Tejaprakash paragraph [0010], “the network operator can deploy a virtual network function (VNF) to perform a firewalling functionality, a routing functionality, a wide area networking (WAN) functionality, and/or the like”; Tejaprakash paragraph [0013], “test control device 115 can initially receive a test package… [and] can onboard the test package (e.g., by providing a VNF onboarding portal for VNF developers and receiving a test package submission via the onboarding portal)”; Tejaprakash paragraphs [0020] and [0024]-[0025], “[c]loud computing environment 230… delivers computing as a service, whereby shared resources, services, etc. can be provided to test a VNF… [and] a set of virtual machines 225-2 can be deployed as a set of network devices with a configured topology to test a VNF”; Tejaprakash paragraph [0029], “[n]etwork device 250 includes physical and/or virtualized instances of one or more devices… [such as] a router, a gateway… [and] can include a virtualized device implemented by computing resource 225 in a test bed to provide a testing environment for a VNF”; Tejaprakash paragraph [0089], describing the user interface through which a user provides input. Tejaprakash thus provides an application—the test control device having a VNF onboarding portal and a user interface—that receives user inputs for testing a VNF against a network device that includes a gateway, where that gateway/network device is provided in the cloud-based test bed remote from the VNF under test, thereby teaching providing an application for testing a VNF with an edge gateway device remote from the VNF).
receiving, by the at least one processor, via the application, a first user input associated with adding an image of a virtual machine instance to the application (Tejaprakash abstract, “[a] device can receive a test package for testing. The test package can include at least one virtual network function (VNF) for testing”; Tejaprakash paragraphs [0024]-[0025], “[v]irtual machine 225-2 includes a software implementation of a machine… [and] a set of virtual machines 225-2 can be deployed as a set of network devices… to test a VNF”; Tejaprakash paragraph [0089], user interface receiving user input. Tejaprakash thus receives, via the user interface of the application, a user input that adds/submits the virtual-machine image (the test package including the VNF) to the application).
receiving, by the at least one processor, via the application, a third user input associated with testing the VNF with the edge gateway device using the image and the service (Tejaprakash paragraph [0014], “test control device 115 can execute the test package… using test bed 120 (e.g., a sandbox of network devices 125-1 to 125-K…)”; Tejaprakash paragraph [0029], identifying the gateway as a network device in the test bed; Tejaprakash paragraph [0047], “test control device 220 can receive user selected test cases”; Tejaprakash paragraph [0089], user input. Tejaprakash thus receives a user input to test the VNF against the network device (gateway) using the image (test package) and the associated service in the test bed).
generating, via the application, based on a fourth user input, a job template comprising parameters to use when executing the test (Tejaprakash paragraphs [0013] and [0041], “the test package can include… selection of tests, configuration for tests, and/or the like”; Tejaprakash paragraph [0047], “test control device 220 can receive user selected test cases, and can automatically identify test cases based on a test package…”; Tejaprakash paragraph [0055], “test control device 220 can configure an automation server to automate a set of test cases. For example, test control device 220 can configure a Jenkins based automation server… [and] can generate a testing workflow to organize a set of tests into an ordering for the set of tests (e.g., based on resource utilization, criticality, time, etc.)”; Tejaprakash paragraph [0089], describing a configurable user interface through which a user provides input. Under the broadest reasonable interpretation, a “job template comprising parameters to use when executing the test” is a preconfigured/reusable specification that organizes and holds the parameters used to run the test. Tejaprakash generates precisely such a specification: the test control device generates a testing workflow and configures a Jenkins-based automation server that organizes the set of tests into an ordering ([0055]), where that workflow/configuration contains the “configuration for tests” ([0013],[0041])—i.e., the parameters to use when executing the test—and where the generation is performed based on a user input, namely user-selected test cases ([0047]) provided via the configurable user interface ([0089]). The generated testing workflow/Jenkins job is the claimed job template, and the included configuration-for-tests/ordering values are the claimed parameters to use when executing the test).
executing, by the at least one processor, via the application, a test of the VNF with the edge gateway device using the image and the service based on the third user input, wherein executing the test is based on the job template (Tejaprakash paragraph [0014], “test control device 115 can execute the test package… using test bed 120”; Tejaprakash paragraph [0057], “test control device 220 can execute testing for the test package based on configuring testing for the test package”; Tejaprakash paragraph [0058], “test control device 220 can execute testing in an order based on a configured workflow, in a user selected order”. Tejaprakash thus executes the test against the VNF with the network device (gateway) using the image and service, where the execution is performed “based on a configured workflow” and “based on configuring testing”—that is, executing the test is based on the generated testing workflow/job (the job template), directly satisfying the limitation “wherein executing the test is based on the job template”).
Tejaprakash is silent to disclose, however in an analogous art, Hermoni teaches: downloading, by the at least one processor, via the application, the image based on the first user input (Hermoni paragraph [0110], “a VNF package contains a VNF Descriptor file…, the software image, test scripts, policies, monitoring information and more”; Hermoni paragraphs [0146], [0151], “a test can be executed. This may start by downloading the VNF package from the marketplace, so it can be logged in the blockchain and can be verified at later stage”. Hermoni thus downloads the VNF package, which contains the software image, thereby teaching downloading the image based on the user request/input). It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to modify the VNF-testing platform of Tejaprakash, which receives a test package including a VNF/image for testing, to download the image based on the first user input as taught by Hermoni. Tejaprakash already obtains the VNF/image as a test package submitted through its onboarding portal ([0013], [0042]), and Hermoni provides a concrete, predictable mechanism for retrieving that image—downloading the VNF package (which contains the software image) from a marketplace—together with integrity verification so the downloaded image is logged and can be verified before testing ([0146], [0151]). One of ordinary skill would have been motivated to incorporate Hermoni’s download because it yields the predictable benefit of obtaining a verified, tamper-free image on demand for Tejaprakash’s automated testing, improving the reliability and integrity of the artifact under test, with a reasonable expectation of success because both references operate on the same NFV VNF-package artifacts in the same field of automated VNF testing. Tejaprakash in view of Hermoni is silent to disclose, however in an analogous art, Lee teaches: receiving, by the at least one processor, via the application, a second user input associated with instantiating a service associated with the virtual machine instance; instantiating, by the at least one processor, via the application, the service based on the second user input (Lee paragraph [0026], “one or more of the components… are created manually and/or based on user input following instantiation of the commissioning VM 110”; Lee paragraphs [0029]-[0030], “the VIM component 140 is capable of instantiating VMs in the virtualized environment 100… [and] the commissioning VM 110 is configured to instruct the VIM component 140 to instantiate first VMs… that are operable to perform a first VNF”. Lee thus receives user input and, based on that input, instantiates the VMs/components that perform the service (VNF) in the virtualized environment). It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to modify the combination of Tejaprakash and Hermoni to receive a second user input associated with instantiating a service associated with the virtual machine instance and to instantiate the service based on that input as taught by Lee. Tejaprakash imports and instantiates the VNF/test package in a test bed for testing ([0046]), and Lee supplies a specific, user-driven mechanism for instantiating, in a virtualized environment, the VMs/components that perform the service based on user input ([0026], [0029]-[0030]). One of ordinary skill would have been motivated to combine these teachings so that the user of Tejaprakash’s application can set up (instantiate) the particular service associated with the uploaded image prior to testing, yielding the predictable benefit of a properly commissioned service in the virtualized test environment and reducing manual configuration errors (Lee, [0008]), with a reasonable expectation of success because Lee operates in the same virtualized-VNF testing and commissioning environment addressed by Tejaprakash. With respect to claim 2 (Original), Tejaprakash in view of Lee is silent to disclose, however in an analogous art, Hermoni teaches further comprising: receiving, via the application, a fourth user input indicative of a checksum associated with verifying the image; and verifying the image, via the application, using the checksum, wherein the checksum is unique to the image (Hermoni paragraph [0023], “[t]he system computes a unique identifier (e.g., a checksum, a hash, a signature, etc.) of the VNF package… that allows verification of an integrity of the VNF package”; Hermoni paragraph [0106], “a checksum or hash of the data can be calculated and compared to the value stored in the repository. If the calculated and the stored values are identical, then no unauthorized changes have been made”; Hermoni paragraph [0109], verifying integrity by polling with the VNF’s hash or checksum. Hermoni computes a checksum that is unique to the VNF package/image and verifies the image’s integrity using that checksum).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to modify the combination of Tejaprakash and Lee to receive a fourth user input indicative of a checksum and to verify the image using that unique checksum as taught by Hermoni. The combination already obtains and tests a VNF/image, and Hermoni teaches computing a checksum/hash unique to the VNF package and comparing it to a stored value to confirm that no unauthorized changes have been made before the image is used ([0023], [0106], [0109]). One of ordinary skill would have been motivated to add Hermoni’s checksum verification to ensure that the image added and tested in Tejaprakash’s platform is authentic and unmodified, yielding the predictable benefit of detecting tampering or corruption prior to testing and deployment, with a reasonable expectation of success given that both references handle the same VNF-package artifacts.
With respect to claim 9 (Original), Tejaprakash teaches further comprising: receiving, via the application, a fourth user input to authorize the image, wherein authorizing the image is indicative of the image being tested and approved based on executing the test (Tejaprakash paragraph [0068], “test control device 220 can certify a test package as satisfying one or more testing criteria… [and] 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”; Tejaprakash paragraph [0082], describing a package certification step, a package acceptance step and a VNF deployment step; Tejaprakash paragraph [0085], “test control device 220 can automatically test, certify, and deploy VNFs”. Tejaprakash thus certifies/accepts (authorizes) the image upon the image being tested and satisfying the testing criteria, i.e., the image being tested and approved based on executing the test).
With respect to claims 12-13, the claims recite limitations similar to those of claims 1-2, respectively, and are rejected for the same reasons set forth above (wherein Tejaprakash also teaches such a system in figures 1-3).
With respect to claim 20, the claim recites limitations similar to those of claim 1 and is rejected for the same reasons set forth above (wherein Tejaprakash also teaches such a non-transitory computer-readable storage medium in paragraph [0037] and figure 3).
Claims 3 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Tejaprakash et al. (US Pub. No. 2019/0104047) in view of Hermoni et al. (US Pub. No. 2018/0337931) in view of Lee et al. (US Pub. No. 2020/0344144) and further in view of Shaikh et al. (US Pub. No. 2022/0350632, hereinafter Shaikh – previously presented). With respect to claim 3 (Original), Tejaprakash in view of Hermoni in view of Lee is silent to disclose, however in an analogous art, Shaikh teaches further comprising: receiving, via the application, a fourth user input indicative of a type of the edge gateway device, wherein the image is based on the type of the edge gateway device (Shaikh paragraph [0044], “[h]osts 262c include hosts installed in a particular edge data center and also hosts that are mounted on radio towers 104…”; Shaikh paragraph [0036], “VNFD is a file that describes the properties of the VNF, including resources needed (e.g., amount and type of virtual compute, storage, and network resources)… [and] [t]he… EMS… is… executed to manage the configuration of a VNF after a virtual machine for the VNF has been instantiated. The virtual machine communicates with the EMS to receive initial configuration parameters”. Shaikh discloses different types of edge hosts (edge gateway devices)—those installed at the edge data center and those mounted on radio towers—and a VNFD/EMS that specifies the type of resources and configures the VNF/image according to that host type, such that the deployed image is based on the type of the edge host). It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to modify the combination of Tejaprakash, Hermoni and Lee so that a user input indicates a type of the edge gateway device and the image is based on that type, as taught by Shaikh. Shaikh deploys VNFs across heterogeneous edge hosts of differing types and configures each VNF/image according to the type of host through the VNFD/EMS configuration parameters ([0036]/[0044]). One of ordinary skill would have been motivated to select and configure the image based on the type of edge gateway device so that the tested image matches the resources and capabilities of the specific edge host on which it will run, yielding the predictable benefit of correct and resource-appropriate deployment across different edge hardware, with a reasonable expectation of success because Shaikh operates in the same NFV VNF-deployment field. With respect to claim 14, the claim recites limitations similar to those of claim 3 and is rejected for the same reasons set forth above.
Claims 4 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Tejaprakash et al. (US Pub. No. 2019/0104047) in view of Hermoni et al. (US Pub. No. 2018/0337931) in view of Lee et al. (US Pub. No. 2020/0344144) and further in view of Prasad et al. (US Pub. No. 2020/0267072, hereinafter Prasad – previously presented).
With respect to claim 4 (Original), Tejaprakash in view of Hermoni in view of Lee is silent to disclose, however in an analogous art, Prasad teaches wherein the service comprises at least one of the following: a single router[[, a router and any of a firewall, a session border controller, a monitor, or an information technology payload, or multiple standalone information technology payloads]] (Prasad paragraphs [0030]-[0031], “the development platform may configure VNF to be deployed as a virtual router in a network and may create a VNF descriptor for the virtual router. The development platform may deploy the virtual router… and may utilize testing tools to validate the virtual router and functionality of the virtual router based on a pre-validation test of the virtual router and a conformance test of the virtual router”. Claim 4 recites a “at least one of the following” alternative listing, and only one alternative need be taught. Prasad teaches the service comprising a single (virtual) router and validating/testing that router VNF, thereby satisfying the “single router” alternative; the remaining bracketed alternatives are not required to be taught given the “at least one of” language). It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to modify the combination of Tejaprakash, Hermoni and Lee wherein the service comprises a single router as taught by Prasad. Prasad configures and tests a VNF deployed as a virtual router, using testing tools to validate the router’s functionality through pre-validation and conformance testing ([0030]-[0031]). One of ordinary skill would have been motivated to apply the testing platform of the combination to a router VNF/service as in Prasad because a router is a fundamental network function that is commonly virtualized and tested, yielding the predictable benefit of validating router functionality before deployment, with a reasonable expectation of success because Prasad operates in the same field of deploying and testing VNFs in a software-defined network.
With respect to claim 15, the claim recites limitations similar to those of claim 4 and is rejected for the same reasons set forth above.
Claims 5 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Tejaprakash et al. (US Pub. No. 2019/0104047) in view of Hermoni et al. (US Pub. No. 2018/0337931) in view of Lee et al. (US Pub. No. 2020/0344144) and further in view of Wang et al. (US Pub. No. 2021/0224092, hereinafter Wang). With respect to claim 5 (Original), Tejaprakash in view of Hermoni in view of Lee is silent to disclose, however in an analogous art, Wang teaches further comprising: identifying, via the application, a uniform resource locator associated with viewing a console of the VNF, wherein executing the test is based on the uniform resource locator (Wang [0009], “VM management web client 104 also enables IT administrator to remotely access VM consoles of VMs 172 through a VM remote console (VMRC) 126”; Wang [0014], “[w]hen the IT administrator clicks on a hyperlink in VM management web client 104 for opening a console of the target VM remotely, browser 103 is asked to open a URL (uniform resource locator)… [and] VMRC 126… perform[s] several steps… before presenting the VM console to the IT administrator”; Wang [0003], “transmitting a uniform resource locator (URL) identifying the proxy server and the second ticket to the remote computing device. The remote computing device accesses the console of the VM through the URL”; Wang [0029], “using the opened VM console, to perform various tasks in the VM, such as installing or patching an operating system, configuring the operating system settings, running applications, monitoring performance”. Wang identifies a uniform resource locator (URL) through which the console of the virtual machine—on which the VNF runs—is accessed, viewed and presented to the user, and through which the user exercises and observes the VM/VNF (e.g., running applications and monitoring performance). Under the broadest reasonable interpretation, the URL through which the VM/VNF console is viewed is a uniform resource locator associated with viewing a console of the VNF, and the test—which exercises and observes the VNF—is executed based on that uniform resource locator). It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to modify the combination of Tejaprakash, Hermoni and Lee to identify a uniform resource locator associated with viewing a console of the VNF and to base test execution on that uniform resource locator, as taught by Wang. Wang provides a URL through which a remote user securely accesses and views the console of a VM running in a cloud environment in order to perform and observe tasks on that VM ([0003], [0009], [0014], [0029]). One of ordinary skill would have been motivated to provide such a console URL in the testing application of the combination so that the user can remotely view and interact with the VNF’s console during testing and base the test on that URL, yielding the predictable benefit of remote, browser-based observation and exercise of the VNF under test without requiring tedious and error-prone VPN setup, with a reasonable expectation of success because Wang operates in the same field of remotely accessing virtual machines (on which VNFs run) in a cloud computing environment. With respect to claim 16, the claim recites limitations similar to those of claim 5 and is rejected for the same reasons set forth above.
Claims 6 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Tejaprakash et al. (US Pub. No. 2019/0104047) in view of Hermoni et al. (US Pub. No. 2018/0337931) in view of Lee et al. (US Pub. No. 2020/0344144) and further in view of Zemlerub (US Pat. No. 9,912,573, hereinafter Zemlerub – previously presented). With respect to claim 6 (Original), Tejaprakash in view of Hermoni in view of Lee is silent to disclose, however in an analogous art, Zemlerub teaches wherein the test is a hypertext transfer protocol (HTTP) test associated with a request port and a uniform resource locator, wherein executing the test is based on the uniform resource locator and the request port (Zemlerub at column 15 lines 10-19, “[t]he testing software 602 may choose network connection parameters for the testing session, for example, IP 1.1.1.1 port 4578 to IP 2.2.2.2 port 80”; Zemlerub at column 15 lines 20-26, “[t]he testing software 602 may create a TCP connection according to chosen parameters and send an HTTP request via interface 2”. Zemlerub performs a test in which the testing software selects connection parameters including request ports (e.g., port 4578 and port 80) and a destination endpoint (e.g., IP 2.2.2.2 port 80) to which it sends an HTTP request; under the broadest reasonable interpretation, the destination endpoint to which the HTTP request is directed is a uniform resource locator, and the test—creating the TCP connection and sending the HTTP request—is executed based on that destination locator and the request port). It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to modify the combination of Tejaprakash, Hermoni and Lee wherein the test is an HTTP test associated with a request port and a uniform resource locator and executing the test is based on the uniform resource locator and the request port, as taught by Zemlerub. Zemlerub tests a network service by selecting connection parameters (destination address/locator and request ports) and sending an HTTP request accordingly (column 15 lines 10-26). One of ordinary skill would have been motivated to use Zemlerub’s HTTP-based test with the specified port and locator to actively exercise the VNF/service over a real protocol, yielding the predictable benefit of verifying that the service correctly handles HTTP traffic to a specified destination and port, with a reasonable expectation of success because Zemlerub tests virtual network services in the same NFV field. With respect to claim 17, the claim recites limitations similar to those of claim 6 and is rejected for the same reasons set forth above.
Claims 7 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Tejaprakash et al. (US Pub. No. 2019/0104047) in view of Hermoni et al. (US Pub. No. 2018/0337931) in view of Lee et al. (US Pub. No. 2020/0344144) and further in view of Yeung et al. (US Pub. No. 2019/0028350, hereinafter Yeung – previously presented). With respect to claim 7 (Original), Tejaprakash in view of Hermoni in view of Lee is silent to disclose, however in an analogous art, Yeung teaches wherein the test is a Netconf test using a Netconf template, wherein executing the test is based on the Netconf template (Yeung paragraph [0038], “VNF manager 200 includes various interfaces… including NETCONF/YANG application programming interface (API) 202”; Yeung paragraph [0039], “NETCONF is a network management protocol to install, manipulate, operate, and delete the configuration of network devices. In some cases, an orchestrator… can communicate with VNF manager 200 using open NETCONF protocol and YANG based data models”; Yeung paragraph [0031], “ensuring that orchestrator 152 can access templates required by the network service, including VNF templates stored in VNF catalog 160 and NFVI templates”; Yeung paragraph [0033], “VNF catalog 160 can store… VNF deployment templates (sometimes referred to as VNF Descriptors (VNFD)), software images, manifest files”. Yeung manages and operates the VNF using the NETCONF protocol via a NETCONF/YANG API ([0038]-[0039]) and uses templates required by the VNF—VNF templates and VNF deployment templates ([0031], [0033]); the VNF operations/tests are therefore NETCONF-based and use a NETCONF template, and executing those operations is based on the template). It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to modify the combination of Tejaprakash, Hermoni and Lee wherein the test is a Netconf test using a Netconf template and executing the test is based on the Netconf template, as taught by Yeung. Yeung manages VNFs over the standardized NETCONF protocol and relies on stored VNF/deployment templates to configure and operate the VNFs ([0038]-[0039], [0031], [0033]). One of ordinary skill would have been motivated to perform the VNF test using NETCONF and a NETCONF template because NETCONF is a standardized network-management protocol that provides a uniform, machine-processable way to install, manipulate, and operate VNF configurations, yielding the predictable benefit of reliable, standards-based configuration and testing of the VNF, with a reasonable expectation of success because Yeung operates in the same NFV lifecycle-management field. With respect to claim 18, the claim recites limitations similar to those of claim 7 and is rejected for the same reasons set forth above.
Claims 8 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Tejaprakash et al. (US Pub. No. 2019/0104047) in view of Hermoni et al. (US Pub. No. 2018/0337931) in view of Lee et al. (US Pub. No. 2020/0344144) and further in view of Jebbar et al. (US Pub. No. 2023/0082606, hereinafter Jebbar – previously presented). With respect to claim 8 (Original), Tejaprakash in view of Hermoni in view of Lee is silent to disclose, however in an analogous art, Jebbar teaches wherein the test is an Ansible test using an Ansible playbook, wherein executing the test is based on the Ansible playbook (Jebbar paragraph [0091], “[t]est configurations may be specified in various languages such as ansible playbook language, puppet DSL, chef DSL, etc.; as a result, one may use this feature… to specify test configurations as constraints expressed in languages that deployment management engines can process”; Jebbar paragraph [0005], “a platform independent Test Planner for generating a test package… and a platform dependent Test Execution Framework (TEF) for executing the test package”; Jebbar paragraph [0051], “[a] test package 103 consists of a test suite 107 and a test plan 108… [where] each TSI is an application of one or more test suite items under a given test configuration”. Jebbar specifies the test configurations in ansible playbook language ([0091]) and executes the test package containing those test configurations via the Test Execution Framework ([0005], [0051]); the test therefore uses an Ansible playbook (the ansible-playbook-language test configuration) and executing the test is based on that Ansible playbook).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to modify the combination of Tejaprakash, Hermoni and Lee wherein the test is an Ansible test using an Ansible playbook and executing the test is based on the Ansible playbook, as taught by Jebbar. Jebbar specifies test configurations in ansible playbook language and executes the resulting test package on the system under test ([0091], [0005], [0051]). One of ordinary skill would have been motivated to express and run the VNF test as an Ansible playbook because Ansible playbooks provide a widely used, deployment-management-engine-processable way to specify and automate test configurations across heterogeneous platforms, yielding the predictable benefit of automated, repeatable test configuration and execution, with a reasonable expectation of success because Jebbar addresses automated testing in the same NFV/cloud field. With respect to claim 19, the claim recites limitations similar to those of claim 8 and is rejected for the same reasons set forth above.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Tejaprakash et al. (US Pub. No. 2019/0104047) in view of Hermoni et al. (US Pub. No. 2018/0337931) in view of Lee et al. (US Pub. No. 2020/0344144) in view of Shaikh et al. (US Pub. No. 2022/0350632) and further in view of Htay (US Pub. No. 2017/0244606, hereinafter Htay – previously presented). With respect to claim 10 (Original), Tejaprakash teaches presenting, via the application, details associated with [[the image, the details comprising a download location, a download start time, a download end time,]] an authorization state [[, a host type of the edge gateway device, and a checksum associated with verifying the image]] (Tejaprakash [0068], “the test control device can certify a test package as satisfying one or more testing criteria” and may “accept” the test package; the certified/accepted status being an authorization state of the image indicating that the image has been tested and approved).
Tejaprakash in view of Hermoni in view of Lee in view of Htay is silent to disclose, however in an analogous art, Shaikh teaches a host type of the edge gateway device of the recited details (Shaikh [0044], “[h]osts… include hosts installed in a particular edge data center and also hosts that are mounted on radio towers”, Shaikh [0036], a VNFD describing the “type” of resources; the type of the recited edge host being a host type of the edge gateway device). It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to modify the combination of Tejaprakash, Hermoni, Lee and Htay to include, among the presented details, a host type of the edge gateway device as taught by Shaikh. Shaikh characterizes edge hosts by type ([0036],[0044]). One of ordinary skill would have been motivated to present the host type so that the user can identify the type of edge host associated with the image, yielding the predictable benefit of resource-appropriate identification and management of the image across different edge hardware, with a reasonable expectation of success because Shaikh operates in the same NFV virtual-network-function deployment field.
Tejaprakash in view of Hermoni in view of Lee in view of Shaikh is silent to disclose, however in an analogous art, Htay teaches presenting, via the application, details associated with the image, the details comprising a download location, a download start time, a download end time and a checksum associated with verifying the image (Htay [0030], “[t]his is done through manifest files and associated data… A manifest file… is a file containing metadata for a group of accompanying files… [such as a] manifest describing the name, version number, and the constituting files of the program”; Htay [0035], [0004], the image being uniquely identified and tracked between “source and destination locations in the network” and “identifiable over the network based on one of a manifest file and a hash signature” (the download location), and “[t]he unique tracking can be through a manifest file, cryptographic hash functions (e.g., Secure Hash Algorithm (SHA))… can uniquely identify data over the network” (the checksum associated with verifying the image); Htay [0032]-[0033], “the image has to be first downloaded by a container daemon process… When all the layers are downloaded, they are extracted locally and ready to be run… A software image can only be run when all the layers are fully downloaded and extracted” (the download start time and the download end time, i.e., the times at which the monitored download of the image begins and at which the image is fully downloaded). Htay presents, via a manifest file, details associated with the image, the presented details comprising the download location, the download start time and the download end time of the monitored image download, and the checksum associated with verifying the image).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to modify the combination of Tejaprakash, Hermoni, Lee and Shaikh to present, via the application, details associated with the image—including the download location, the download start time, the download end time, and the checksum associated with verifying the image—as taught by Htay. Htay presents image-download details through an extensible manifest file and monitors each image download from initiation through full completion ([0030], [0032]-[0035]). One of ordinary skill would have been motivated to present such image details to the user of the testing application so that the user can monitor and verify the image download and its integrity, yielding the predictable benefit of transparency and traceability of the image used for testing, with a reasonable expectation of success because Htay manages the distribution and identification of uniquely identifiable images in the same SDN/NFV field.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Asawa et al. (US Pub. No. 2022/0201447) Systems and methods are disclosed that seamlessly integrates orchestration and CI/CD without requiring duplication of any of the tasks. This method allows creation of test slices as well as operator specific policy control and implementation to implement dynamic test and deployment options that allows different containerized network functions (CNFs) versions to be used for different slices. (see abstract).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANIBAL RIVERACRUZ whose telephone number is (571)270-1200. The examiner can normally be reached Monday-Friday 9:30 AM-6:00 PM.
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, Hyung S Sough can be reached at 5712726799. 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.
/ANIBAL RIVERACRUZ/Primary Examiner, Art Unit 2192
Prosecution Insights