DETAILED ACTION
This action is responsive to Remarks and Claim amendments filed on February 05, 2026.
Claims 1, 12 and 20 have been amended. Claim 11 has been canceled.
Claims 1-10 and 12-20 are pending and are presented to examination.
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 Amendments
The objection of the specification (Abstract of the Disclosure) is withdrawn in view of applicant’s amendments.
The objection of claim 11 is withdrawn in view of applicant’s amendments.
The rejection of claim 20 under 35 U.S.C. 101 is withdrawn in view of applicant’s amendments.
Response to Arguments
Rejection under 35 U.S.C. § 103
As an initial matter, the Examiner would like to point out that the claims are interpreted in light of the specification; however, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). It is improper to import to claim limitations from the specification “Though understanding the claim language may be aided by explanations contained in the written description, it is important not to import into a claim limitation that are not part of the claim. For example, a particular embodiment appearing in the written description may not be read into a claim when the claim language is broader than the embodiment.’ Superguide Corp. v. DirecTV Enterprises, Inc., 358 F.3d 870, 875, 69 USPQ2d 1865, 1868 (Fed. Cir. 2004).” Argument: Applicant asserted “Independent claim 1 of the present application, from which claims 2-10 depend, recites, inter alia, a method for remotely testing virtual network functions with edge gateway devices that includes ‘generating, via the application, based on a fourth user input, a job template comprising parameters to use when executing the test’ and ‘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’ where ‘executing the test is based on the job template’ (emphasis added). Independent claim 12, from which claims 13-19 depend, and independent claim 20 include similar recitations written in different formats. For the reasons discussed below, the Applicant respectfully submits that the cited references fail to disclose or suggest these recitations.
At page 14 of the Office Action, the Office alleges that Tejaprakash discloses the claimed generation and execution, referring specifically to paragraph [0076] thereof and its disclosure of test modeling. Paragraph [0076] of Tejaprakash discloses the use of test modeling, test management, and test reporting, which provide example use cases, test storage, test status determination, reporting test results, and mapping requirements to test cases. However, the cited portion of Tejaprakash is silent as to generating a template that comprises parameters to use when executing the test, as recited in the present claims. There is no disclosure or suggestion in the cited portion of Tejaprakash of anything that could be considered parameters to be used when executing the test, let alone having those parameters comprise a job template that is used when executing the test, as recited in the present claims. Thus, for at least this reason, Tejaprakash fails to disclose or suggest the above recitations.” (Remarks pages 12-13). Response: Examiner respectfully disagrees with the applicant. First it is acknowledged that dependent claim 11 has been canceled and it was fully incorporated in all independent claims 1, 12 and 20. The amended and argued limitation of claim 1 recites “generating, via the application, based on a fourth user input, a job template comprising parameters to use when executing the test:” and “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.”. Dependent claim 11 (now part of independent claim 1) was rejected under 35 U.S.C. 103 as being unpatentable over Tejaprakh (prior art of record). The rejection stated: “generating, via the application, based on a fourth user request, a job template comprising parameters to use when executing the test, wherein executing the test is based on the job template (see figure 5 (and related text) and paragraph [0076], testing modeling). Test package or configuration (information for testing)”.
PNG
media_image1.png
552
706
media_image1.png
Greyscale
A person of ordinary skill in the art would know “a template” or a similar name variation, in this case “a job template” is a type of file that contain (as required in the claim language) parameters/data. In other words, is a way to utilize preconfigured data (i.e., parameters) for a task or process purposes (e.g., testing process). It is worth mentioning, that parameter is a broad term and could be interpreted as anything defining how something works or behave, in this case it was interpreted as data for testing. If we take a look of figure 5, we can see an automated testing implementation for a VNF or Virtual Network Function. Figure 5 uses a VNF configuration 512 (interpreted as job template with parameters) which has the purpose to add into a test platform the VNF including the configuration or preconfigured parameters (i.e., job template with parameters) “VNF onboarding and configuration 512 (e.g., adding a VNF into a test platform, configuring the VNF, etc.)” – emphasis added. This being said, the argued limitation as drafted is fully taught by the prior art. Therefore, applicant’s argument is not persuasive. Examiner recommends further amending the claim to indicate what the parameters are and what they do.
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) in view of Hermoni et al. (US Pub. No. 2018/0337931 – hereinafter Hermoni) and further in view of Lee et al. (US Pub. No. 2020/0344144 – hereinafter Lee).
With respect to claim 1 (currently amended), Tejaprakash teaches a method for remotely testing virtual network functions with edge gateway devices, the method comprising: 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 (see paragraph [0013], “As further shown in FIG. 1, and by reference number 135, test control device 115 can initially receive a test package (e.g., including VNF or other SDN functionality, tests, test scripts, use cases, selection of tests, configuration for tests, etc.). As shown by reference number 140, test control device 115 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). As shown by reference number 145, test control device 115 can configure the test package (e.g., import the test package into test bed 120, identify test cases, obtain and use external tools for testing, etc.”. See paragraph [0047], “In some implementations, test control device 220 can determine a set of tests to perform, as described herein. In this case, test control device 220 can determine a set of test cases for the set of tests. For example, test control device 220 can receive user selected test cases, and can automatically identify test cases based on a test package, stored information identifying previous test cases for previous test packages, and/or the like. In this case, test control device 220 can determine a similarity between a test package and previous test packages to select previous test cases, such as based on a VNF type, an SDN type, a test package source (e.g., a user, a vendor, a company, an industry, a geography, etc.), and/or the like.”. See paragraph [0053], “In some implementations, test control device 220 can utilize a continuous integration and continuous deployment (CICD) tool set for testing during development of the VNF. For example, test control device 220 can automatically trigger testing on a VNF of the test package during development of the VNF (e.g., based on one or more testing criteria being satisfied) and can automatically deploy versions of a VNF of the test package based on results of the automatically triggered testing. In some implementations, test control device 220 can utilize a version control tool to perform testing on versions of a VNF. For example, test control device 220 can trigger a version control tool to provide a version of the VNF as a test package, and can provide results of testing to the version control tool to enable error correction for subsequent versions. In some implementations, test control device 220 can utilize a tool of test control device 220 (e.g., a collocated tool), a vendor provided tool (e.g., a tool provided by a vendor of the VNF and not collocated with test control device 220 in cloud computing environment 230), an open source tool, and/or the like.”. Furthermore, see figure 5 (and related text) and paragraphs [0081], [0085], [0089]).
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 (See abstract, “A device can receive a test package for testing. The test package can include at least one virtual network function (VNF) for testing.”. See paragraph [0010], “A network operator can utilize software defined networking (SDN) and network function virtualization (NFV) to manage packet routing for a network provided by the network operator, interaction with backend networks provided by one or more backend network providers, and/or the like. For example, 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.”. See paragraphs [0024]-[0025] and figure 2 (and related text), “Virtual machine 225-2 includes a software implementation of a machine (e.g., a computer) that executes programs like a physical machine. Virtual machine 225-2 can be either a system virtual machine or a process virtual machine, depending upon use and degree of correspondence to any real machine by virtual machine 225-2. A system virtual machine can provide a complete system platform that supports execution of a complete operating system (“OS”). A process virtual machine can execute a single program, and can support a single process. In some implementations, virtual machine 225-2 can execute on behalf of a user (e.g., client device 210), and can manage infrastructure of cloud computing environment 230, such as data management, synchronization, or long-duration data transfers. In some implementations, a set of virtual machines 225-2 can be deployed as a set of network devices with a configured topology to test a VNF.”). Furthermore, see paragraphs [0043], [0046], [0048], [0067]. Examiner notes: claim limitations in independent claim 1 limit a plurality of users (e.g., first, second and third user) performing certain steps. It is noted that performing these steps either by one or more users would provide the same result as limited in the claim, which is reasonable interpreted as a mere collaboration/interaction of different users/clients in a network (see Tejaprakash, plurality of client devices 210)).
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; and 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 (see paragraphs [0014], [0020], “Cloud computing environment 230 includes an environment that delivers computing as a service, whereby shared resources, services, etc. can be provided to test a VNF to enable automatic testing and/or deployment of VNFs. Cloud computing environment 230 can provide computation, software, data access, storage, and/or other services that do not require end-user knowledge of a physical location and configuration of a system and/or a device that delivers the services. As shown, cloud computing environment 230 can include a test control device 220 and one or more computing resources 225. In some implementations, cloud computing environment can correspond to and/or implement at least one of testing environment 110, test control device 115, test bed 120, network device 125, and/or the like.”. See paragraph [0029], “Network device 250 includes physical and/or virtualized instances of one or more devices (e.g., one or more traffic transfer devices) capable of processing and/or transferring traffic between endpoint devices. For example, network device 250 can include a firewall, a router, a gateway, a switch, a hub, a bridge, a reverse proxy, a server (e.g., a proxy server), a security device, an intrusion detection device, a load balancer, or a similar device. In some implementations, network device 250 can include a physical device, such as a router connected to and/or controlled by computing resource 225. In some implementations, network device 250 can include a virtualized device implemented by computing resource 225 in a test bed to provide a testing environment for a VNF. In some implementations, network device 250 corresponds to network device 125 shown in FIG. 1.”. Furthermore, see paragraph [0053], [0069], [0071]. Examiner notes: claim limitations in independent claim 1 limit a plurality of users (e.g., first, second and third user) performing certain steps. It is noted that performing these steps either by one or more users would provide the same result as limited in the claim, which is reasonable interpreted as a mere collaboration/interaction of different users/clients in a network (see Tejaprakash, plurality of client devices 210)), wherein executing the test is based on the job template (See figure 5 (and related text) and paragraph [0076], testing modeling, which includes the test package/configuration/parameter as further explained for better clarification above in “Response to Arguments” section). generating, via the application, based on a fourth user input, a job template comprising parameters to use when executing the test (See figure 5 (and related text) and paragraph [0076], which includes the test package/configuration/parameter as further explained for better clarification above in “Response to Arguments” section).
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 (see paragraphs [0146], [0151], “Once a configuration is in place, 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. Tests will run on the target orchestration platform. Once tests are complete, results will be published back to the marketplace, where the blockchain will log those results, along with the hash code of the result file, that is attached to the record in the marketplace.”). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Tejaprakash’s teaching, which receives a test package for testing, the test package can include one virtual network function (VNF) for testing, by downloading via the application the image based on the first user input as suggested by Hermoni, as Hermoni would provide flexibility of the NFV-based network enhancing and optimizing the network's capacity and performance (see paragraph [0004]). 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 (see paragraph [0025], “One or more of the components 112, 115, 116, 118, 120 may be created in response to, or as part of, instantiation of the commissioning VM 110. For example, one or more of the components 112, 115, 116, 118, 120 may be created automatically when the commissioning VM 110 is instantiated. As such, relatively little configuration of the commissioning VM 110 is required by a customer, and after instantiation of the commissioning VM 110 an engineer can access the commissioning VM 110 via the remote access connection facility 115, to perform subsequent configuration, instantiation and/or testing steps in the environment 100. The commissioning VM 110 may be relatively easy for a customer to instantiate, compared to a case in which the customer is required to instantiate (and configure) other VMs in the environment that are to perform the VNF. The commissioning VM 110, which is dedicated to the task of instantiating and configuring other VMs to perform VNFs, is less complex and/or more lightweight than such other VMs, and is thus easier for a customer to instantiate and/or configure. Further, the customer only instantiates a single VM (namely the commissioning VM 110), rather than multiple VMs in the environment 100. Moreover, in embodiments, the commissioning VM 110 can be instantiated and/or configured without knowledge of the particular properties of the customer network. That is, the commissioning VM 110 may be provided as a “standard” VM, instead of being bespoke to the particular customer network. Data that is customer network-specific can be provided at a later stage, by the remote engineer.”. See paragraph [0026], “In alternative embodiments, one or more of the components 112, 115, 116, 118, 120 are created manually and/or based on user input following instantiation of the commissioning VM 110. In alternative embodiments, the commissioning VM 110 is not instantiated by a customer. For example, instantiation of the commissioning VM 110 may be performed remotely, e.g. via a remote access connection facility in a further VM.”. See paragraph [0029], “In embodiments, the VIM component 140 is capable of instantiating VMs in the virtualized environment 100. Such VMs could be instantiated manually, e.g. by a customer interacting with the VIM component 140 in the customer network.”. Examiner notes: claim limitations in independent claim 1 limit a plurality of users (e.g., first, second and third user) performing certain steps. It is noted that performing these steps either by one or more users would provide the same result as limited in the claim, which is reasonable interpreted as a mere collaboration/interaction of different users/clients in a network (see Tejaprakash, plurality of client devices 210)). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify the combination of Tejaprakash and Hermoni, by receiving 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 as suggested by Lee, as Lee would provide steps for testing virtual network functions in a virtualized environment of a customer network (see paragraph [0002]). 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 (see paragraph [0023], “In operation, a system identifies a virtual network function package or network service definition for performing integrity verification. See operation 102. The system computes a unique identifier (e.g., a checksum, a hash, a signature, etc.) of the VNF package or the network service definition that allows verification of an integrity of the VNF package or the network service definition. See operation 104. The system stores the unique identifier in a blockchain or a shared database. See operation 106.”. Furthermore, see paragraphs [0106], [0109], [0115], [0122], [0125], [0128], [0131]. Examiner notes: claim limitations in independent claim 1 limit a plurality of users (e.g., first, second, third and fourth user) performing certain steps. It is noted that performing these steps either by one or more users would provide the same result as limited in the claim, which is reasonable interpreted as a mere collaboration/interaction of different users/clients in a network (see Tejaprakash, plurality of client devices 210)).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify the combination of Tejaprakash and Lee, by receiving 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 as suggested by Hermoni, as Hermoni would provide flexibility of the NFV-based network enhancing and optimizing the network's capacity and performance (see paragraph [0004]). 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 (see paragraphs [0068], [0082], [0085] and figures 4-6 (and related text), “In this way, test control device 220 can automatically test, certify, and deploy VNFs for use in network 240. Test control device 220 can integrate tools collocated in a cloud computing environment 230 with test control device 220, external tools (e.g., vendor provided tools), and/or the like into an end-to-end testing platform. Moreover, test control device 220 can automatically configure testing for the VNF. In this way, the test control device can reduce an amount of time to test and certify a VNF, thereby improving network performance relative to a manual technique that results in VNF deployment being delayed. Moreover, based on implementing test control device 220 in a cloud computing environment 230, test control device 220 can automatically scale and reallocate computing resources for testing, sandboxing, and/or the like, thereby reducing resource utilization (e.g., computing resource utilization, memory resource utilization, and/or the like) relative to a manual testing technique. 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.”. Examiner notes: claim limitations in independent claim 1 limit a plurality of users (e.g., first, second, third and fourth user) performing certain steps. It is noted that performing these steps either by one or more users would provide the same result as limited in the claim, which is reasonable interpreted as a mere collaboration/interaction of different users/clients in a network (plurality of client devices 210)).
With respect to claims 12-13, the claims are directed to a system that corresponds to the method recited in claims 1-2, respectively (see the rejection of claims 1-2 above; wherein Tejaprakash also teaches such system in figures 1-3).
With respect to claim 20, the claim is directed to a medium that corresponds to the method recited in claim 1, respectively (see the rejection of claim 1 above; wherein Tejaprakash also teaches such medium in paragraphs [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). 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 (see figures 8-9 (and related text), host type). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify the combination of Tejaprakash, Hermoni and Lee, by receiving 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 as suggested by Shaikh, as Shaikh would provide steps to manage the configuration of the VNF after the VNF has been instantiated (see paragraph [0006]). With respect to claim 14, the claim is directed to a system that corresponds to the method recited in claim 3, respectively (see the rejection of claim 3 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).
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]] (see 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 in the non-production environment 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 in the non-production environment. Any failure in testing of the virtual router may require re-work of the virtual router, redeployment of the virtual router in the non-production environment, and retesting of the virtual router.”. “Upon successful testing of the virtual router, the development platform may deploy the virtual router in the non-production environment and may perform validation and performance testing on the virtual router VNF. The performance testing may be performed by development platform to predict and study behavior of the virtual router under load conditions before deploying the virtual router in the production environment.”). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify the combination of Tejaprakash, Hermoni and Lee, wherein the service comprises at least one of the following: a single router as suggested by Prasad, as Prasad would provide steps to 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 in the non-production environment, thus testing virtual network functions.
With respect to claim 15, the claim is directed to a system that corresponds to the method recited in claim 4, respectively (see the rejection of claim 4 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 Sidebottom et al. (US Pat. No. 10,785,109 – hereinafter Sidebottom). With respect to claim 5 (original), Tejaprakash in view of Hermoni in view of Lee is silent to disclose, however in an analogous art, Sidebottom 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 (see figures 5 and 7A, 7E (and related text) and column 21 lines 42-55, “As further shown, at step 2, design platform 215 may assign a vendor A VNF to perform the URL filtering function for the first traffic flow. As shown, design platform 215 may determine, based on the attribute information and the design parameters, a bandwidth capability of the vendor A VNF configured to perform the URL filtering function (e.g., BW=50/(2c.sub.url)=50/(2×3)=8), a latency capability of the vendor A VNF configured to perform the URL filtering function (e.g., Lat.=c.sub.url=3), and a cost of the vendor A VNF configured to perform the URL filtering function (e.g., Cost=14). Here, one instance of the vendor A VNF configured to perform the URL filtering function is sufficient since the bandwidth capability of the VNF (e.g., 8) meets or exceeds the bandwidth parameter for the first traffic flow of (e.g., 5)”). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify the combination of Tejaprakash, Hermoni and Lee, by identifying a uniform resource locator associated with viewing a console of the VNF, wherein executing the test is based on the uniform resource locator as suggested by Sidebottom, as Sidebottom would generate a network service design, associated with providing the network service, based on the set of design parameters and the attribute information (see abstract). With respect to claim 16, the claim is directed to a system that corresponds to the method recited in claim 5, respectively (see the rejection of claim 5 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). 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 (see column 8 lines 33-43, “The NFV management system 411 may also include a service fulfillment module 435 that manages service and resource (e.g. VNF) instance lifecycle activities as part of the process and orchestration activities. This may include on boarding, initiation (e.g. instantiation), installation and configuration, scaling, termination, software update (e.g. of a running VNF, etc.), test environment, and/or rollback procedure. Additionally, the service fulfillment module 435 may also provide decomposition of an order to multiple network services, and the activation of such network service as a single VNF instance, or as a chain of VNF instances.”. See column 15 lines 10-26, “As an example flow, the testing software 602 may reach a time for verifying that a network service (e.g. firewall) is functioning, according to a configured testing plan. The 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. The testing software 202 may program the SDN controller 604 such that flows exiting its virtual machine (VM) via interface 2 with parameters 1.1.1.1:4578>2.2.2.2:80 should be sent to the ingress of the network service 606.”. “The testing software 602 may also program the SDN controller 604 such that flows exiting an egress interface of the network service 606 with parameters 1.1.1.1:4578>2.2.2.2:80 should be sent back to the interface 3 of the testing software 602 virtual machine. The testing software 602 may create a TCP connection according to chosen parameters and send an HTTP request via interface 2.”). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify the combination of Tejaprakash, Hermoni and Lee, 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 as suggested by Zemlerub, as Zemlerub would enhance and provide via a NFV platform delivery of network functions that support the network services by implementing virtual network functions (VNFs) that are delivered through software virtualization on standard hardware. As a result, network service providers have been able to quickly adapt to the on-demand, dynamic needs of telecommunications traffic and services (see paragraphs [0002] and [0009]-[0011]).
With respect to claim 17, the claim is directed to a system that corresponds to the method recited in claim 6, respectively (see the rejection of claim 6 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). 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 (see figure 2 (and related text) and paragraphs [0038]-[0039]). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify the combination of Tejaprakash, Hermoni and Lee, wherein the test is a Netconf test using a Netconf template, wherein executing the test is based on the Netconf template as suggested by Yeung, as Yeung would provide a way to monitor the virtual network function to detect satisfaction of the condition and, in response to detecting satisfaction of the condition, the VNF manager can perform the action associated with the lifecycle management policy (see abstract and paragraph [0001]). With respect to claim 18, the claim is directed to a system that corresponds to the method recited in claim 7, respectively (see the rejection of claim 7 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). 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 (see paragraphs [0031]-[0035], [0091], “Test configurations in UTP include modeling the configuration of the test component as well as the configuration of the test item (system or component under test). Two patterns are proposed in UTP specification to model these configurations, one of them being modeling these configurations as constraints. Although UML has a language for constraints specifications, similar to behaviors, it also allows the usage of other languages. Test 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 of UML to specify test configurations as constraints expressed in languages that deployment management engines can process. Therefore, such use of UTP is useful for dealing with Challenge #2.”). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify the combination of Tejaprakash, Hermoni and Lee, wherein the test is an Ansible test using an Ansible playbook, wherein executing the test is based on the Ansible playbook as suggested by Jebbar, as Jebbar would provide an architecture for live testing, comprising a platform independent Test Planner for generating a test package in response to receiving an event; and a platform dependent Test Execution Framework (TEF) for executing the test package in an environment serving live traffic (see abstract and paragraph [0005]). With respect to claim 19, the claim is directed to a system that corresponds to the method recited in claim 8, respectively (see the rejection of claim 8 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) and further in view of Htay (US Pub. No. 2017/0244606). With respect to claim 10 (original), Tejaprakash in view of Hermoni in view of Lee 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, an authorization state, a host type of the edge gateway device, and a checksum associated with verifying the image (see paragraphs [0004], [0006], [0008], “The bandwidth management method can be performed by a bandwidth management system communicatively coupled to the SDN controller network via an SDN controller. The network service can provide distribution of uniquely identifiable images or software containers between a source and destination location in the network. The network service can provide distribution of uniquely identifiable content between a source and destination location in the network, wherein the uniquely identifiable content is identifiable over the network based on one of a manifest file and a hash signature. The detecting congestion can be responsive to continually monitoring the network and the network service with identifiable data therein.”. See paragraphs [0030], [0034]-[0035], “The bandwidth management orchestration system 400 is configured to determine which images, containers, etc. are being distributed over the network 10. This is done through manifest files and associated data, processed by the container runtime analyzer 408 and stored in the scalable storage 412. A manifest file in computing is a file containing metadata for a group of accompanying files that are part of a set or coherent unit. For example, the files of a computer program may have a manifest describing the name, version number, and the constituting files of the program. In an exemplary embodiment, manifest files are obtained in a JavaScript Object Notation (JSON) format for processing by the container runtime analyzer 408.”. See paragraphs [0040], [0045], “Referring to FIG. 8, in an exemplary embodiment, a flowchart illustrates a container runtime analyzer process 600, which may be implemented by the container runtime analyzer 408 in the bandwidth management orchestration system 400. The process 600 describes the functionality of the container runtime analyzer 408, which may include identifying specific image or software container downloads, between source and destination locations in the network 10, and monitoring for associated congestion. The process 600 includes receiving container runtime data, and analyzing the data to determine source and destination locations of downloads (step 602); determining network services supporting the source and destination locations (step 604); receiving network data and monitor for congestion between the source and destination locations (step 606); marking a container indicating congestion when it is determined there is network congestion between the source and destination locations (step 608); informing the bandwidth orchestrator 410 of the marked containers (step 610); and continuing to monitor the network 10 (step 612). That is, the container runtime analyzer 408 generally identifies image or software container downloads, between source and destination locations in the network 10, and monitors the network 10 to determine if any associated network service is congested.”).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify the combination of Tejaprakash, Hermoni and Lee, by 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 as suggested by Htay, as Htay would a mechanism to identify images, software containers, or any other uniquely identifiable content downloaded between two points (source and destination locations) in a network and to monitor for congestion associated therewith (see paragraph [0045]).
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.
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