Detailed Action
Claims 1-20 are pending
Claims 1-4 and 7-12 are rejected.
Claims 5 and 13-14 are objected.
Claims 15-20 are allowed.
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 of this title, 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 before the effective filing date of the invention to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1 and 3-4 are rejected under 35 U.S.C. 103 as being unpatentable over Tsai et al (Pub. No.: US 2019/0149618 A1) in view of AZARIA et al (Pub. No.: US 2022/0350686 A1).
As per claim 1, Tsai discloses:
A method comprising: - obtaining access to a memory of a computing device allocated to a service (Tsai; abstract, par. [0011], wherein “provide the service endpoint information, from the memory, in response to the service request”); - identifying a route object within the memory, wherein the route object forwards individual requests to individual request handlers (Tsai; abstract, Fig 3, par. [0012, 0080], wherein “endpoint information may include at least one of: a Uniform Resource Locator (URL), a host name, or a port number”; The endpoint information can be the route object, “Both service A 601 and service B 602 invoke the same service endpoint C 603. Service discovery agent can assign different URLs of service endpoint C 603 into OS environment variable 604 and database 605 separately so that Service A 601 and Service B 602 can query the same endpoint through different URLs to achieve load balance with a round-robin mechanism or the like—which usually results in a fairly even distribution of queries across the different URLs for the same endpoint 603”). Tsai does not explicitly disclose - extracting a route pattern from the route object; - identifying an endpoint of the service from the route pattern; and - identifying a parameter of the endpoint from the route pattern.
However, Tsai already discloses a URL (which can represent a route pattern and can include a parameter) (see Tsai; abstract, Fig 3, par. [0012, 0080]) and thus it is well known in the art to parse the endpoint information to extract the URL to identify the endpoint of the service and the parameter associated with the endpoint service. To make the record clear, the examiner interduces AZARIA to disclose - extracting a route pattern from the route object; - identifying an endpoint of the service from the route pattern; and - identifying a parameter of the endpoint from the route pattern
(AZARIA, paragraph 0061, wherein “The parameter detection component 650 may then analyze URL paths included in the same group to determine whether they include a parameter. URL paths that include a parameter are often unique and thus tend to form larger groups, and thus it may be relatively straightforward to detect the parameters in larger groups. For example, the parameter detection component 650 may determine that the URL paths included in group 640A include a parameter and refer to the endpoint 660 of the web service represented by the URL path pattern “/api/vi/sites/{number}”. Groups from which an endpoint could not be extracted (e.g., smaller groups such as groups 640B and 640C) may be designated as leftover groups 670. Thus, the main component 600 may return extracted endpoints (e.g., endpoint 660D) and leftover groups (e.g., groups 640B and 640C)”).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of the invention to combine Tsai and AZARIA to achieve the claimed invention because this would have provided a way to improve the system performance and/or effectiveness by accurately discovering the endpoints of a web service (and particularly when the uniform resource locator (URL) paths have parameters) without manual intervention (see AZARIA par. 0030).
As per claim 3, claim 1 is incorporated and Tsai further discloses:
generating a specification that describes the service, wherein the specification includes a description of the endpoint and a description of the parameter (Tsai; abstract, Fig 3, par. [0012], wherein “endpoint information may include at least one of: a Uniform Resource Locator (URL), a host name, or a port number”).
As per claim 4, claim 1 is incorporated and Tsai further discloses:
identifying the service as one of a plurality of services running on a server device (Tsai; abstract, par. [0011], wherein “provide the service endpoint information, from the memory, in response to the service request”).
Claims 2 and 8-12 are rejected under 35 U.S.C. 103 as being unpatentable over Tsai et al (Pub. No.: US 2019/0149618 A1) in view of AZARIA et al (Pub. No.: US 2022/0350686 A1) and Karimibiuki et al (Pub. No.: US 2016/0119757 A1).
As per claim 2, claim 1 is incorporated and Tsai further discloses:
causing (Tsai; paragraph 0078, wherein “Service discovery agent 420 is decoupled from microservices 502 and applications 503, and the IoT Gateway administrator can remove service discovery agent 420 at any time, or manually change the storage values for testing or debugging without modifying any codes of microservices 502 and applications 503”). Tsai does not explicitly disclose a dynamic security scanner. However, Karimibiuki discloses a dynamic security scanner (Karimibiuki, paragraph 0033, wherein “Fuzz testing, also referred to as fuzzing, is a software testing technique which uses a fuzzer to find implementation bugs using injection of generated test data, such as malformed or semi-malformed data, in an automated fashion. A fuzzer is a computer program which automatically injects different data into a program/stack to detect software bugs. The injected data can be based on automated data generators, and vulnerability identification can rely on debugging tools. Data generators usually use combinations of static fuzzing vectors (e.g., known-to-be-dangerous values), generation or modification of test data according to patterns or rules, or random data. Some fuzzers may use genetic algorithms to link injected data and observed impact of the tested software (e.g., target software)”).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of the invention to combine Tsai, AZARIA and Karimibiuki to achieve the claimed invention because this would have provided a way to find implementation bugs using injection of generated test data, such as malformed or semi-malformed data, in an automated fashion.
As per claim 8, Tsai discloses:
A system comprising: a processing unit; and a computer-readable storage medium having computer-executable instructions stored thereupon, which, when executed by the processing unit, cause the processing unit to: - obtain access to a memory allocated to a web service (Tsai; abstract, par. [0011], wherein “provide the service endpoint information, from the memory, in response to the service request”); - identify a route object within the memory, wherein the route object forwards individual web requests to individual web request handlers (Tsai; abstract, Fig 3, par. [0012, 0080], wherein “endpoint information may include at least one of: a Uniform Resource Locator (URL), a host name, or a port number”; The endpoint information can be the route object, “Both service A 601 and service B 602 invoke the same service endpoint C 603. Service discovery agent can assign different URLs of service endpoint C 603 into OS environment variable 604 and database 605 separately so that Service A 601 and Service B 602 can query the same endpoint through different URLs to achieve load balance with a round-robin mechanism or the like—which usually results in a fairly even distribution of queries across the different URLs for the same endpoint 603”). Tsai does not explicitly disclose - extract a route pattern from the route object; - identify an endpoint of the web service from the route pattern; and - identify a parameter of the endpoint from the route pattern.
However, Tsai already discloses a URL (which can represent a route pattern and can include a parameter) (see Tsai; abstract, Fig 3, par. [0012, 0080]) and thus it is well known in the art to parse the endpoint information to extract the URL to identify the endpoint of the service and the parameter associated with the endpoint service. To make the record clear, the examiner interduces AZARIA to disclose - extract a route pattern from the route object; - identify an endpoint of the web service from the route pattern; and - identify a parameter of the endpoint from the route pattern
(AZARIA, paragraph 0061, wherein “The parameter detection component 650 may then analyze URL paths included in the same group to determine whether they include a parameter. URL paths that include a parameter are often unique and thus tend to form larger groups, and thus it may be relatively straightforward to detect the parameters in larger groups. For example, the parameter detection component 650 may determine that the URL paths included in group 640A include a parameter and refer to the endpoint 660 of the web service represented by the URL path pattern “/api/vi/sites/{number}”. Groups from which an endpoint could not be extracted (e.g., smaller groups such as groups 640B and 640C) may be designated as leftover groups 670. Thus, the main component 600 may return extracted endpoints (e.g., endpoint 660D) and leftover groups (e.g., groups 640B and 640C)”).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of the invention to combine Tsai and AZARIA to achieve the claimed invention because this would have provided a way to improve the system performance and/or effectiveness by accurately discovering the endpoints of a web service (and particularly when the uniform resource locator (URL) paths have parameters) without manual intervention (see AZARIA par. 0030).Tsai further discloses:
cause (Tsai; paragraph 0078, wherein “Service discovery agent 420 is decoupled from microservices 502 and applications 503, and the IoT Gateway administrator can remove service discovery agent 420 at any time, or manually change the storage values for testing or debugging without modifying any codes of microservices 502 and applications 503”). Tsai does not explicitly disclose a dynamic security scanner. However, Karimibiuki discloses a dynamic security scanner (Karimibiuki, paragraph 0033, wherein “Fuzz testing, also referred to as fuzzing, is a software testing technique which uses a fuzzer to find implementation bugs using injection of generated test data, such as malformed or semi-malformed data, in an automated fashion. A fuzzer is a computer program which automatically injects different data into a program/stack to detect software bugs. The injected data can be based on automated data generators, and vulnerability identification can rely on debugging tools. Data generators usually use combinations of static fuzzing vectors (e.g., known-to-be-dangerous values), generation or modification of test data according to patterns or rules, or random data. Some fuzzers may use genetic algorithms to link injected data and observed impact of the tested software (e.g., target software)”).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of the invention to combine Tsai, AZARIA and Karimibiuki to achieve the claimed invention because this would have provided a way to find implementation bugs using injection of generated test data, such as malformed or semi-malformed data, in an automated fashion.
As per claim 9, claim 8 is incorporated and Tsai further discloses:
wherein the computer-executable instructions cause the processing unit to: find a root object of the web service; enumerate descendent objects of the root object; and identify the route object as one of the descendent objects having a route object type (Tsai; Fig 4-6, par. [0012], wherein “The tree 310 conveys information regarding the distinct URL paths that have been seen in the web service requests and the counts (also referred to as “hits”) per distinct URL path (e.g., the number of web service requests having the URL path). The tree 310 includes a root node representing the web service. Each node stemming from the root node represents a URL part. Each layer of the tree 310 corresponds to a location within a URL path”).
As per claim 10, claim 9 is incorporated and Tsai further discloses:
wherein the identified route object is one of a plurality of route objects associated with the web service, and wherein a plurality of endpoints exposed by the web service are identified from one or more of the plurality of route objects (Tsai; Fig 4-6, par. [0012, 0061], wherein “The tree 310 conveys information regarding the distinct URL paths that have been seen in the web service requests and the counts (also referred to as “hits”) per distinct URL path (e.g., the number of web service requests having the URL path). The tree 310 includes a root node representing the web service. Each node stemming from the root node represents a URL part. Each layer of the tree 310 corresponds to a location within a URL path”, “The parameter detection component 650 may then analyze URL paths included in the same group to determine whether they include a parameter. URL paths that include a parameter are often unique and thus tend to form larger groups, and thus it may be relatively straightforward to detect the parameters in larger groups. For example, the parameter detection component 650 may determine that the URL paths included in group 640A include a parameter and refer to the endpoint 660 of the web service represented by the URL path pattern “/api/vi/sites/{number}. Groups from which an endpoint could not be extracted (e.g., smaller groups such as groups 640B and 640C) may be designated as leftover groups 670. Thus, the main component 600 may return extracted endpoints (e.g., endpoint 660D) and leftover groups (e.g., groups 640B and 640C)”).
As per claim 11, claim 10 is incorporated and Tsai further discloses:
generating a specification that describes the service, wherein the specification includes a description of the endpoint and a description of the parameter (Tsai; abstract, Fig 3, par. [0012], wherein “endpoint information may include at least one of: a Uniform Resource Locator (URL), a host name, or a port number”).
As per claim 12, claim 8 is incorporated and Tsai further discloses:
wherein the route pattern maps a path segment variable to a route handler variable, and wherein at least a portion of the endpoint of the web service comprises a name of one of a plurality of route handlers that are compatible with the route handler variable (Tsai; abstract, Fig 3, par. [0012], wherein “endpoint information may include at least one of: a Uniform Resource Locator (URL), a host name, or a port number”).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Tsai et al (Pub. No.: US 2019/0149618 A1) in view of AZARIA et al (Pub. No.: US 2022/0350686 A1) and FEIMAN et al (Pub. No.: US 2021/0084064 A1).
As per claim 6, claim 1 is incorporated and AZARIA further discloses:
- receiving, from a centralized orchestration server, a web service schema (AZARIA; par. [0059], wherein “The distance matrix calculator 620 may receive distinct URL paths 610 of incoming traffic to a web service (e.g., web service requests)”); - generating, on the computing device, an HTTP request derived from the web service schema, wherein the HTTP request includes a route path that includes one or more route path segments (AZARIA; par. [0031, 0034], wherein “As used herein, a URL part is a component within a URL path that is delimited by a predefined character such as a forward slash (‘/’). For example, for the URL “http://www.website.com/api/example/test”, “api”, “example”, and “test” are URL parts. As used herein, a parameter is a URL part that is expected to be variable. As used herein, an endpoint of a web service refers to an entry point of the web service that is associated with a particular functionality of the web service (e.g., an application programming interface (API) or web site). An endpoint may be represented using a URL or a URL pattern (e.g., if the endpoint includes a parameter)”, “The web service clients 110 may access a web service implemented by the web service server 130, for example, by generating one or more web server requests (e.g., Hypertext Transfer Protocol (HTTP) request messages such as a “POST” HTTP request messages or “GET” HTTP request messages) and sending these web service requests to the web service server 130. In response to receiving web service requests, the web service servers 130 may send corresponding web server responses (e.g., HTTP response messages) containing the data/content of the web service to the web service clients 110. Each of the web service clients 110 and the web service server 130 may be implemented by a network device”); providing the web service endpoint with the HTTP request over a logical network stack; receiving an HTTP response from the web service endpoint over the logical network stack (AZARIA; par. [0034], wherein “The web service clients 110 may access a web service implemented by the web service server 130, for example, by generating one or more web server requests (e.g., Hypertext Transfer Protocol (HTTP) request messages such as a “POST” HTTP request messages or “GET” HTTP request messages) and sending these web service requests to the web service server 130. In response to receiving web service requests, the web service servers 130 may send corresponding web server responses (e.g., HTTP response messages) containing the data/content of the web service to the web service clients 110. Each of the web service clients 110 and the web service server 130 may be implemented by a network device”).
Tsai and AZARIA do not explicitly disclose generating a security analysis of the web service endpoint based on the HTTP response. However, FEIMAN discloses generating a security analysis of the web service endpoint based on the HTTP response (FEIMAN, paragraph 0023, 0035, 0051, 0054 wherein “FIG. 1B shows another example intelligent and directed dynamic application security testing (ID-DAST) environment 100 employing API tracing as a source of intelligence for its testing”, “The neural network, once trained, can be used to analyze the results of attacks. For example, when an attack is performed (as discussed in FIGS. 1A and 1B) the attack (e.g., HTTP request) and the results of the attack (e.g., HTTP response) can be used as input into the trained neural network. The trained neural network can then determine if the attack resulted in a vulnerability, no vulnerability or a false positive”).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of the invention to combine Tsai, AZARIA and FEIMAN to achieve the claimed invention because this would have provided a way to perform intelligent and directed dynamic application security testing by determining specific attacks to perform in a condensed and efficient manner, improving the dynamic application security testing process, while removing the unnecessary aspects of the process (see FEIMAN, par. 0023-0024).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Tsai et al (Pub. No.: US 2019/0149618 A1) in view of AZARIA et al (Pub. No.: US 2022/0350686 A1) and Low et al (Pub. No.: US 2014/012321 A1).
As per claim 6, claim 1 is incorporated and Tsai and AZARIA do not explicitly disclose injecting an authorization hook between an authentication component and an authorization component of a request handler pipeline of the service, wherein the authorization hook: receives a request from the authentication component; determines that the request originated from a trustworthy source; and forwards the request to a component that follows the authorization component in the request handler pipeline. However, Low discloses injecting an authorization hook between an authentication component and an authorization component of a request handler pipeline of the service, wherein the authorization hook: receives a request from the authentication component; determines that the request originated from a trustworthy source; and forwards the request to a component that follows the authorization component in the request handler pipeline (Low, Fig 8, paragraph 0043 wherein “The authentication agent 415 interacts with the authentication/authorization server 404, which incorporates all of the desired authentication and/or authorization logic. As will be described, the server sends commands to the authentication agent 415 to acquire all required data from the user, the authentication mechanism or the host environment. In a preferred embodiment, the authentication agent 415 uses UI-hooking techniques to scrape requests originating from the authentication/authorization server 404, and to inject by auto-fill the responses to such requests into the application client UI for transmission back to the server 404”).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of the invention to combine Tsai, AZARIA and Low to achieve the claimed invention because this would have provided a way to improve the performance and efficiency of the system by allowing requests and their responses to be communicated by leveraging the existing support (see Low, par. 0043).
Allowable Subject Matter
Claims 5 and 13-14 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claims 15-20 are allowed.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAMZA N ALGIBHAH whose telephone number is (571)270-7212. The examiner can normally be reached 7:30 am - 3:30 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, Wing Chan can be reached on (571) 272-7493. 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.
/HAMZA N ALGIBHAH/ Primary Examiner, Art Unit 2441