DETAILED ACTION
Summary and Status of Claims
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to Applicant’s reply filed 3/16/2026.
Claims 1-5, 7-14, and 16-21 are pending.
Claims 1-5, 7-14, and 16-21 are rejected under 35 U.S.C. 103 as being unpatentable over Mittal et al. (US Patent 10,873,618), in view of Lester et al. (US Patent 10,747,505), further in view of Mantin et al. (US Patent 10,917,401).
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim Objections
Claims 1, 10, and 19 are objected to because of the following informalities:
In claims 1, 10, and 19, in the “in response to determining” limitation, “the number” should be “a number”.
Appropriate correction is required.
Note on Prior Art Rejections
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 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 § 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 to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-5, 7-14, and 16-21 are rejected under 35 U.S.C. 103 as being unpatentable over Mittal et al. (US Patent 10,873,618) (Mittal), in view of Lester et al. (US Patent 10,747,505), further in view of Mantin et al. (US Patent 10,917,401) (Mantin).
In regards to claim 1, Mittal discloses a method for naming application program interfaces (API)s from uniform resource locator (URL) information, comprising:
a. receiving intercepted requests and responses sent to one or more URL addresses related to a first server by a plurality of remote computing devices, wherein the requests and responses are intercepted by an agent installed on a second server (Mittal at col. 1, lines 19-21; col. 4, lines 15-21; col. 8, lines 53-66)1;
b. building a digital data structure based on analysis of the one or more URL addresses to which the requests and the responses are sent, the digital data structure including a single node for identical portions of the one or more URL addresses located at a same hierarchical position within the digital data structure (Mittal at Fig. 2; col. 7, lines 51-67; col. 8, lines 1-12)2 and including a separate node for different portions of the one or more URL addresses located at the same hierarchical position within the digital data structure (Mittal at Fig. 2; col. 7, lines 51-67; col. 8, lines 1-12)3, wherein each separate node is associated with a node type and a value (Mittal at Fig. 2; col. 7, lines 51-67; col. 8, lines 1-12)4;
c. determining a subset of nodes from a plurality of nodes which have a same hierarchical position and same node type, wherein the determination includes analyzing node types and values based a comparison strategy defined for specification analysis, wherein the node type includes one of a GUID type, integer type, and string type (Mittal at Fig. 1; col. 9, lines 63-67; col. 10, lines 1-5)5;
d. determining that the number of node sin the subset of nodes exceeds a threshold number (Mittal at col. 6, lines 11-14; col. 7, lines 9-16; col. 8, lines 36-40; col. 12, lines 2-7; col. 13, lines 9-23)6; and
e. naming an API by consolidating the matched nodes into a representative node and metadata derived from the URL hierarchy. Mittal at Fig. 1; col. 6, lines 11-14; col. 7, lines 9-16; col. 8, lines 36-40; col. 12, lines 2-7; col. 13, lines 9-23.7
Mittal does not expressly disclose determining a subset of nodes from a plurality of nodes which have a same hierarchical position, a same node type, and a different value. Note that Mittal discloses determining a plurality of nodes that have the same hierarchical position and same node type as set forth above.
Lester discloses a system and method for API specification generation. Lester discloses generating a tree data structure to identify variables of an API specification. The tree is built based on the resource path (i.e., URL address) of a request. Lester at Fig. 3; col. 7, lines 40-50. The system identifies nodes of the tree data structure to count a number of child nodes that directly descend from a parent node (i.e., same hierarchical position), having the same label (i.e., same node type) and different values. These identified nodes are designated as “variable” nodes if the number exceeds a threshold number. Lester at Fig. 3; col. 8, lines 25-67.
Mittal and Lester are analogous art because they are both directed to API endpoints.
At the time before the effective filing date of the instant application, it would have been obvious to one of ordinary skill in the art to modify Mittal by adding the feature of determining a subset of nodes from a plurality of nodes which have a same hierarchical position, a same node type, and a different value, as disclosed by Lester.
The motivation for doing so would have been to enable automated updating of API specifications based on API traffic. Lester at col. 2, lines 61-66.
Mittal in view of Lester does not expressly disclose in response to determining that the number of node sin the subset of nodes exceeds a threshold number, comparing specification data associated with each node of the determined subset of nodes, wherein the threshold number is pre-defined for the respective node type, wherein comparing specification data for each node of the subset of nodes includes determining whether a plurality of URL request specifications match and whether a plurality of URL response specifications match, and wherein determining if request specifications match includes determining if the request headers and request bodies match, and determining if response specifications match includes determining if the response headers and response bodies match, generating the name based at least in part on the compared specification data. It is noted that Lester does disclose analyzing the sets of API requests and responses to identify attributes within them. Lester at col. 3, lines 35-39.
Mantin discloses a system and method for preventing data leakage over an API. The system provides an application layer proxy that is deployed between the API clients and the API server in order to intercept and analyze the traffic sent between them (API requests and responses). Mantin at col. 5, lines 29-33. The proxy comprises a profiler component, which analyzes API requests and API responses. The profiler component aggregates key-value paths to generate a list of values associated with each key path. By doing so, the system is able to generate a profile for an API endpoint. For example, each API endpoint may correspond to a plurality of URLs. If multiple URLs (i.e., in response to the number of nodes in the subset exceeding a threshold) having similar API requests and similar API responses for those URLs in terms of their structure, data fields, and/or values (i.e., specification data), then the URLs are treated as a single API endpoint (i.e., comparing specification data for each node of the plurality of nodes … determining whether a plurality of URL request specifications match and whether a plurality of URL response specifications match … ; and generating an API based on the matching specifications, at least based on the comparison). Mantin at col. 7, lines 21-50. Since URL based APIs use HTTP, standard HTTP requests and responses utilize particular formats that include “header” information and optionally “body” data, depending on the type of request or response. However, same types of requests or responses would have a “header” and potentially a “body” for comparison. For example, POST requests would include a header and a body, whereas a GET request would include a header. Similarly, a response to a GET request would include a header and a body, while a response indicating an error may only include a header. Since Mantin discloses comparing specification data of responses and requests in terms of their “structure, data fields, and/or values” it is interpreted that the “headers” and “bodies” (if included in the request or response) are compared to determine a match. The system further provides a feature to pre-define a threshold for particular node types (i.e., wherein the threshold number is pre-defined for the respective node type), allowing the user to customize the system. Mantin at col. 12, lines 43-54.
Mittal, Lester, and Mantin are analogous art because they are both directed to the same field of endeavor of API end points.
At the time before the effective filing date of the instant application, it would have been obvious to one of ordinary skill in the art to modify Mittal in view of Lester by adding the features of in response to determining that the number of node sin the subset of nodes exceeds a threshold number, comparing specification data associated with each node of the determined subset of nodes, wherein the threshold number is pre-defined for the respective node type, wherein comparing specification data for each node of the subset of nodes includes determining whether a plurality of URL request specifications match and whether a plurality of URL response specifications match, and wherein determining if request specifications match includes determining if the request headers and request bodies match, and determining if response specifications match includes determining if the response headers and response bodies match, generating the name based at least in part on the compared specification data, as disclosed by Mantin.
The motivation for doing so would have been to provide more visibility of data flow through their API for security, insight, and policy enforcement. Mantin at col. 1, lines 50-57.
In regards to claim 2, Mittal in view of Lester and Mantin discloses the method of claim 1, wherein the specification data has the same format for each of the subset of nodes which have the same hierarchical position and same node type. Mittal at col. 7, lines 9-12.8
In regards to claim 3, Mittal in view of Lester and Mantin discloses the method of claim 1, wherein the specification data for the subset of nodes which have the same hierarchical position and the same node type includes a specification for a request sent to one or more URLs associated with the subset of nodes. Mittal at Fig. 2; col. 1, lines 19-21; col. 6, lines 11-44.9
In regards to claim 4, Mittal in view of Lester and Mantin discloses the method of claim 1, wherein the specification data for the subset of nodes which have the same hierarchical position and the same node type includes a specification for a response sent from one or more URLs associated with the subset of nodes. Mittal at Fig. 2; col. 1, lines 19-21; col. 6, lines 11-44.10
In regards to claim 5, Mittal in view of Lester and Mantin discloses the method of claim 1, wherein the digital data structure is a tree. Mittal at Fig. 2.11
In regards to claim 7, Mittal in view of Lester and Mantin discloses the method of claim 1, wherein the threshold number is greater than five nodes having a numerical value type. Mittal at col. 9, lines 63-67; col. 10, lines 1-2, 39-43.12
In regards to claim 8, Mittal in view of Lester and Mantin discloses the method of claim 1, wherein the threshold number is greater than 5 for nodes having a unique identifier type. Mittal at col. 2, lines 13-16; col. 9, lines 63-67; col. 10, lines 1-2. Mantin at col. 12, lines 43-50.13
In regards to claim 9, Mittal in view of Lester and Mantin discloses the method of claim 1, the building, comparing, and naming performed by an application on the first server in response to the agent transmitting the URL requests and responses to the application. Mittal at Fig. 3; col. 4, lines 15-24; col. 8, lines 53-57.14
In regards to claim 10, Mittal discloses a non-transitory computer readable storage medium having embodied thereon a program, the program being executable by a processor to perform a method (Mittal at col. 13, lines 39-47) for naming application program interfaces (APIs) from uniform resource locator (URL) information, the method comprising:
a. receiving intercepted requests and responses sent to one or more URL addresses related to a first server by a plurality of remote computing devices, wherein the requests and responses are intercepted by an agent installed on a second server (Mittal at col. 1, lines 19-21; col. 4, lines 15-21; col. 8, lines 53-66)15;
b. building a digital data structure based on analysis of the one or more URL addresses to which the requests and the responses are sent, the digital data structure including a single node for identical portions of the one or more URL addresses located at a same hierarchical position within the digital data structure (Mittal at Fig. 2; col. 7, lines 51-67; col. 8, lines 1-12)16 and including a separate node for different portions of the one or more URL addresses located at the same hierarchical position within the digital data structure (Mittal at Fig. 2; col. 7, lines 51-67; col. 8, lines 1-12)17, wherein each separate node is associated with a node type and a value (Mittal at Fig. 2; col. 7, lines 51-67; col. 8, lines 1-12)18;
c. determining a number of nodes from a subset of nodes in a plurality of nodes which have a same hierarchical position and same node type, wherein the determination includes analyzing node types and values based on a comparison strategy defined for specification analysis, wherein the node type includes one of a GUID type, integer type, and string type (Mittal at Fig. 1; col. 9, lines 63-67; col. 10, lines 1-5)19;
d. determining that the number of node sin the subset of nodes exceeds a threshold number (Mittal at col. 6, lines 11-14; col. 7, lines 9-16; col. 8, lines 36-40; col. 12, lines 2-7; col. 13, lines 9-23)20; and
e. naming an API by consolidating the matched nodes into a representative node, and metadata derived from the URL hierarchy. Mittal at Fig. 1; col. 6, lines 11-14; col. 7, lines 9-16; col. 8, lines 36-40; col. 12, lines 2-7; col. 13, lines 9-23.21
Mittal does not expressly disclose determining a subset of nodes from a plurality of nodes which have a same hierarchical position, a same node type, and a different value. Note that Mittal discloses determining a plurality of nodes that have the same hierarchical position and same node type as set forth above.
Lester discloses a system and method for API specification generation. Lester discloses generating a tree data structure to identify variables of an API specification. The tree is built based on the resource path (i.e., URL address) of a request. Lester at Fig. 3; col. 7, lines 40-50. The system identifies nodes of the tree data structure to count a number of child nodes that directly descend from a parent node (i.e., same hierarchical position), having the same label (i.e., same node type) and different values. These identified nodes are designated as “variable” nodes if the number exceeds a threshold number. Lester at Fig. 3; col. 8, lines 25-67.
Mittal and Lester are analogous art because they are both directed to API endpoints.
At the time before the effective filing date of the instant application, it would have been obvious to one of ordinary skill in the art to modify Mittal by adding the feature of determining a subset of nodes from a plurality of nodes which have a same hierarchical position, a same node type, and a different value, as disclosed by Lester.
The motivation for doing so would have been to enable automated updating of API specifications based on API traffic. Lester at col. 2, lines 61-66.
Mittal in view of Lester does not expressly disclose in response to determining that the number of node sin the subset of nodes exceeds a threshold number, comparing specification data associated with each node of the determined subset of nodes, wherein the threshold number is pre-defined for the respective node type, wherein comparing specification data for each node of the subset of nodes includes determining whether a plurality of URL request specifications match and whether a plurality of URL response specifications match, and wherein determining if request specifications match includes determining if the request headers and request bodies match, and determining if response specifications match includes determining if the response headers and response bodies match, generating the name based at least in part on the compared specification data. It is noted that Lester does disclose analyzing the sets of API requests and responses to identify attributes within them. Lester at col. 3, lines 35-39.
Mantin discloses a system and method for preventing data leakage over an API. The system provides an application layer proxy that is deployed between the API clients and the API server in order to intercept and analyze the traffic sent between them (API requests and responses). Mantin at col. 5, lines 29-33. The proxy comprises a profiler component, which analyzes API requests and API responses. The profiler component aggregates key-value paths to generate a list of values associated with each key path. By doing so, the system is able to generate a profile for an API endpoint. For example, each API endpoint may correspond to a plurality of URLs. If multiple URLs (i.e., in response to the number of nodes in the subset exceeding a threshold) having similar API requests and similar API responses for those URLs in terms of their structure, data fields, and/or values (i.e., specification data), then the URLs are treated as a single API endpoint (i.e., comparing specification data for each node of the plurality of nodes … determining whether a plurality of URL request specifications match and whether a plurality of URL response specifications match … ; and generating an API based on the matching specifications, at least based on the comparison). Mantin at col. 7, lines 21-50. Since URL based APIs use HTTP, standard HTTP requests and responses utilize particular formats that include “header” information and optionally “body” data, depending on the type of request or response. However, same types of requests or responses would have a “header” and potentially a “body” for comparison. For example, POST requests would include a header and a body, whereas a GET request would include a header. Similarly, a response to a GET request would include a header and a body, while a response indicating an error may only include a header. Since Mantin discloses comparing specification data of responses and requests in terms of their “structure, data fields, and/or values” it is interpreted that the “headers” and “bodies” (if included in the request or response) are compared to determine a match. The system further provides a feature to pre-define a threshold for particular node types (i.e., wherein the threshold number is pre-defined for the respective node type), allowing the user to customize the system. Mantin at col. 12, lines 43-54.
Mittal, Lester, and Mantin are analogous art because they are both directed to the same field of endeavor of API end points.
At the time before the effective filing date of the instant application, it would have been obvious to one of ordinary skill in the art to modify Mittal in view of Lester by adding the features of in response to determining that the number of node sin the subset of nodes exceeds a threshold number, comparing specification data associated with each node of the determined subset of nodes, wherein the threshold number is pre-defined for the respective node type, wherein comparing specification data for each node of the subset of nodes includes determining whether a plurality of URL request specifications match and whether a plurality of URL response specifications match, and wherein determining if request specifications match includes determining if the request headers and request bodies match, and determining if response specifications match includes determining if the response headers and response bodies match, generating the name based at least in part on the compared specification data, as disclosed by Mantin.
The motivation for doing so would have been to provide more visibility of data flow through their API for security, insight, and policy enforcement. Mantin at col. 1, lines 50-57.
Claims 11-14 and 16-18 are essentially the same as claims 2-5 and 7-9, respectively, in the form of a non-transitory computer readable storage medium. Therefore, they are rejected for the same reasons.
In regards to claim 19, Mittal discloses a system for naming application program interfaces (APIs) from uniform resource locator (URL) information, comprising:
a. a server including a memory and a processor (Mittal at col. 13, lines 29-47); and
b. one or more modules stored in the memory and executed by the processor (Mittal at col. 13, lines 49-67) to receive intercepted requests and responses sent to one or more URL addresses related to a first server by a plurality of remote computing devices, wherein the requests and responses are intercepted by an agent installed on a second server (Mittal at col. 1, lines 19-21; col. 4, lines 15-21; col. 8, lines 53-66)22; build a digital data structure based on analysis of the one or more URL addresses to which the requests and the responses are sent, the digital data structure including a single node for identical portions of the one or more URL addresses located at a same hierarchical position within the digital data structure (Mittal at Fig. 2; col. 7, lines 51-67; col. 8, lines 1-12)23 and including a separate node for different portions of the one or more URL addresses located at the same hierarchical position within the digital data structure (Mittal at Fig. 2; col. 7, lines 51-67; col. 8, lines 1-12)24, wherein each separate node is associated with a node type and a node value (Mittal at Fig. 2; col. 7, lines 51-67; col. 8, lines 1-12)25, determine number of nodes from a subset of nodes of a plurality of nodes which have a same hierarchical position and same node type, wherein the determination includes analyzing node types and node values based on a comparison strategy defined for specification analysis, wherein the node type includes one of a GUID type, integer type, and string type (Mittal at Fig. 1; col. 9, lines 63-67; col. 10, lines 1-5)26, determining that the number of node sin the subset of nodes exceeds a threshold number (Mittal at col. 6, lines 11-14; col. 7, lines 9-16; col. 8, lines 36-40; col. 12, lines 2-7; col. 13, lines 9-23)27, and name an API by consolidating the matched nodes into a representative node, and generating the name based at least in part on the compared specification data and metadata derived from the URL hierarchy. Mittal at Fig. 1; col. 6, lines 11-14; col. 7, lines 9-16; col. 8, lines 36-40; col. 12, lines 2-7; col. 13, lines 9-23.28
Mittal does not expressly disclose determining a subset of nodes from a plurality of nodes which have a same hierarchical position, a same node type, and a different value. Note that Mittal discloses determining a plurality of nodes that have the same hierarchical position and same node type as set forth above.
Lester discloses a system and method for API specification generation. Lester discloses generating a tree data structure to identify variables of an API specification. The tree is built based on the resource path (i.e., URL address) of a request. Lester at Fig. 3; col. 7, lines 40-50. The system identifies nodes of the tree data structure to count a number of child nodes that directly descend from a parent node (i.e., same hierarchical position), having the same label (i.e., same node type) and different values. These identified nodes are designated as “variable” nodes if the number exceeds a threshold number. Lester at Fig. 3; col. 8, lines 25-67.
Mittal and Lester are analogous art because they are both directed to API endpoints.
At the time before the effective filing date of the instant application, it would have been obvious to one of ordinary skill in the art to modify Mittal by adding the feature of determining a subset of nodes from a plurality of nodes which have a same hierarchical position, a same node type, and a different value, as disclosed by Lester.
The motivation for doing so would have been to enable automated updating of API specifications based on API traffic. Lester at col. 2, lines 61-66.
Mittal in view of Lester does not expressly disclose in response to determining that the number of node sin the subset of nodes exceeds a threshold number, comparing specification data associated with each node of the determined subset of nodes, wherein the threshold number is pre-defined for the respective node type, wherein comparing specification data for each node of the subset of nodes includes determining whether a plurality of URL request specifications match and whether a plurality of URL response specifications match, and wherein determining if request specifications match includes determining if the request headers and request bodies match, and determining if response specifications match includes determining if the response headers and response bodies match, generating the name based at least in part on the compared specification data. It is noted that Lester does disclose analyzing the sets of API requests and responses to identify attributes within them. Lester at col. 3, lines 35-39.
Mantin discloses a system and method for preventing data leakage over an API. The system provides an application layer proxy that is deployed between the API clients and the API server in order to intercept and analyze the traffic sent between them (API requests and responses). Mantin at col. 5, lines 29-33. The proxy comprises a profiler component, which analyzes API requests and API responses. The profiler component aggregates key-value paths to generate a list of values associated with each key path. By doing so, the system is able to generate a profile for an API endpoint. For example, each API endpoint may correspond to a plurality of URLs. If multiple URLs (i.e., in response to the number of nodes in the subset exceeding a threshold) having similar API requests and similar API responses for those URLs in terms of their structure, data fields, and/or values (i.e., specification data), then the URLs are treated as a single API endpoint (i.e., comparing specification data for each node of the plurality of nodes … determining whether a plurality of URL request specifications match and whether a plurality of URL response specifications match … ; and generating an API based on the matching specifications, at least based on the comparison). Mantin at col. 7, lines 21-50. Since URL based APIs use HTTP, standard HTTP requests and responses utilize particular formats that include “header” information and optionally “body” data, depending on the type of request or response. However, same types of requests or responses would have a “header” and potentially a “body” for comparison. For example, POST requests would include a header and a body, whereas a GET request would include a header. Similarly, a response to a GET request would include a header and a body, while a response indicating an error may only include a header. Since Mantin discloses comparing specification data of responses and requests in terms of their “structure, data fields, and/or values” it is interpreted that the “headers” and “bodies” (if included in the request or response) are compared to determine a match. The system further provides a feature to pre-define a threshold for particular node types (i.e., wherein the threshold number is pre-defined for the respective node type), allowing the user to customize the system. Mantin at col. 12, lines 43-54.
Mittal, Lester, and Mantin are analogous art because they are both directed to the same field of endeavor of API end points.
At the time before the effective filing date of the instant application, it would have been obvious to one of ordinary skill in the art to modify Mittal in view of Lester by adding the features of in response to determining that the number of node sin the subset of nodes exceeds a threshold number, comparing specification data associated with each node of the determined subset of nodes, wherein the threshold number is pre-defined for the respective node type, wherein comparing specification data for each node of the subset of nodes includes determining whether a plurality of URL request specifications match and whether a plurality of URL response specifications match, and wherein determining if request specifications match includes determining if the request headers and request bodies match, and determining if response specifications match includes determining if the response headers and response bodies match, generating the name based at least in part on the compared specification data, as disclosed by Mantin.
The motivation for doing so would have been to provide more visibility of data flow through their API for security, insight, and policy enforcement. Mantin at col. 1, lines 50-57.
In regards to claim 20. Mittal in view of Lester and Mantin discloses the system of claim 19, wherein the specification data has the same format for each of the two or more of the plurality of nodes which have the same hierarchical position and same value type. Mittal at col. 7, lines 9-12.29
In regards to claim 21, Mittal in view of Lester and Mantin discloses the method of claim 1, wherein the digital data structure is a trie structure. Mittal at Fig. 2.30
Response to Amendment
Objection to claims 7, 10, and 19 for Minor Informalities
Applicant’s amendment to claims 1, 10, and 19 to address the minor informalities is acknowledged. However, new minor informalities are noted above. Consequently, the objection to claim 7 is withdrawn.
Rejection of Claims 1-5, 7-14, and 16-21 under 35 U.S.C 112(b)
Applicant’s amendment to claims 1-5, 7-14, and 16-20 is acknowledged. The rejection to claims 1-5, 7-14, and 16-21 under 35 U.S.C. 112(b) is withdrawn.
Response to Arguments
Rejection of claims 1-5, 7-14, and 16-21 under 35 U.S.C. 103
Applicant’s arguments in regards to the rejections to claims 1-5, 7-14, and 16-21 under 35 U.S.C. 103, have been fully considered and they are not persuasive.
In regards to claim 1, Applicant’s arguments are against the references individually and does not address their combination. One cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
In regards to Mittal, Applicant alleges Mittal in view of Lester and Mantin does not disclose (1) “in response to determining that the number of nodes in the subset of nodes exceeds a threshold number, comparing specification data associated with each node of the determined subset of nodes” (Remarks at 9) and (2) “wherein determining of requests specifications match includes determining if the request headers and request bodies match, and determining if response specifications match includes determining if the response headers and response bodies match” Remarks at 9-10.
Examiner is required to give claim limitations their broadest reasonable interpretation in light of the specification. However, limitations from the specification are not read into the claims. MPEP 2111.
In regards to limitation (1), Applicant argues with respect to Mittal. Mittal does disclose determining a subset of nodes having a same hierarchical position and same node type. Mittal discloses determining nodes that share the same parent (i.e., same hierarchical position). Mittal at col. 9, lines 63-67; col. 10, lines 1-4. For example, “abcd” is the value of a node sharing the parent “user” as shown in Fig. 1 of Mittal, which can be interpreted as a string type. Contrary to Applicant’s allegation that Mittal any threshold is not to trigger comparison of specification data for each node of the determined subset (Remarks at 9), Mittal discloses of the number of nodes exceeds a MaxLimit then the node is determined to be dynamic. Mittal at col. 9, lines 63-67; col. 10, lines 1-2. Similarly, Lester discloses keeping a count of nodes to determine if the count meets or exceeds a threshold number, which indicates that the nodes represent a variable. Lester at col. 7, lines 65-67; col. 8, lines 1-12; col. 9, lines 1-15. As set forth in the modified rejection above in response to Applicant’s amendment, Mantin is relied upon for disclosing comparing specifications of nodes in the subset of nodes in response to the number of nodes in the subset of nodes exceeds a threshold. Mantin discloses a system and method for preventing data leakage over an API. The system provides an application layer proxy that is deployed between the API clients and the API server in order to intercept and analyze the traffic sent between them (API requests and responses). Mantin at col. 5, lines 29-33. The proxy comprises a profiler component, which analyzes API requests and API responses. The profiler component aggregates key-value paths to generate a list of values associated with each key path. By doing so, the system is able to generate a profile for an API endpoint. For example, each API endpoint may correspond to a plurality of URLs. If multiple URLs (i.e., nodes exceed a threshold) having similar API requests and similar API responses for those URLs in terms of their structure, data fields, and/or values (i.e., specification data), then the URLs are treated as a single API endpoint. Mantin at col. 7, lines 21-50. The system further provides a feature to pre-define a threshold for particular value/node types (i.e., wherein the threshold number is pre-defined for the respective node type), allowing the user to customize the system. Mantin at col. 12, lines 43-54. For at least these reasons, the cited prior art discloses limitation (1).
In regards to limitation (2), Applicant argues it is not disclosed by Mantin because Mantin teaches that “web APIs are defined by HTTP request messages together with response-message structure, usually in XML or JSON format, and that the endpoint profiles indicate the expected structure of API responses and the expected data types associated with the data fields in those responses.” Remarks at 9. Examiner respectfully disagrees. What Applicant is citing is Mantin discloses API responses contain a body (i.e., the response message structure). As noted, Mantin is discussing HTTP web APIs, which include headers. For example, Mantin discusses request messaging containing POST or GET, which are part of API request header “structure, data fields, and/or values). Applicant further argues that in context, Mantin’s analysis is within the API content and not of headers and bodies. Remarks at 10. As explained above, the cited portions discuss response bodies and Mantin discloses analysis of request header content (e.g., GET, POST). Accordingly, the comparison of “structured, data fields, and/or data values” includes comparison of headers and responses of API specifications.
Applicant does not present arguments with regards to the remaining limitations. Accordingly, Examiner asserts Mittal in view of Lester and Mantin discloses the limitations of claim 1. Applicant also does not present specific arguments with regards to the remaining claims. Therefore, Examiner asserts they remain rejected at least for the same reasons discussed above.
Consequently, the rejection of claims 1-5, 7-14, and 16-21 under 35 U.S.C 103 is maintained.
Additional Prior Art
Additional relevant prior art are listed on the attached PTO-892 form. Some examples are:
Treadway (US Patent 11,586,487) discloses a system and method for REST API route modeling by building a tree structure of a URL path.
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 extension fee 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 Examiner Michael Le whose telephone number is 571-272-7970 and fax number is 571-273-7970. The examiner can normally be reached Mon-Fri 9:30 AM – 6 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, Tony Mahmoudi can be reached on 571-272-4078. 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.
/MICHAEL LE/Examiner, Art Unit 2163
/ALEX GOFMAN/Primary Examiner, Art Unit 2163
1 A proxy intercepts transmissions to URLs at an application server from clients. The method can also be performed on a processor coupled to the proxy server (i.e., an agent installed on a second server).
2 Fig. 2 shows identical/common components of the URL are represented in a single node.
3 Differing components are in separate nodes. For example, column 206 shows different components each having their own node.
4 Node types as shown in Fig. 2 correspond to user ID, for example, which has a value (e.g., f5om89s) (i.e., GUID type or string type).
5 The number of nodes sharing the same parent node are counted (i.e., nodes having same hierarchical position and same node type). These nodes have the “same node type” as shown in Fig. 1 of Mittal where “abcd” is the value, which is a string type.
6 If number of nodes exceeds max limit (i.e., threshold) they are compared to determine whether they are similar enough to know if they should be collapsed into a smaller subtree (thereby included under the same API endpoint). If they are different, then they belong to different API endpoints.
7 If comparisons result in collapsing of URLs, until non-dynamic components remain. At this point a new API endpoint can be assigned, such as shown in Fig. 1. The naming is a result of a successful comparison and where utilizing the URL hierarchy to identify nodes (i.e., based at least in part on the compared specification data and metadata derived from the URL hierarchy).
8 Nodes have the same header in the format {URL, method}.
9 The format of the requests/responses are the same for nodes at the same position in the tree and have the same type. For example, in col. 6, the example discusses a unique ID node, which has a same type of unique ID and includes the same request header in the form of the same reddit URL components. Therefore, the nodes (in this example, the unique ID nodes) are in the same position include the header (comprising URL, method format), which includes the URL associated with the request/response associated with the node.
10 The format of the requests/responses are the same for nodes at the same position in the tree and have the same type. For example, in col. 6, the example discusses a unique ID node, which has a same type of unique ID and includes the same request header in the form of the same reddit URL components. Therefore, the nodes (in this example, the unique ID nodes) are in the same position include the header (comprising URL, method format), which includes the URL associated with the request/response associated with the node.
11 Fig. 2 shows a trie in table form.
12 Number of children from a selected parent node has to be greater than a maxlimit. Maxlimit is an exceptionally high number (i.e., threshold greater than 5 nodes). In the example shown, the components “1234” and “5678” are interpreted as numerical node type. Therefore, the nodes created by those components are numerical node type.
13 Number of children from a selected parent node (i.e., number of nodes having same hierarchical position), when greater than a max limit (i.e., threshold greater than 5 nodes) are compared in order to determine whether they should be collapsed and assigned to an API endpoint (i.e., new name). In the example disclosed, the component of the URL (i.e., node type) is for a unique identifier. Therefore, it is interpreted as a unique identifier type. Mantin also discloses data types (i.e., node types) of social security number, which can be interpreted as a unique identifier type.
14 The system shows clients communicating with application servers through a proxy server (i.e., agent). As disclosed in col. 4, the logic that performs the building, comparing, and generating can be located separate from the proxy server. This separate server is interpreted as an application at a second server, which performs the building, comparing, and generating in response to the proxy server (i.e., agent) sending it the captured data.
15 A proxy intercepts transmissions to URLs at an application server from clients. The method can also be performed on a processor coupled to the proxy server (i.e., an agent installed on a second server).
16 Fig. 2 shows identical/common components of the URL are represented in a single node.
17 Differing components are in separate nodes. For example, column 206 shows different components each having their own node.
18 Node types as shown in Fig. 2 correspond to user ID, for example, which has a value (e.g., f5om89s) (i.e., GUID type or string type).
19 The number of nodes sharing the same parent node are counted (i.e., nodes having same hierarchical position and same node type). These nodes have the “same node type” as shown in Fig. 1 of Mittal where “abcd” is the value, which is a string type.
20 If number of nodes exceeds max limit (i.e., threshold) they are compared to determine whether they are similar enough to know if they should be collapsed into a smaller subtree (thereby included under the same API endpoint). If they are different, then they belong to different API endpoints.
21 If comparisons result in collapsing of URLs, until non-dynamic components remain. At this point a new API endpoint can be assigned, such as shown in Fig. 1. The naming is a result of a successful comparison and where utilizing the URL hierarchy to identify nodes (i.e., based at least in part on the compared specification data and metadata derived from the URL hierarchy).
22 A proxy intercepts transmissions to URLs at an application server from clients. The method can also be performed on a processor coupled to the proxy server (i.e., an agent installed on a second server).
23 Fig. 2 shows identical/common components of the URL are represented in a single node.
24 Differing components are in separate nodes. For example, column 206 shows different components each having their own node.
25 Node types as shown in Fig. 2 correspond to user ID, for example, which has a value (e.g., f5om89s) (i.e., GUID type or string type).
26 The number of nodes sharing the same parent node are counted (i.e., nodes having same hierarchical position and same node type). These nodes have the “same node type” as shown in Fig. 1 of Mittal where “abcd” is the value, which is a string type.
27 If number of nodes exceeds max limit (i.e., threshold) they are compared to determine whether they are similar enough to know if they should be collapsed into a smaller subtree (thereby included under the same API endpoint). If they are different, then they belong to different API endpoints.
28 If comparisons result in collapsing of URLs, until non-dynamic components remain. At this point a new API endpoint can be assigned, such as shown in Fig. 1. The naming is a result of a successful comparison and where utilizing the URL hierarchy to identify nodes (i.e., based at least in part on the compared specification data and metadata derived from the URL hierarchy).
29 Nodes have the same header in the format {URL, method}.
30 Fig. 2 shows a trie in table form.
Prosecution Insights