Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
2. This office action has been issued in response to amendment filed on 03/19/2026. Claims 1, 3, 12-15 and 20 have been amended. Claims 22-24 have been added. Claims 1-24 are pending, of which claims, of which claims 1, 14 and 15 are in independent form. Accordingly, this action has been made FINAL.
Response to Argument
3. Claims 12, 13 and 20 have been amended to overcome the claim objections. Therefore, the claim objections for claims 12, 13 and 20 have been withdrawn.
The Office will maintain claim 14 invoke 112(f).
Claims 1, 14 and 15 have been amended to overcome the 112(b) rejection. Therefore, the 112(b) rejection for claims 1, 14 and 15 has been withdrawn.
Based on amended claim 1 and applicant’s arguments, the 101 rejection for claims 1-13 has been withdrawn.
Applicant's arguments with respect to claims 1-24 have been considered but are moot in view of the new ground(s) of rejection.
Status of Claims
4. Claims 1-24 are pending, of which claims, of which claim 1, 14 and 15 are in independent form.
The Office's Note:
5. The Office has cited particular paragraphs / columns and line numbers in the reference(s) applied to the claims above for the convenience of the Applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim(s), other passages and figures may apply as well. It is respectfully requested from the Applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the cited passages as taught by the prior art or relied upon by the Examiner.
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.
6. Claims 1-24 are rejected under 35 U.S.C. 103 as being unpatentable over Watt (US 10630808– hereinafter Watt – IDS of records) and further in view of Bonas (US 20200358846– hereinafter Bonas).
Claim 1 is rejected, Watt teaches a computer-based system for controlling network traffic allocation to different versions of a software application for a service, the computer-based system comprising (Watt, abstract and summary):
a first version of the software application running on a first network resource of the computer- based system (Watt, US 10630808, fig. 3, component 305 – Set B, column 7, line 31 to 52, FIG. 3 shows an example of a software testing and rollout system 300, which may be used to implement Blue-Green deployment or A/B testing functionality… The software testing and rollout system 300 includes a load balancer 301, which can route traffic to different versions of an application or software denoted Set A 303 and Set B 305. For example, the Set A 303 may represent the “Blue” or updated software version, with the Set B 305 representing the “Green” or currently deployed software version. The load balancer 301 routes traffic to Set A 303 or Set B 305.);
a second version of the software application running on a second network resource of the computer-based system, wherein the second version is different from the first version(Watt, fig. 3, component 303 – Set A, column 7, line 31 to 52, FIG. 3 shows an example of a software testing and rollout system 300, which may be used to implement Blue-Green deployment or A/B testing functionality… The software testing and rollout system 300 includes a load balancer 301, which can route traffic to different versions of an application or software denoted Set A 303 and Set B 305. For example, the Set A 303 may represent the “Blue” or updated software version, with the Set B 305 representing the “Green” or currently deployed software version. The load balancer 301 routes traffic to Set A 303 or Set B 305.);
a router comprising a load balancer in communication with the first and second network resources(Watt, fig. 3, component 301 – Load Balancer, column 7, line 31 to 52, The software testing and rollout system 300 includes a load balancer 301, which can route traffic to different versions of an application or software denoted Set A 303 and Set B 305. For example, the Set A 303 may represent the “Blue” or updated software version, with the Set B 305 representing the “Green” or currently deployed software version. The load balancer 301 routes traffic to Set A 303 or Set B 305.);
a version control service for (Watt, fig. 7B, Contextual Gateway):
periodically polling the toggle interface for an updated network traffic allocation between the first and second versions of the software application(Watt, column 9, line 5 to 25, the contextual gateway 704-1 may provide contextual routing for a first application, with the contextual gateway 704-2 providing contextual routing for a second application and the contextual gateway 704-3 providing contextual routing for a third application. Thus, the central toggle controller 702 provides traffic toggle settings 703-1 for the first application to the contextual gateway 704-1, traffic toggle settings 703-2 for the second application to the contextual gateway 704-2, and traffic toggle settings 703-3 for the third application to the contextual gateway 704-3. Each of the contextual gateways 704 uses the traffic toggle settings provided by the central toggle controller 702 to enable feature toggling at the software-defined load balancer level, based on application context information. Column 11, line 3 to 13, Rule update processing module 745 is configured to update routing rules that are used by the routing rules evaluation module 742 to resolve header key/value pairs into route names. The rule update processing module 745 may be configured to run in a background thread or process to fetch the latest routing rules from a remote management entity such as the central toggle controller 702. The remote management module 746 may be used to interface to the central toggle controller 702, to set locations for fetching desired routing rule sets, such as by environment, feature flag, environment or toggle settings, etc. Watt, column 8, line 50 to column 9 line 25, FIG. 7A shows a contextual routing system 700 which pushes feature toggling capabilities to software-defined load balancers or contextual gateways. The contextual routing system 700 include a user 701, which interacts with a central toggle controller 702 to define routing policies for use by contextual gateways 704-1, 704-2 and 704-3 (collectively, contextual gateways 704). In some embodiments, the user 701 represents a system administrator, software developer or other authorized user permitted to define traffic toggle settings for different applications. Colum 9, line 26 to line 43, contextual gateway 704-1 utilizes traffic toggle settings 703-1 to determine routing of traffic between two versions of its associated application, denoted Set A 705-1 and Set B 705-2. The version of the application associated with Set A 705-1 may have a first set of features providing a first user experience, with the version of the application associated with Set B 705-2 having a second set of features providing a second user experience. Of course, it is possible for more than two versions of an application to be deployed, so as to provide more than two types of features or user experiences.); and
communicating the updated network traffic allocation between the first and second versions of the software application to the load balancer(Watt, column 9, line 33 to 43, contextual gateway 704-1 utilizes traffic toggle settings 703-1 to determine routing of traffic between two versions of its associated application, denoted Set A 705-1 and Set B 705-2. The version of the application associated with Set A 705-1 may have a first set of features providing a first user experience, with the version of the application associated with Set B 705-2 having a second set of features providing a second user experience. Of course, it is possible for more than two versions of an application to be deployed, so as to provide more than two types of features or user experiences. Column 3, line 59 to column 4, line 4, The contextual gateways 120 may be viewed as providing load balancing-as-a-service, to route requests from client devices 104 to application hosts 126 in an intelligent manner, such as based on application context information obtained or derived from the requests, on routing rules or other information stored in routing database 106, etc. The contextual gateways 120 are thus examples of software-defined load balancers.),
wherein the load balancer is for allocating network traffic for the software application to the first and second versions of the software application in accordance with the updated network traffic allocation(Watt, fig. 3, component 301 – Load Balancer, column 7, line 31 to 52, The software testing and rollout system 300 includes a load balancer 301, which can route traffic to different versions of an application or software denoted Set A 303 and Set B 305. For example, the Set A 303 may represent the “Blue” or updated software version, with the Set B 305 representing the “Green” or currently deployed software version. The load balancer 301 routes traffic to Set A 303 or Set B 305.).
Watt does not explicitly teach
a toggle interface for receiving user input indicative of a desired network traffic allocation between the first and second versions of the software application;
periodically polling the toggle interface for an updated network traffic allocation between the first and second versions of the software application, wherein the updated network traffic allocation is based on the user input received by the toggle interface;
However, Bonas teaches
a toggle interface for receiving user input indicative of a desired network traffic allocation between the first and second versions of the software application(Bonas, US 20200358846, fig. 2 and para [0042], the traffic information acquisition module 220 may determine the amount of traffic to be routed to the second version of the application in view of one or more user inputs, such as a user input of a proportion of traffic destined to the application to be routed to the second version of the application (e.g., 10% of the traffic destined to the application), a maximum amount of traffic that can be routed to the second version of the application, etc. Para [0107], determining the traffic information relating to the deployment of the second version of the application in view of a user input. Fig. 1 and para [0030], the traffic management component 142 may route a first proportion (e.g., 90%) of traffic destined to the application to a first version of the application deployed in system 100 and may route a second proportion (e.g., 10%) of traffic destined to the application to a second version of the application deployed in system 100. In some embodiments, the first version of the application may be an old version of the application. The second version of the application may be a new version of the application (e.g., a canary version). The source code of the second version of the application may include changes to the source code of the first version of the application. Para [0043-0045], the routing module 240 may split traffic destined to the application by routing a proportion of the traffic destined to the application to a given version of the application.);
periodically polling the toggle interface for an updated network traffic allocation between the first and second versions of the software application, wherein the updated network traffic allocation is based on the user input received by the toggle interface(Bonas, para [0033], The traffic management component 142 may also determine traffic information relating to the first version of the application deployed in the computer system, such as an amount of traffic that the first version of the application is capable of handling during a time frame (e.g., a few hours, a few minutes. Fig. 2 and para [0040-0041], The traffic information acquisition module 220 can acquire information about traffic that may be handled by one or more versions of an application. For example, the traffic information acquisition module 220 can determine traffic information relating to a first version of the application deployed in a computer system, such as an amount of traffic handled by the first version of the application during a time frame. The time frame may be and/or include any suitable period of time, such as a few minutes, a few hours, a day, etc. In some embodiments, the time frame may be and/or include a random period of time, a period of time designated by a user, etc. The amount of traffic may be handled by one or more instances of the first version of the application during the time frame. Each of the instances of the first version of the application may correspond to a replica of the first version of the application and may be deployed in one or more containers, nodes, etc. of the computer system. The amount of the traffic handled by the first version of the application during the time frame may include the number of requests that the instances of the first version of the application are capable of handling during the time frame. Fig. 2 and para [0042], the traffic information acquisition module 220 may determine the amount of traffic to be routed to the second version of the application in view of one or more user inputs, such as a user input of a proportion of traffic destined to the application to be routed to the second version of the application (e.g., 10% of the traffic destined to the application), a maximum amount of traffic that can be routed to the second version of the application, etc. Para [0107], determining the traffic information relating to the deployment of the second version of the application in view of a user input. Fig. 1 and para [0030], the traffic management component 142 may route a first proportion (e.g., 90%) of traffic destined to the application to a first version of the application deployed in system 100 and may route a second proportion (e.g., 10%) of traffic destined to the application to a second version of the application deployed in system 100. In some embodiments, the first version of the application may be an old version of the application. The second version of the application may be a new version of the application (e.g., a canary version). The source code of the second version of the application may include changes to the source code of the first version of the application. Para [0043-0045], the routing module 240 may split traffic destined to the application by routing a proportion of the traffic destined to the application to a given version of the application.).
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Bonas into Watt to reduce impact of new version of application to users of application. Determines proportion of traffic destined to application in view of ratio of amount of traffic to be routed to second version of application to amount of traffic handled by first version of application during time frame as suggested by Bonas (See abstract and summary).
Claim 2 is rejected for the reasons set forth hereinabove for claim 1, Watt and Bonas teach the computer-based system of claim 1, wherein the toggle interface stores feature flags related to the updated network traffic allocation between the first and second versions of the software application that is based on the user input received by the toggle interface(Watt, column 8, line 50 to column 9 line 25, FIG. 7A shows a contextual routing system 700 which pushes feature toggling capabilities to software-defined load balancers or contextual gateways. The contextual routing system 700 include a user 701, which interacts with a central toggle controller 702 to define routing policies for use by contextual gateways 704-1, 704-2 and 704-3 (collectively, contextual gateways 704). In some embodiments, the user 701 represents a system administrator, software developer or other authorized user permitted to define traffic toggle settings for different applications. Colum 9, line 26 to line 43, contextual gateway 704-1 utilizes traffic toggle settings 703-1 to determine routing of traffic between two versions of its associated application, denoted Set A 705-1 and Set B 705-2. The version of the application associated with Set A 705-1 may have a first set of features providing a first user experience, with the version of the application associated with Set B 705-2 having a second set of features providing a second user experience. Of course, it is possible for more than two versions of an application to be deployed, so as to provide more than two types of features or user experiences.).
Claim 3 is rejected for the reasons set forth hereinabove for claim 2, Watt and Bonas teach the computer-based system of claim 2, wherein the toggle interface comprises a web- based interface for receiving the user input indicative of a first proportion of network traffic routed to the first version of the software application and a second proportion of network traffic routed to the second version of the software application (Watt, fig. 4 and column 7, line 66 to column 8, line 3, The feature toggling system 400 illustrates a new feature 401, along with feature flags or toggles 403 that are set to “ON” or “OFF” to enable and disable the new feature 401 for different groups of consumers 405. Bonas, US 20200358846, fig. 2 and para [0042], the traffic information acquisition module 220 may determine the amount of traffic to be routed to the second version of the application in view of one or more user inputs, such as a user input of a proportion of traffic destined to the application to be routed to the second version of the application (e.g., 10% of the traffic destined to the application), a maximum amount of traffic that can be routed to the second version of the application, etc. Para [0107], determining the traffic information relating to the deployment of the second version of the application in view of a user input. Fig. 1 and para [0030], the traffic management component 142 may route a first proportion (e.g., 90%) of traffic destined to the application to a first version of the application deployed in system 100 and may route a second proportion (e.g., 10%) of traffic destined to the application to a second version of the application deployed in system 100. In some embodiments, the first version of the application may be an old version of the application. The second version of the application may be a new version of the application (e.g., a canary version). The source code of the second version of the application may include changes to the source code of the first version of the application. Para [0043-0045], the routing module 240 may split traffic destined to the application by routing a proportion of the traffic destined to the application to a given version of the application.).
Claim 4 is rejected for the reasons set forth hereinabove for claim 2, Watt and Bonas teach the computer-based system of claim 2, wherein the toggle interface employs a Boolean attribute that has a first value when only one of the first and second versions of the software application is available for deployment, and has a second value when both of the first and second versions of the software application are available for deployment (Watt, fig. 4 and column 7, line 66 to column 8, line 3, The feature toggling system 400 illustrates a new feature 401, along with feature flags or toggles 403 that are set to “ON” or “OFF” to enable and disable the new feature 401 for different groups of consumers 405. Watt, column 11, line 35 to 56, The contextual gateways 704 in some embodiments are instantiated with environment labels in order to fetch a flag set from the routing database or central toggle controller 702. For example, a contextual gateway may be instantiated with an environment label such as ‘non-production’ in order to fetch appropriate flags set from the routing database. A production gateway could be flagged ‘prod’ and a non-production gateway could be flagged ‘non prod’ and then those values would show in the user interface of the central toggle controller 702 (e.g., in the routing rules editing interface provided by module 711) for the user 701 to specify appropriate rule sets. When servers hosting different application versions are deployed, they may be similarly labeled based on the rule sets. For example, a label can be the server name itself (e.g., route to server A) or servers can be grouped under a label (e.g., version 1.2 servers). The contextual gateways 704 are thus grouped in environments, and servers hosting different application versions would also be grouped by labels to facilitate rule specification (e.g., the above-described routing rule of “For non-production environment, if (storename>10000) then route to servers hosting application versions labeled ‘beta’.”).).
Claim 5 is rejected for the reasons set forth hereinabove for claim 1, Watt and Bonas teach the computer-based system of claim 1, wherein the second version has a different name than the first version (Watt, column 10, line 47 to 54, A given header may include the key/value pair “storename:1234567” and the routing database defined by the user 701 may include the routing rule “For non-production environment, if (storename>10000) then route to servers hosting application versions labeled ‘beta’.” This routing rule would cast traffic for a particular store set to deployed servers hosting application versions with a ‘beta’ label.).
Claim 6 is rejected for the reasons set forth hereinabove for claim 5, Watt and Bonas teach the computer-based system of claim 5, wherein the different name of the second version comprises a name of the first version plus a suffix(Watt, column 10, line 47 to 54, A given header may include the key/value pair “storename:1234567” and the routing database defined by the user 701 may include the routing rule “For non-production environment, if (storename>10000) then route to servers hosting application versions labeled ‘beta’.” This routing rule would cast traffic for a particular store set to deployed servers hosting application versions with a ‘beta’ label.).
Claim 7 is rejected for the reasons set forth hereinabove for claim 1, Watt and Bonas teach the computer-based system of claim 1, wherein: the first network resource comprises a first endpoint of a network comprising the load balancer (Watt, column 10, line 62 to column 11, line 2, The endpoint map module 744 provides a mapping of route names to hostnames, IP addresses or other identifiers for different application instances (e.g., particular servers, virtual machines, containers, etc. hosting application instances). The web request forwarding module 747 forwards the web request received by the web request handler module 741 to the IP/hostname or other identifier provided by the endpoint map module 744. Watt, fig. 3, component 301 – Load Balancer, column 7, line 31 to 52, The software testing and rollout system 300 includes a load balancer 301, which can route traffic to different versions of an application or software denoted Set A 303 and Set B 305. For example, the Set A 303 may represent the “Blue” or updated software version, with the Set B 305 representing the “Green” or currently deployed software version. The load balancer 301 routes traffic to Set A 303 or Set B 305); and
the second network resource comprises a second endpoint of the network (Watt, column 10, line 62 to column 11, line 2, The endpoint map module 744 provides a mapping of route names to hostnames, IP addresses or other identifiers for different application instances (e.g., particular servers, virtual machines, containers, etc. hosting application instances). The web request forwarding module 747 forwards the web request received by the web request handler module 741 to the IP/hostname or other identifier provided by the endpoint map module 744. Watt, fig. 3, component 301 – Load Balancer, column 7, line 31 to 52, The software testing and rollout system 300 includes a load balancer 301, which can route traffic to different versions of an application or software denoted Set A 303 and Set B 305. For example, the Set A 303 may represent the “Blue” or updated software version, with the Set B 305 representing the “Green” or currently deployed software version. The load balancer 301 routes traffic to Set A 303 or Set B 305).
Claim 8 is rejected for the reasons set forth hereinabove for claim 7, Watt and Bonas teach the computer-based system of claim 7, wherein the first network resource comprises a first pod in the network and the second network resource comprises a second pod in the network(Watt, column 10, line 62 to column 11, line 2, The endpoint map module 744 provides a mapping of route names to hostnames, IP addresses or other identifiers for different application instances (e.g., particular servers, virtual machines, containers, etc. hosting application instances). The web request forwarding module 747 forwards the web request received by the web request handler module 741 to the IP/hostname or other identifier provided by the endpoint map module 744. Column 5, line 54 to 63, Such virtualization infrastructure illustratively includes container-based virtualization infrastructure configured to provide Docker containers or other types of Linux containers (LXCs).)
Claim 9 is rejected for the reasons set forth hereinabove for claim 8, Watt and Bonas teach the computer-based system of claim 8, wherein the first pod comprises a first collection of one or more containers and the second pod comprises a second collection of one or more containers(Watt, column 10, line 62 to column 11, line 2, The endpoint map module 744 provides a mapping of route names to hostnames, IP addresses or other identifiers for different application instances (e.g., particular servers, virtual machines, containers, etc. hosting application instances). The web request forwarding module 747 forwards the web request received by the web request handler module 741 to the IP/hostname or other identifier provided by the endpoint map module 744. Column 5, line 54 to 63, Such virtualization infrastructure illustratively includes container-based virtualization infrastructure configured to provide Docker containers or other types of Linux containers (LXCs).).
Claim10 is rejected for the reasons set forth hereinabove for claim 1, Watt and Bonas teach the computer-based system of claim 1, wherein the second version of the software application is developed after the first version of the software application(Watt, fig. 3, component 303 – Set A, column 7, line 31 to 52, FIG. 3 shows an example of a software testing and rollout system 300, which may be used to implement Blue-Green deployment or A/B testing functionality… The software testing and rollout system 300 includes a load balancer 301, which can route traffic to different versions of an application or software denoted Set A 303 and Set B 305. For example, the Set A 303 may represent the “Blue” or updated software version, with the Set B 305 representing the “Green” or currently deployed software version. The load balancer 301 routes traffic to Set A 303 or Set B 305.).
Claim 11 is rejected for the reasons set forth hereinabove for claim 10, Watt and Bonas teach the computer-based system of claim 10, wherein the second version fixes at least one bug in the first version(Watt, fig. 3, component 303 – Set A, column 7, line 31 to 52, FIG. 3 shows an example of a software testing and rollout system 300, which may be used to implement Blue-Green deployment or A/B testing functionality… The software testing and rollout system 300 includes a load balancer 301, which can route traffic to different versions of an application or software denoted Set A 303 and Set B 305. For example, the Set A 303 may represent the “Blue” or updated software version, with the Set B 305 representing the “Green” or currently deployed software version. The load balancer 301 routes traffic to Set A 303 or Set B 305.).
Claim 12 is rejected for the reasons set forth hereinabove for claim 1, Watt and Bonas teach the computer-based system of claim 1, wherein the network traffic comprises hyper transfer protocol (HTTP) requests for the service (Watt, fig. 2 and column 6, line 40 to 51, the request comprises a hypertext transfer protocol (HTTP) web request comprising a header, and step 204 includes stripping the header from the HTTP web request and processing the header to obtain one or more key/value pairs.).
Claim 13 is rejected for the reasons set forth hereinabove for claim 1, Watt and Bonas teach the computer-based system of claim 1, wherein the version control service is for communicating the updated network traffic allocation between the first and second versions of the software application to the load balancer via an application programming interface (API) (Watt, column 9, line 5 to 25, the contextual gateway 704-1 may provide contextual routing for a first application, with the contextual gateway 704-2 providing contextual routing for a second application and the contextual gateway 704-3 providing contextual routing for a third application. Thus, the central toggle controller 702 provides traffic toggle settings 703-1 for the first application to the contextual gateway 704-1, traffic toggle settings 703-2 for the second application to the contextual gateway 704-2, and traffic toggle settings 703-3 for the third application to the contextual gateway 704-3. Each of the contextual gateways 704 uses the traffic toggle settings provided by the central toggle controller 702 to enable feature toggling at the software-defined load balancer level, based on application context information. Column 11, line 3 to 13, Rule update processing module 745 is configured to update routing rules that are used by the routing rules evaluation module 742 to resolve header key/value pairs into route names. The rule update processing module 745 may be configured to run in a background thread or process to fetch the latest routing rules from a remote management entity such as the central toggle controller 702. The remote management module 746 may be used to interface to the central toggle controller 702, to set locations for fetching desired routing rule sets, such as by environment, feature flag, environment or toggle settings, etc. Column 9, line 5 to 25, Thus, the central toggle controller 702 provides traffic toggle settings 703-1 for the first application to the contextual gateway 704-1, traffic toggle settings 703-2 for the second application to the contextual gateway 704-2, and traffic toggle settings 703-3 for the third application to the contextual gateway 704-3. Each of the contextual gateways 704 uses the traffic toggle settings provided by the central toggle controller 702 to enable feature toggling at the software-defined load balancer level, based on application context information. Lucas, column 6, line 28 to line 46, the API of the different versions of the resource are the same to the client, so that the clients 110 may remain oblivious to which version of the resource is used to handle their requests. In some embodiments, there may be differences in the APIs of the different versions. In that case, in some embodiments, the request router 140 may be configured to translate a request formatted for the API of a first version to the API of a second version. Column 5, line 50 to 57, The computing services generally operate on computing resources of the service provider system 130, and may be controlled and configured by clients 110 via various interfaces such as graphical user interface (GUI) (e.g., as part of an administration control panel or web site) and/or as a programmatic interface such as an Application Programming Interface (API).).
As per claim 14, this is the system claim to system claim 1. Therefore, it is rejected for the same reasons as above.
As per claim 15, this is the method claim to system claim 1. Therefore, it is rejected for the same reasons as above.
As per claim 16, this is the method claim to system claim 2 and claim 3. Therefore, it is rejected for the same reasons as above.
As per claim 17, this is the method claim to system claim 4. Therefore, it is rejected for the same reasons as above.
As per claim 18, this is the method claim to system claim 5 and claim 6. Therefore, it is rejected for the same reasons as above.
As per claim 19, this is the method claim to system claim 7. Therefore, it is rejected for the same reasons as above.
As per claim 20, this is the method claim to system claim 8, claim 12 and claim 13. Therefore, it is rejected for the same reasons as above.
As per claim 21, this is the method claim to system claim 11. Therefore, it is rejected for the same reasons as above.
Claim 22 is rejected for the reasons set forth hereinabove for claim 1, Watt and Bonas teach the computer-based system of claim 1, wherein the toggle interface further comprises a user interface for receiving a numerical input indicative of a proportion of network traffic associated with each of the first and second versions of the software application, wherein the toggle interface enforces a constraint so that all network traffic is routed between the first and second versions of the software application, and wherein the numerical input for the second version of the software application is set to zero absent receipt of the user input( Bonas, fig. 2 and para [0042], the traffic information acquisition module 220 may determine the amount of traffic to be routed to the second version of the application in view of one or more user inputs, such as a user input of a proportion of traffic destined to the application to be routed to the second version of the application (e.g., 10% of the traffic destined to the application), a maximum amount of traffic that can be routed to the second version of the application, etc. Para [0107], determining the traffic information relating to the deployment of the second version of the application in view of a user input. Fig. 1 and para [0030], the traffic management component 142 may route a first proportion (e.g., 90%) of traffic destined to the application to a first version of the application deployed in system 100 and may route a second proportion (e.g., 10%) of traffic destined to the application to a second version of the application deployed in system 100. In some embodiments, the first version of the application may be an old version of the application. The second version of the application may be a new version of the application (e.g., a canary version). The source code of the second version of the application may include changes to the source code of the first version of the application. Para [0043-0045], the routing module 240 may split traffic destined to the application by routing a proportion of the traffic destined to the application to a given version of the application.).
Claim 23 is rejected for the reasons set forth hereinabove for claim 1, Watt and Bonas teach the computer-based system of claim 1, wherein the toggle interface further comprises a web-based interface for receiving a user input to update the desired network traffic allocation( Bonas, fig. 2 and para [0042], the traffic information acquisition module 220 may determine the amount of traffic to be routed to the second version of the application in view of one or more user inputs, such as a user input of a proportion of traffic destined to the application to be routed to the second version of the application (e.g., 10% of the traffic destined to the application), a maximum amount of traffic that can be routed to the second version of the application, etc. Para [0107], determining the traffic information relating to the deployment of the second version of the application in view of a user input. Fig. 1 and para [0030], the traffic management component 142 may route a first proportion (e.g., 90%) of traffic destined to the application to a first version of the application deployed in system 100 and may route a second proportion (e.g., 10%) of traffic destined to the application to a second version of the application deployed in system 100. In some embodiments, the first version of the application may be an old version of the application. The second version of the application may be a new version of the application (e.g., a canary version). The source code of the second version of the application may include changes to the source code of the first version of the application. Para [0043-0045], the routing module 240 may split traffic destined to the application by routing a proportion of the traffic destined to the application to a given version of the application.);
wherein a software automation server is communicatively coupled to the version control service, and wherein the second version of the software application is deployed by the software automation server (Bonas, fig. 2 and para [0043-0044], the deployment module 230 may deploy one or more instances of the second version of the application (also referred to as the “second instances”) in the computer system. The deployment module 230 may deploy each of the second instances in one or more containers, nodes, and/or any other suitable component of the computer system. In one implementation, the deployment module 230 may determine the number of the second instances in view of one or more user inputs (e.g., a user input providing the number of the second instances). In another implementation, the deployment module 230 may determine the number of the second instances in view of the workload information related to the first version of the application and the traffic information relating to the deployment of the second version of the application on the computer system. For example, the deployment module 230 can determine that a proportion of the traffic destined to the application is to be routed to the second version of the application (e.g., by determining a ratio of the amount of traffic to be routed to the second version of the application to the amount of traffic handled by the first version of the application during the time frame, by determining the proportion of the traffic destined to the application in view of a user input). The deployment module 230 may further determine the number of the second instances so that a ration of the number of the second instances to the number of the first instances corresponds to the proportion of the traffic destined to the application that is to be routed to the second version of the application. Para [0045], the routing module 240 may split traffic destined to the application by routing a proportion of the traffic destined to the application to a given version of the application); and
wherein the version control service is further for updating the web-based interface based on receipt of a request from the software automation server, wherein the second version of the software application is initially allocated zero network traffic upon deployment of the second version of the software application by the software automation server, and wherein the second version of the software application is subsequently allocated a non-zero percentage of network traffic based on the user input to the web-based interface(Bonas, para [0033], The traffic management component 142 may also determine traffic information relating to the first version of the application deployed in the computer system, such as an amount of traffic that the first version of the application is capable of handling during a time frame (e.g., a few hours, a few minutes. Fig. 2 and para [0040-0041], The traffic information acquisition module 220 can acquire information about traffic that may be handled by one or more versions of an application. For example, the traffic information acquisition module 220 can determine traffic information relating to a first version of the application deployed in a computer system, such as an amount of traffic handled by the first version of the application during a time frame. The time frame may be and/or include any suitable period of time, such as a few minutes, a few hours, a day, etc. In some embodiments, the time frame may be and/or include a random period of time, a period of time designated by a user, etc. The amount of traffic may be handled by one or more instances of the first version of the application during the time frame. Each of the instances of the first version of the application may correspond to a replica of the first version of the application and may be deployed in one or more containers, nodes, etc. of the computer system. The amount of the traffic handled by the first version of the application during the time frame may include the number of requests that the instances of the first version of the application are capable of handling during the time frame. Fig. 2 and para [0042], the traffic information acquisition module 220 may determine the amount of traffic to be routed to the second version of the application in view of one or more user inputs, such as a user input of a proportion of traffic destined to the application to be routed to the second version of the application (e.g., 10% of the traffic destined to the application), a maximum amount of traffic that can be routed to the second version of the application, etc. Para [0107], determining the traffic information relating to the deployment of the second version of the application in view of a user input. Fig. 1 and para [0030], the traffic management component 142 may route a first proportion (e.g., 90%) of traffic destined to the application to a first version of the application deployed in system 100 and may route a second proportion (e.g., 10%) of traffic destined to the application to a second version of the application deployed in system 100. In some embodiments, the first version of the application may be an old version of the application. The second version of the application may be a new version of the application (e.g., a canary version). The source code of the second version of the application may include changes to the source code of the first version of the application. Para [0043-0045], the routing module 240 may split traffic destined to the application by routing a proportion of the traffic destined to the application to a given version of the application.).
Claim 24 is rejected for the reasons set forth hereinabove for claim 16, Watt and Bonas teach the computer-based method of claim 16, further comprising:
automatically deploying, by a software automation server, the second version of the software application after deployment of the first version of the software application, wherein the second version of the software application is initially allocated zero network traffic(Bonas, para [0043-0044], the deployment module 230 may deploy one or more instances of the second version of the application (also referred to as the “second instances”) in the computer system. The deployment module 230 may deploy each of the second instances in one or more containers, nodes, and/or any other suitable component of the computer system. In one implementation, the deployment module 230 may determine the number of the second instances in view of one or more user inputs (e.g., a user input providing the number of the second instances). In another implementation, the deployment module 230 may determine the number of the second instances in view of the workload information related to the first version of the application and the traffic information relating to the deployment of the second version of the application on the computer system. For example, the deployment module 230 can determine that a proportion of the traffic destined to the application is to be routed to the second version of the application (e.g., by determining a ratio of the amount of traffic to be routed to the second version of the application to the amount of traffic handled by the first version of the application during the time frame, by determining the proportion of the traffic destined to the application in view of a user input). The deployment module 230 may further determine the number of the second instances so that a ration of the number of the second instances to the number of the first instances corresponds to the proportion of the traffic destined to the application that is to be routed to the second version of the application. Para [0045], the routing module 240 may split traffic destined to the application by routing a proportion of the traffic destined to the application to a given version of the application.);
receiving, by the toggle interface, a POST request from the software automation server (Bonas, para [0043-0044], by determining the proportion of the traffic destined to the application in view of a user input. Fig. 2 and para [0042], the traffic information acquisition module 220 may determine the amount of traffic to be routed to the second version of the application in view of one or more user inputs, such as a user input of a proportion of traffic destined to the application to be routed to the second version of the application (e.g., 10% of the traffic destined to the application), a maximum amount of traffic that can be routed to the second version of the application, etc. Para [0107], determining the traffic information relating to the deployment of the second version of the application in view of a user input. Para [0045], the routing module 240 may split traffic destined to the application by routing a proportion of the traffic destined to the application to a given version of the application.);
updating, by the version control service, the toggle interface upon receipt of the POST request, wherein updating the toggle interface comprises creating a feature flag for the second version of the software application accessible via the web-based interface (Bonas, para [0043-0044], by determining the proportion of the traffic destined to the application in view of a user input. Fig. 2 and para [0042], the traffic information acquisition module 220 may determine the amount of traffic to be routed to the second version of the application in view of one or more user inputs, such as a user input of a proportion of traffic destined to the application to be routed to the second version of the application (e.g., 10% of the traffic destined to the application), a maximum amount of traffic that can be routed to the second version of the application, etc. Para [0107], determining the traffic information relating to the deployment of the second version of the application in view of a user input. Para [0045], the routing module 240 may split traffic destined to the application by routing a proportion of the traffic destined to the application to a given version of the application.); and
wherein receiving user input indicative of a desired network traffic allocation between the first and second versions of the software application further comprises receiving a user input to allocate a non-zero percentage of the network traffic to the second version of the software application(Bonas, para [0043-0044], by determining the proportion of the traffic destined to the application in view of a user input. Fig. 2 and para [0042], the traffic information acquisition module 220 may determine the amount of traffic to be routed to the second version of the application in view of one or more user inputs, such as a user input of a proportion of traffic destined to the application to be routed to the second version of the application (e.g., 10% of the traffic destined to the application), a maximum amount of traffic that can be routed to the second version of the application, etc. Para [0107], determining the traffic information relating to the deployment of the second version of the application in view of a user input. Para [0045], the routing module 240 may split traffic destined to the application by routing a proportion of the traffic destined to the application to a given version of the application).
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 DUY KHUONG THANH NGUYEN whose telephone number is (571)270-7139. The examiner can normally be reached Monday - Friday 0800-1630.
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, Lewis Bullock can be reached at 5712723759. 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.
/DUY KHUONG T NGUYEN/ Primary Examiner, Art Unit 2199
Prosecution Insights