DETAILED ACTION
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 7-9 recite the limitation "a second service" in both the “sending, by the plugin to a second service” and the “receiving, at a second plugin of a second proxy of a second service”. The antecedent basis for this limitation in unclear in the claims.
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.
Claims 1-9 and 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Sinha et al. (US20210194780A1) in view of Coffing (US20190273746A1).
Regarding claim 1, Sinha discloses a method comprising ([Abstract] shows using service graphs to compare performance of a plurality of versions of a microservice; para [0005] shows the user may want to monitor metrics of the new version of the microservice in comparison to the previous version of the microservice - particularly where the deployment of the new version is a canary deployment; para [0094] shows a service 275 may comprise several independent applications (e.g., microservices)):
receiving, at a proxy corresponding to a service of an application, an outbound request from the service, the outbound request indicating a trace identifier (ID) identifying a trace [network traffic traversing the device(s)] of the outbound request in the application (Fig 1B and para [0040] show appliance 200 may act as a proxy to provide a connection from a client 102 to a server 106; para [0102] shows the service graph may be generated responsive to a request by a user; para [0103] shows the service graph monitor 516 may identify network traffic traversing the device(s));
assigning a custom label [version] to the outbound request, the custom label associated with the trace ID and indicating a version of the application towards which the outbound request is to be routed; and sending, by the plugin to a router of the proxy, the outbound request for routing (para [0065] shows client agent 120 may identify a running service or versions of various applications; para [0120] shows the service graph monitor 516 may identify differences in network traffic from the execution of the versions of the microservice; para [0121] shows the device 200 may route a portion of network traffic from the previous version of the microservice 575A1 to the new version of the microservice 575A2).
Sinha fails to show
receiving, at a plugin of a proxy corresponding to a service of an application, an outbound request;
assigning, by the plugin, a custom label.
However Coffing, in an analogous art (para [0005] shows applications are being developed as microservices; para [0023] shows access management system deployed via microservice may include a pluggable microgateway via plugins. Such a microgateway handles canary routing), discloses:
receiving, at a plugin of a proxy corresponding to a service of an application, an outbound request (para [0035] shows each incoming and outgoing request may be proxied before reaching a target microservice 140 or going outside of a microservice 140. The proxy may use a security plugin to validate each incoming request and to transform each outgoing request);
assigning, by the plugin, a custom label (para [0023] shows access management system deployed via microservice may include a pluggable microgateway capable of custom transformation via configurable plugins.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the proxy in Sinha (para [0040]) with the teaching of Coffing regarding such proxies 150 may be extended with a plugin to validate and transform requests (para [0031]) in order to use a security plugin to validate each incoming request and to transform each outgoing request (Coffing; para [0035]).
Regarding claim 2, Sinha-Coffing discloses the method of claim 1 further comprising: obtaining, by the plugin, the custom label from a shared in-memory storage of the proxy (Sinha; para [0076] shows tuples of information associated with a network packet or data flow may be used for distributing a network packet via a hash table; para [0088] shows the service graph generator may read and/or write data representing the service graph to a database.)
Regarding claim 3, Sinha-Coffing discloses the method of claim 2 further comprising: receiving, at the plugin, an inbound request corresponding to the outbound request, the inbound request indicating the trace ID and the custom label; storing, by the plugin, the trace ID and the custom label in the shared in-memory storage; and sending, by the plugin to the service, the inbound request for processing (Coffing; para [0035] shows each incoming and outgoing request may be proxied before reaching a target microservice 140 or going outside of a microservice 140. The proxy may use a security plugin to validate each incoming request and to transform each outgoing request; para [0091] shows metrics may include timing of requests or responses received.)
Regarding claim 4, Sinha-Coffing discloses the method of claim 1, wherein the service is a first version of a first service of the application, the version of the application is a second version of a second service of the application towards which the outbound request is to be routed, the second version being the first version or a different version (Sinha; para [0065] shows client agent 120 may identify a running service or versions of various applications; para [0121] shows the device 200 may route a portion of network traffic from the previous version of the microservice 575A1 to the new version of the microservice 575A2.)
Regarding claim 5, Sinha-Coffing discloses the method of claim 1, wherein the service is a first service of a first version of the application, the first version of the application comprising a first set of services of the application including the first service (Sinha; para [0065] shows client agent 120 may identify a running service or versions of various applications; para [0094] shows a service 275 may comprise microservices 575, wherein applications are built as a collection of different smaller services.)
Regarding claim 6, Sinha-Coffing discloses the method of claim 4, wherein the custom label indicates a second version of the application running in parallel to the first version of the application, the second version of the application comprising a second set of services of the application (Sinha; para [0065] shows client agent 120 may identify a running service or versions of various applications; para [0072] shows such architectures may allow functional parallelism, data parallelism, flow-based data parallelism, etc.; para [0106] shows the versions may be deployed concurrently for a portion of execution of the service.)
Regarding claim 7, Sinha discloses a method comprising ([Abstract] shows using service graphs to compare performance of a plurality of versions of a microservice; para [0005] shows the user may want to monitor metrics of the new version of the microservice in comparison to the previous version of the microservice - particularly where the deployment of the new version is a canary deployment; para [0094] shows a service 275 may comprise several independent applications (e.g., microservices)):
receiving, at a proxy corresponding to a first service of an application, a request indicating a trace identifier (ID) identifying a trace [network traffic traversing the device(s)] of the request in the application (Fig 1B and para [0040] show appliance 200 may act as a proxy to provide a connection from a client 102 to a server 106; para [0102] shows the service graph may be generated responsive to a request by a user; para [0103] shows the service graph monitor 516 may identify network traffic traversing the device(s)),
the first service being in a first lane [first percentage of network traffic] of the application, the first lane of the application corresponding to a first version of the application, the first version of the application comprising a first set of services of the application including the first service (para [0011] shows a first percentage of network traffic is distributed to a first version of the microservice and a second percentage of network traffic to a second version of the microservice; para [0065] shows client agent 120 may identify versions of various applications; para [0094] shows a service has several independent applications (e.g., microservices));
sending, to a second service in a second lane [second percentage of network traffic] of the application, the request, the second lane of the application corresponding to a second version of the application running in parallel to the first version of the application, the second version of the application comprising a second set of services of the application including the second service (para [0011] shows a first percentage of network traffic is distributed to a first version of the microservice and a second percentage of network traffic to a second version of the microservice; para [0064] shows client agent 120 may intercept a network communication at any point in a network stack and redirect the network communication to a destination; para [0072] shows such architectures may allow functional parallelism, data parallelism, flow-based data parallelism, etc.; para [0106] shows the versions may be deployed concurrently for a portion of execution of the service); and
receiving, at a second service in the first lane from the second lane, the request (para [0011] shows a first percentage of network traffic is distributed to a first version of the microservice and a second percentage of network traffic to a second version of the microservice; para [0064] shows client agent 120 may intercept a network communication at any point in a network stack and redirect the network communication to a destination; para [0106] shows the versions may be deployed concurrently for a portion of execution of the service; para [0121] shows the device 200 may shift or divert a portion of network traffic from the previous version of the microservice 575A1 to the new version of the microservice 575A2.)
Sinha fails to show:
receiving, at a plugin of a proxy corresponding to a first service, a request;
sending, by the plugin to a second service, the request;
receiving, at a second plugin of a second proxy of a second service, the request.
However Coffing, in an analogous art (para [0065] shows applications are being developed as microservices; para [0023] shows access management system deployed via microservice may include a pluggable microgateway via plugins. Such a microgateway handles canary routing), discloses:
receiving, at a plugin of a proxy corresponding to a first service, a request (para [0035] shows each incoming and outgoing request may be proxied before reaching a target microservice 140 or going outside of a microservice 140. The proxy may use a security plugin to validate each incoming request and to transform each outgoing request);
sending, by the plugin to a second service, the request (para [0035] shows each incoming and outgoing request may be proxied before reaching a target microservice 140 or going outside of a microservice 140. The proxy may use a security plugin to validate each incoming request and to transform each outgoing request);
receiving, at a second plugin of a second proxy of a second service, the request (para [0023] shows a “pod” may be provided for each microservice that is protected by a dedicated microgateway; para [0026] shows each microservices deployed in service A pod 140A and service B pod 140B may further each include proxy 150; para [0035] shows each incoming and outgoing request may be proxied before reaching a target microservice 140.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the proxy in Sinha (para [0040]) with the teaching of Coffing regarding such proxies 150 may be extended with a plugin to validate and transform requests (para [0031]) in order to use a security plugin to validate each incoming request and to transform each outgoing request (Coffing; para [0035]).
Regarding claim 8, Sinha-Coffing discloses method of claim 7 wherein:
receiving, at the plugin of the proxy corresponding to the first service, the request comprises (Coffing; para [0035] shows each incoming and outgoing request may be proxied before reaching a target microservice 140 or going outside of a microservice 140. The proxy may use a security plugin to validate each incoming request and to transform each outgoing request);
receiving, at the plugin of the proxy corresponding to the first service, an inbound request indicating the trace [network traffic traversing the device(s)] ID and a custom label [version of the microservice], the custom label associated with the trace ID and indicating the second version of the application towards which the request is to be routed (Sinha; Fig 1B and para [0040] show appliance 200 may act as a proxy to provide a connection from a client 102 to a server 106; para [0102] shows the service graph may be generated responsive to a request by a user; para [0103] shows the service graph monitor 516 may identify network traffic traversing the device(s); para [0120] shows the service graph monitor 516 may identify differences in network traffic from the execution of the versions of the microservice; para [0121] shows the device 200 may route a portion of network traffic from the previous version of the microservice 575A1 to the new version of the microservice 575A2);
storing, by the plugin of the proxy corresponding to the first service, the trace ID and the custom label in a shared in-memory storage (Sinha; para [0076] shows tuples of information associated with a network packet or data flow may be used for distributing a network packet via a hash table; para [0088] shows the service graph generator may read and/or write data representing the service graph to a database); and
sending, by the plugin of the proxy corresponding to the first service to the first service, the inbound request for processing (Sinha; para [0005] shows the user may want to monitor metrics of the new version of the microservice in comparison to the previous version of the microservice—particularly where the deployment of the new version is a canary deployment. Coffing; para [0035] shows each incoming and outgoing request may be proxied before reaching a target microservice 140 or going outside of a microservice 140. The proxy may use a security plugin to validate each incoming request and to transform each outgoing request.)
Regarding claim 9, Sinha-Coffing discloses method of claim 8 wherein:
sending, by the plugin to the second service in the second lane of the application, the request comprises (Sinha; para [0121] shows the device 200 may shift or divert a portion of network traffic from the previous version of the microservice 575A1 to the new version of the microservice 575A2):
receiving, at the plugin of the proxy corresponding to the first service, an outbound request from the first service (Coffing; para [0035] shows each incoming and outgoing request may be proxied before reaching a target microservice 140 or going outside of a microservice 140. The proxy may use a security plugin to validate each incoming request and to transform each outgoing request),
the outbound request indicating the trace [network traffic traversing the device(s)] ID (Sinha; para [0102] shows the service graph may be generated responsive to a request by a user; para [0103] shows the service graph monitor 516 may identify network traffic traversing the device(s));
obtaining, by the plugin of the proxy corresponding to the first service, the custom label [version] from the shared in-memory storage (Sinha; para [0120] shows the service graph monitor 516 may identify differences in network traffic from the execution of the versions of the microservice; para [0076] shows tuples of information associated with a network packet or data flow via a hash table; para [0088] shows the service graph generator may read and/or write data representing the service graph to a database);
assigning, by the plugin of the proxy corresponding to the first service, the custom label to the outbound request (Sinha; para [0120] shows the service graph monitor 516 may identify differences in network traffic from the execution of the versions of the microservice), and
sending, by the plugin of the proxy corresponding to the first service to a router of the proxy, the outbound request for routing (Sinha; para [0121] shows the device 200 may route a portion of network traffic from the previous version of the microservice 575A1 to the new version of the microservice 575A2).
Regarding claim 14, claim 14 is directed to an apparatus. Claim 14 requires limitations that are similar to those recited in the method claim 1 to carry out the method steps. And since the references of Sinha-Coffing combined teach the method including limitations required to carry out the method steps, therefore claim 14 would have also been obvious in view of the structures disclosed in Sinha-Coffing combined.
Furthermore, Sinha-Coffing as combined discloses an apparatus comprising processing electronics (Sinha; para [0018]).
Regarding claim 15, claim 15 is directed to a device. Claim 15 requires limitations that are similar to those recited in the method claim 1 to carry out the method steps. And since the references of Sinha-Coffing combined teach the method including limitations required to carry out the method steps, therefore claim 15 would have also been obvious in view of the structures disclosed in Sinha-Coffing combined.
Furthermore, Sinha-Coffing as combined discloses a computer device comprising a computer readable medium having instructions stored thereon and executed by a computer processor (Sinha; para [0018]).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Sinha in view of Mankad et al. (US20220207053A1).
Regarding claim 10, Sinha discloses a method comprising ([Abstract] shows using service graphs to compare performance of a plurality of versions of a microservice; para [0005] shows the user may want to monitor metrics of the new version of the microservice in comparison to the previous version of the microservice - particularly where the deployment of the new version is a canary deployment; para [0094] shows a service 275 may comprise several independent applications (e.g., microservices)):
receiving, by a proxy corresponding to a service of an application, an outbound request from the service, the service corresponding to a version of the service (Sinha; para [0066] shows client agent 120 may identify a version of a running service or versions of various applications; para [0102] shows the service graph may be generated responsive to a request by a user; para [0088] shows the service graph generator may read and/or write data representing the service graph to a database; para [0120] shows the service graph monitor 516 may identify differences in network traffic from the execution of the versions of the microservice).
Sinha fails to teach:
obtaining, by the proxy corresponding to the service of the application, an address of a middleware towards which the outbound request is to be routed; and
routing, by the proxy corresponding to the service of the application, the outbound request to the middleware based on the address of the middleware.
However, Mankad discloses:
obtaining, by the proxy corresponding to the service of the application, an address of a middleware [database server] towards which the outbound request is to be routed; and routing, by the proxy corresponding to the service of the application, the outbound request to the middleware based on the address of the middleware (Fig 6 and para [0121] show of FIG. 6 where multiple proxy are used, each of those proxy may be configured to route user requests to the leader database server; para [0056] shows the IP address of the database server).
The database in Sinha (para [0120] is mapped to the custom transformation via configurable plugins in Mankad (para [0023]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teaching of Sinha (para [0120]) regarding the device may obtain, access or receive the topology 510 from a database (para [0100]) with the teaching of Mankad regarding where multiple proxy are used, each of those proxy may be configured to route user requests to the leader database server (para [0121]) in order for the proxy to figure out the leader database server and forward the request to the leader (Mankad; para [0128]).
Claims 11-13 are rejected under 35 U.S.C. 103 as being unpatentable over Sinha in view of Mankad, further in view of Padmanabhan et al. (US20150049632A1).
Regarding claim 11, Sinha-Mankad discloses the method of claim 10, wherein obtaining, by the proxy corresponding to the service of the application, an address of a middleware towards which the outbound request is to be routed comprises: obtaining, by the proxy corresponding to the service of the application, the address of the middleware (Mankad; Fig 6 and para [0121] show of FIG. 6 where multiple proxy are used, each of those proxy may be configured to route user requests to the leader database server; para [0056] shows the IP address of the database server).
Sinha-Mankad fails to teach:
obtaining, by the proxy corresponding to the service of the application, a version of the middleware based on the version of the service
However Padmanabhan, in an analogous art (para [0057] shows the network control system will be running both the old and new versions of the network control applications until the system can switch to the new version), discloses:
obtaining a version of the middleware based on the version of the service (para [0068] shows multiple versions of config database can exist on the forwarding elements at the same time; para [0111] shows the network controllers write to separate sets of tables in order to avoid conflicts that may arise when multiple controllers using different versions of the network control applications are writing to the same instance of a database. Controller 810 will write to a particular subset of tables 830 using a new version (v1) of the network control applications, while controller 815 will write to a separate different subset of tables 825 using a different version (v0) of the network control applications.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teaching of Sinha-Mankad with the teaching of Padmanabhan in order to avoid conflicts that may arise when multiple controllers using different versions of the network control applications are writing to the same instance of a database (Padmanabhan; para [0111]).
Regarding claim 12, Sinha-Mankad as applied to claim 10 fails to teach obtaining, by the proxy corresponding to the service of the application, a version of the middleware based on the version of the service comprises:
matching, by the proxy corresponding to the service of the application, the version of the service to the version of the middleware via a registry center,
the registry center indicating a version of each: service of the application and middleware of the application.
However Padmanabhan, in an analogous art (para [0057] shows the network control system will be running both the old and new versions of the network control applications until the system can switch to the new version), discloses:
obtaining, by the proxy corresponding to the service of the application, a version of the middleware based on the version of the service comprises (para [0068] shows multiple versions of config database can exist on the forwarding elements at the same time; para [0111] shows the network controllers write to separate sets of tables in order to avoid conflicts that may arise when multiple controllers using different versions of the network control applications are writing to the same instance of a database. Controller 810 will write to a particular subset of tables 830 using a new version (v1) of the network control applications, while controller 815 will write to a separate different subset of tables 825 using a different version (v0) of the network control applications):
matching, by the proxy corresponding to the service of the application, the version of the service to the version of the middleware via a registry center, the registry center indicating a version of each: service of the application and middleware of the application (para [0105] shows the version of the network control applications running on a controller and its associated flows is identified by a version bit. Each flow matches on a version bit associated with the packet (carried in a global register)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teaching of Sinha-Mankad with the teaching of Padmanabhan in order to avoid conflicts that may arise when multiple controllers using different versions of the network control applications are writing to the same instance of a database (Padmanabhan; para [0111]).
Regarding claim 13, Sinha-Mankad-Padmanabhan discloses the method of claim 12 further comprising:
receiving, by the proxy corresponding to the service of the application, a matching source label routing policy (Sinha; para [0057] shows policy engine to define or configure security, network traffic, network access), wherein:
matching, by the proxy corresponding to the service of the application, the version of the service to the version of the middleware comprises matching according to the matching source label routing policy (para [0105] shows the version of the network control applications running on a controller and its associated flows is identified by a version bit. Each flow matches on a version bit associated with the packet (carried in a global register)).
Citation of Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Lin et al. (CN114666397B) discloses on page 6 the so-called A/B test is performed by gradually introducing more traffic to the new version (e.g., receiving the request in the first lane from the second lane), and continuously adjusting the number of the running server copies of the new version and the old version during the process so that the new version can bear larger and larger traffic pressure. And switching 100% of traffic to the new version, and finally closing the rest old version service to finish gray level release. If a problem with the new version is found during the greyscale release process (greyscale period), the traffic should be switched back to the old version immediately, thus keeping the negative impact to a minimum.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TAN DOAN whose telephone number is (571)270-0162. The examiner can normally be reached Monday - Friday 8am - 5pm ET.
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, Oscar Louie, can be reached at (571) 270-1684. 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.
/TAN DOAN/Primary Examiner, Art Unit 2445