DETAILED ACTION
Notice of Pre-AIA or AIA Status
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 communication filed on 03/02/2026. Claims 1-8,10-11,16-23,26-27 have been examined. Claims 9,12-15,24-25 are cancelled. Claims 26-27 are new.
Response to Argument
Applicant’s arguments with respect to claims 1,4, 20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
With regards to objection, Applicant’s amendment overcome the objection. Therefore, the objection is withdrawn.
With regards to 112 2nd rejection. Applicant’s amendment overcomes the rejection. Therefore, the rejection is withdrawn.
With regards to 101 rejection:
With regards to 101 rejection. Applicant amendment do not overcome the 101 rejection. Applicant relied on his argument is that the amended claims 1,4,20 integrate any alleged judicial exception into a practical application for at least the reasons that they include features that improve the functioning of a computer system – See Remarks – Page 11.
The examiner respectfully disagrees. For example , Claim 1 recites “ 1) receiving, from a consumer of service application programing interface (API), a request that indicates a service API analytics ; (2) collect , for the one or more service APIs , service API logs … ; (3) determine, based at least in part of the service API logs at least one service API analytics parameter; (4) transmit, to the consumer , the at least one service API analytics parameter.
The limitations of (3) determining , (4) transmitting as drafted are processes that under their broadest reasonable interpretation , cover performance of the limitations which can be practically performed in the human mind. These limitations encompass mental observation and evaluations ( e.g. computer programmer’s observing the data, making a determination and outputting the result (transmitting)). Thus, These limitations recite a concept that falls into the “mental process group” of abstract ideas.
The (1) receiving and (2) collecting limitations represent mere data gathering. These limitations do not impose any meaningful limits on the claims. The limitations amount to necessary data gathering.
This judicial exception is not integrated into a practical application. In particular, the claims 1 recite additional elements–“ a network node for wireless communication comprising at least one memory, and at least one processor coupled with the at least one memory”, “a consumer” . These additional elements are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer components. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-8,10-11,16-23, 27 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
The claims 1,4,20 recite “ (1) receiving, from a consumer of service application programing interface (API, a request for a service API analytics ; (2) collect, for the one or more service APIs, service API logs … ; (3) determine based at least in part on the service API logs , at least one service API analytics parameter; (4) transmit, to the consumer , the at least one service API analytics parameter.
The limitations of (3) determining , (4) transmitting as drafted are processes that under their broadest reasonable interpretation , cover performance of the limitations which can be practically performed in the human mind. These limitations encompass mental observation and evaluations ( e.g. computer programmer’s observing the data, making a determination (deriving) and outputting the result (transmitting)). Thus, These limitations recite a concept that falls into the “mental process group” , and “a method of organizing human activity group” of abstract ideas.
The (1) receiving and (2) collecting limitations represent mere data gathering. These limitations do not impose any meaningful limits on the claims. The limitations amount to necessary data gathering.
Therefore, the claims are directed to an abstract idea.
This judicial exception is not integrated into a practical application. In particular, the claims 1, 4, 20 recite additional elements–“ a network node for wireless communication comprising at least one memory, and at least one processor coupled with the at least one memory”, “a consumer” as recited in claim 1, “network node”, “consumer” as recited in claim 4, and “processor comprising at least one controller coupled with at least one memory” as recited in claim 20.
These additional elements are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer components.
Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claims are not patent eligible.
With regards to claims 2,5,21, the claims recite the limitation “wherein the request for the service analytics event comprises one or more of an application service profile,….” as drafted is a process defines what the received request comprises which represents mere data gathering. This limitation does not impose any meaningful limits on the claims. The limitation amounts to necessary data gathering.
This judicial exception is not integrated into a practical application. In particular, the claims do not recite additional element , The claims are directed to an abstract idea.
With regards to claims 3,6, the claims recite the limitation “wherein a collection of the service API logs is based at least in part on one or more of an application service profile…”represents mere data gathering. This limitation does not impose any meaningful limits on the claims. The limitation amounts to necessary data gathering.
This judicial exception is not integrated into a practical application. In particular, the claim does not recite additional element , The claims are directed to an abstract idea.
With regards to claims 7,16,22, the claims recite the limitation “wherein the consumer is one or more of third party application server … additional network node…”the claims define what the consumer is.
This judicial exception is not integrated into a practical application. In particular, the claims recite additional elements–“ wherein the consumer is one or more third party application server … additional network node”
The “consumer is one or more of third party application server, an application of a UE, an API invoker… additional network node” recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer components within a network.
Accordingly, this additional element does not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
With regards to claims 8,17,23, the claims recite the limitation “wherein to determine the at least one service API analytics parameter …predicting or prescribing an API future status …”. as drafted is a process that under their broadest reasonable interpretation , cover performance of the limitation which can be practically performed in the human mind. This limitation encompasses mental observation and evaluations ( e.g. computer programmer’s observing the data, making a determination (determining, predicting )). Thus, This limitation recites a concept that falls into the “mental process group” , and “a method of organizing human activity group” of abstract ideas.
This judicial exception is not integrated into a practical application. In particular, the claims 17, 23 recites additional elements– “processor” as recited in claim 17, and “ controller”, “a processor” as recited in claim 23.
These additional elements are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer components.
Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claims are not patent eligible.
With regards to claims 10,18,24, the claims recite the limitation “wherein the at least one service API analytics parameter is derived based on one or more historical API logs …”. as drafted is a process that under their broadest reasonable interpretation , cover performance of the limitation which can be practically performed in the human mind. This limitation encompasses mental observation and evaluations ( e.g. computer programmer’s observing the data, making a determination (deriving)). Thus, This limitation recites a concept that falls into the “mental process group” , and “a method of organizing human activity group” of abstract ideas.
This judicial exception is not integrated into a practical application. In particular, the claims do not recite additional element , The claims are directed to an abstract idea.
With regards to claims 11,19, the claims recite the limitation “ wherein the one or more service API comprises one or more a network exposure function (NEF)… a local UE API” . the claims define what the API service comprises.
This judicial exception is not integrated into a practical application. In particular, the claims recite additional elements–“ wherein a Service API comprises one or more a network exposure function (NEF)… a local UE API”
The service API is recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer components within a network.
Accordingly, this additional element does not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
With regards to claim 27, the claim recites the limitation” the type of service API information comprising..” . This limitation only defined the type of the service API information.
This judicial exception is not integrated into a practical application. In particular, the claims 1 recite additional elements–“ a network node for wireless communication comprising at least one memory, and at least one processor coupled with the at least one memory”, “a consumer” . These additional elements are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer components. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea
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- 8, 10-11, 16-23, 27 are rejected under 35 U.S.C. 103 as being unpatentable over Gilling et al. Publication No. US 2021/0044672 A1 ( Gilling hereinafter) in view of Witkop et al. Publication No. US 2016/0267153 A1 ( Witkop hereinafter).
Regarding claim 1,
Gilling teaches a network node for wireless communication (Fig.2, ¶ 0151), comprising:
at least one memory; and at least one processor coupled with the at least one memory and operable to cause the network node to: receive, from a consumer of a service application programming interface (API), a request that indicates a service API analytics event, (¶0043 - In operation, API users 120-122 generate API requests 410 to be received by API provider 110. These requests may include various API functions to obtain, post, or replace data within one or more data repositories maintained by API provider 110. For example, an API request may be used to obtain shipping estimates for a postal service provider to a specific destination. As the API requests are obtained by API provider 110, API provider 110 may further identify and provide API request information 411 to monitoring service 130 - ¶ 0035 - monitoring service 130 may be used to provide user behavioral API analytics that makes decisions based on the initial requests and/or the responses to the requests (together API request information - ¶ 0016 -As API requests 150 are obtained by API provider 110, API request information 152 is provided to or extracted by monitoring service 130. This API request information 152 includes at least header information for the API requests obtained from API users 120-122. In some implementations, monitoring service 130 may extract header portions of the packets from API users 120-122 and relevant API attributes for the request from the header. The API attributes may include a user identifier associated with the API request, the API function (API call identifier to a service, such as GET, POST, and the like) included in the request).
wherein the service API analytics event corresponds to a type of service API information and wherein the request comprising a requirement for service API information that indicate one or more service APIs (¶ 0027 - In other implementations, rather than automatically generating a summary, monitoring service 130 may generate a summary in response to a request from administrator 160. The request may indicate a time period of interest, an initial API function for a sequence of functions, or some other attribute related to trends identified by monitoring service 130 – ¶ 0032 - a user may request a graph of usage associated with an API function by the API users – ¶ 0070 - Once the request is identified, trend module 810 may identify data relevant to the request and generate a visual representation of the data. In some examples, the generation of the summary may include identifying API path trends that qualify based on the preferences provided by the administrator and generating a summary using the identified API trends. The summary may indicate a heatmap or list of API paths or sequences based on the usage rates of the various API functions, the summary may indicate one or more API functions that are identified as possible issues in the API, may identify trends in the API paths as a function of time, or may demonstrate some other information related to the API path trends).
collect, for the one or more service APIs, service API data from one or more API sources based at least in part on the service API analytics event (¶ 0043 - information about the amount of data provided in response to an API request may be used to identify one or more API users that are obtaining an unexpected amount of data or may be used to indicate the amount of data provided to an API user in relation to other API users – ¶ 0044 - Once API request information 411 is obtained by monitoring service 130, monitoring service 130 may perform extract operation 430 to extract the various attributes from the API request information – ¶ 0052 – obtaining (501) API request information associated with requests to an API provider by an API user, wherein the API request information corresponds to a first sample rate of requests to the API provider. Operation 500 further identifies (502) a classification for the API user).
determine based at least in part on the service API data, at least one service API analytics parameter corresponding to the type of the service API information (¶ 0055 - As depicted in operational scenario 600 monitoring service 630 may use extract operation 640 to extract attributes or information from API request samples 616, wherein the attributes may include an identifier for the API user associated with the requests, API function identifiers, timestamps, or some other information. As the information is extracted for API user 620, classify operation 642 may classify API user 620 based at least in part on the attributes or statistics derived from the attributes. the classification for a user may be based on user profile input and/or statistics derived from the attributes identified in the API sample requests. The statistics may include a total quantity of requests to the API provider, sequence trends in the API requests, a total time that the user has used API provider 610, a quantity of errors in the API requests from API user 620,; and
transmit, to the consumer, the at least one service API analytics parameter (¶ 0056 - monitoring service 630 may further generate summaries 650 that can be provided to an administrator associated with API provider 610 or API user 620. The summaries may include a variety of different information including statistics derived from API request samples 616, such as the total number of requests, the total number of errors, frequently used sequences of API functions, or some other information. Additionally, when communicated to an API user, the information may include suggestions based on the statistics. The suggestions may indicate new features, sequence of functions used by other users, possible corrections to identified errors, or some other information used to suggest changes to the usage associated with the API)
However, Gilling does not explicitly teach
collect, for the one or more service APIs, service API logs from one or more API sources based at least in part on the service API analytics event; determine based at least in part on the service API logs at least one service API analytics parameter
Witkop teaches
collect, for the one or more service APIs, service API logs from one or more API sources based at least in part on the service API analytics event (¶ 0048 – environmental cartridge screening 304 may be used to identify API references in several environments of the enterprise databases 170. The environmental cartridges may utilize search indices 308, such as the search indices shown in Table 1, in order to identify API references within network traffic 312, in application logs 316, in gateway logs 320 (logs kept in the API gateway 105 or other similar gateways, for example), or in existing registers/repositories separate from the registry/repository of the AIR component 140. After identifying references to APis within the different environments 312, 316, 320, 324, or other environments- ¶ 0022 - The API discovery component 155 may include computer program code to cause one or more CPUs associated with the API discovery component 155 to perform discovery functions. A simple web search may not be enough for service discovery. Service information may be kept in many different types of repositories such as: code, UDDI, WSDL, Domain Name System (DNS), logs as well as documents. To search all of this information many different tools may be utilized);
determine based at least in part on the service API logs at least one service API analytics parameter (¶ 0068 - The results from the assessment performed at block 230 may provide information which may be used by the API management component 165 to configure the API gateway 105 and the API store Monitoring and Analytics may be used to provide API usage statistics – ¶ 0036 -The AP assessment component 160 may store both versions of identified "duplicate" APis and then let the market decide which one should be deleted by performing analytics on the "duplicate APis to see which is used more often or has differentiating features ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Gilling to include the teachings of Witkop. The motivation for doing so is to allow the system to provide API usage statistics (Witkop – ¶ 0068).
Regarding claim 2,
Gilling further teaches
wherein the request for the service API analytics event comprises one or more of an application service profile, an application service requirement, an API identifier, an API type, a time horizon for the service API analytics event, an area of validity, or a reporting configuration ( ¶ 0027 - In other implementations, rather than automatically generating a summary, monitoring service 130 may generate a summary in response to a request from administrator 160. The request may indicate a time period of interest, an initial API function for a sequence of functions, or some other attribute related to trends identified by monitoring service 130 – ¶ 0032 - a user may request a graph of usage associated with an API function by the API users – ¶ 0070 - Once the request is identified, trend module 810 may identify data relevant to the request and generate a visual representation of the data. In some examples, the generation of the summary may include identifying API path trends that qualify based on the preferences provided by the administrator and generating a summary using the identified API trends. The summary may indicate a heatmap or list of API paths or sequences based on the usage rates of the various API functions, the summary may indicate one or more API functions that are identified as possible issues in the API, may identify trends in the API paths as a function of time, or may demonstrate some other information related to the API path trends).
Regarding claim 3,
Gilling does not explicitly teach
wherein a collection of the service API logs is based at least in part on one or more of an application service profile, an application service requirement, an API availability in an area of validity, permissions of the consumer, or exposure capabilities of an API producer of a target API
However, Witkop teaches
wherein a collection of the service API logs is based at least in part on one or more of an application service profile, an application service requirement, an API availability in an area of validity, permissions of the consumer, or exposure capabilities of an API producer of a target API(¶ 0048 – environmental cartridge screening 304 may be used to identify API references in several environments of the enterprise databases 170. The environmental cartridges may utilize search indices 308, such as the search indices shown in Table 1, in order to identify API references within network traffic 312, in application logs 316, in gateway logs 320 (logs kept in the API gateway 105 or other similar gateways, for example), or in existing registers/repositories separate from the registry/repository of the AIR component 140 – ¶ 0040 - The securitization information resulting from the assessments performed by the API assessment component 160 may be used by the API management component 165 to manage services. For example, service settings such as security roles, transformations and throttling parameters may be determined based on which groups were determined to require or be allowed access to specific Apis - The authentication/authorization module and the validation module may develop authorization rules based on the API usage statistics to determine whose requests are permitted. The authentication/authorization module and the validation module may provide access control granularity down to single-edit configuration changes to specific API services A-Z).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Gilling to include the teachings of Witkop. The motivation for doing so is to allow the system to provide API usage statistics (Witkop – ¶ 0068).
Regarding claim 4,
Gilling teaches a method performed by a network node, the method comprising:
receiving from a consumer of a service application programming interface (API), a request that indicates a service API analytics event, (¶ 0043 - In operation, API users 120-122 generate API requests 410 to be received by API provider 110. These requests may include various API functions to obtain, post, or replace data within one or more data repositories maintained by API provider 110. For example, an API request may be used to obtain shipping estimates for a postal service provider to a specific destination. As the API requests are obtained by API provider 110, API provider 110 may further identify and provide API request information 411 to monitoring service 130 - ¶ 0035 - monitoring service 130 may be used to provide user behavioral API analytics that makes decisions based on the initial requests and/or the responses to the requests (together API request information - ¶ 0016 -As API requests 150 are obtained by API provider 110, API request information 152 is provided to or extracted by monitoring service 130. This API request information 152 includes at least header information for the API requests obtained from API users 120-122. In some implementations, monitoring service 130 may extract header portions of the packets from API users 120-122 and relevant API attributes for the request from the header. The API attributes may include a user identifier associated with the API request, the API function (API call identifier to a service, such as GET, POST, and the like) included in the request).
wherein the service API analytics event corresponds to a type of service API information and wherein the request comprising a requirement for the service API information that indicate one or more service APIs (¶ 0027 - In other implementations, rather than automatically generating a summary, monitoring service 130 may generate a summary in response to a request from administrator 160. The request may indicate a time period of interest, an initial API function for a sequence of functions, or some other attribute related to trends identified by monitoring service 130 – ¶ 0032 - a user may request a graph of usage associated with an API function by the API users – ¶ 0070 - Once the request is identified, trend module 810 may identify data relevant to the request and generate a visual representation of the data. In some examples, the generation of the summary may include identifying API path trends that qualify based on the preferences provided by the administrator and generating a summary using the identified API trends. The summary may indicate a heatmap or list of API paths or sequences based on the usage rates of the various API functions, the summary may indicate one or more API functions that are identified as possible issues in the API, may identify trends in the API paths as a function of time, or may demonstrate some other information related to the API path trends).
collect, for the one or more service APIs, service API data from one or more API sources based at least in part on the service API analytics event (¶ 0043 - information about the amount of data provided in response to an API request may be used to identify one or more API users that are obtaining an unexpected amount of data or may be used to indicate the amount of data provided to an API user in relation to other API users – ¶ 0044 - Once API request information 411 is obtained by monitoring service 130, monitoring service 130 may perform extract operation 430 to extract the various attributes from the API request information – ¶ 0052 – obtaining (501) API request information associated with requests to an API provider by an API user, wherein the API request information corresponds to a first sample rate of requests to the API provider. Operation 500 further identifies (502) a classification for the API user).
determine based at least in part on the service API data, at least one service API analytics parameter corresponding to the type of the service API information (¶ 0055 - As depicted in operational scenario 600 monitoring service 630 may use extract operation 640 to extract attributes or information from API request samples 616, wherein the attributes may include an identifier for the API user associated with the requests, API function identifiers, timestamps, or some other information. As the information is extracted for API user 620, classify operation 642 may classify API user 620 based at least in part on the attributes or statistics derived from the attributes. the classification for a user may be based on user profile input and/or statistics derived from the attributes identified in the API sample requests. The statistics may include a total quantity of requests to the API provider, sequence trends in the API requests, a total time that the user has used API provider 610, a quantity of errors in the API requests from API user 620,; and
transmit, to the consumer, the at least one service API analytics parameter (¶ 0056 - monitoring service 630 may further generate summaries 650 that can be provided to an administrator associated with API provider 610 or API user 620. The summaries may include a variety of different information including statistics derived from API request samples 616, such as the total number of requests, the total number of errors, frequently used sequences of API functions, or some other information. Additionally, when communicated to an API user, the information may include suggestions based on the statistics. The suggestions may indicate new features, sequence of functions used by other users, possible corrections to identified errors, or some other information used to suggest changes to the usage associated with the API)
However, Gilling does not explicitly teach
collect, for the one or more service APIs, service API logs from one or more API sources based at least in part on the service API analytics event; determine based at least in part on the service API logs at least one service API analytics parameter
Witkop teaches
collect, for the one or more service APIs, service API logs from one or more API sources based at least in part on the service API analytics event (¶ 0048 – environmental cartridge screening 304 may be used to identify API references in several environments of the enterprise databases 170. The environmental cartridges may utilize search indices 308, such as the search indices shown in Table 1, in order to identify API references within network traffic 312, in application logs 316, in gateway logs 320 (logs kept in the API gateway 105 or other similar gateways, for example), or in existing registers/repositories separate from the registry/repository of the AIR component 140. After identifying references to APis within the different environments 312, 316, 320, 324, or other environments- ¶ 0022 - The API discovery component 155 may include computer program code to cause one or more CPUs associated with the API discovery component 155 to perform discovery functions. A simple web search may not be enough for service discovery. Service information may be kept in many
different types of repositories such as: code, UDDI, WSDL, Domain Name System (DNS), logs as well as documents. To search all of this information many different tools may be utilized);
determine based at least in part on the service API logs at least one service API analytics parameter (¶ 0068 - The results from the assessment performed at block 230 may provide information which may be used by the API management component 165 to configure the API gateway 105 and the API store Monitoring and Analytics may be used to provide API usage statistics – ¶ 0036 -The AP assessment component 160 may store both versions of identified "duplicate" APis and then let the market decide which one should be deleted by performing analytics on the "duplicate APis to see which is used more often or has differentiating features ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Gilling to include the teachings of Witkop. The motivation for doing so is to allow the system to provide API usage statistics (Witkop – ¶ 0068).
Regarding claim 5,
Gilling further teaches
wherein the request for the service API analytics event comprises one or more of an application service profile, an application service requirement, an API identifier, an API type, a time horizon for the service API analytics event, an area of validity, or a reporting configuration ( ¶ 0027 - In other implementations, rather than automatically generating a summary, monitoring service 130 may generate a summary in response to a request from administrator 160. The request may indicate a time period of interest, an initial API function for a sequence of functions, or some other attribute related to trends identified by monitoring service 130 – ¶ 0032 - a user may request a graph of usage associated with an API function by the API users – ¶ 0070 - Once the request is identified, trend module 810 may identify data relevant to the request and generate a visual representation of the data. In some examples, the generation of the summary may include identifying API path trends that qualify based on the preferences provided by the administrator and generating a summary using the identified API trends. The summary may indicate a heatmap or list of API paths or sequences based on the usage rates of the various API functions, the summary may indicate one or more API functions that are identified as possible issues in the API, may identify trends in the API paths as a function of time, or may demonstrate some other information related to the API path trends).
Regarding claim 6,
Gilling does not explicitly teach
wherein a collection of the service API logs is based at least in part on one or more of an application service profile, an application service requirement, an API availability in an area of validity, permissions of the consumer, or exposure capabilities of an API producer of a target API
However, Witkop teaches
wherein a collection of the service API logs is based at least in part on one or more of an application service profile, an application service requirement, an API availability in an area of validity, permissions of the consumer, or exposure capabilities of an API producer of a target API(¶ 0048 – environmental cartridge screening 304 may be used to identify API references in several environments of the enterprise databases 170. The environmental cartridges may utilize search indices 308, such as the search indices shown in Table 1, in order to identify API references within network traffic 312, in application logs 316, in gateway logs 320 (logs kept in the API gateway 105 or other similar gateways, for example), or in existing registers/repositories separate from the registry/repository of the AIR component 140 – ¶ 0040 - The securitization information resulting from the assessments performed by the API assessment component 160 may be used by theAPI management component 165 to manage services. For example, service settings such as security roles, transformations and throttling parameters may be determined based on which groups were determined to require or be allowed access to specific Apis - The authentication/authorization module and the validation module may develop authorization rules based on theAPI usage statistics to determine whose requests are permitted. The authentication/authorization module and the validation module may provide access control granularity down to single-edit configuration changes to specific API services A-Z).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Gilling to include the teachings of Witkop. The motivation for doing so is to allow the system to provide API usage statistics (Witkop – ¶ 0068).
Regarding claim 7,
Gilling further teaches
wherein the consumer is one or more of a third-party application server, an application of a user equipment (UE), an API invoker, an application function (AF), or an additional network node (¶ 0014 - API users 120-122 may correspond to individual users, service providers, such as other web services,
application providers, or some other user of a web APL In some implementations, API users may correspond to companies that register subscriptions or licenses to interact with API provider 110 – ¶ 0059 - API user 720 generates API requests
750 that are received by API gateway 712, which routes the requests for processing by API provider 710. The API requests may be used as part of a service that allows users to obtain, post, or provide some other interaction with a database, or may be used to implement a mobile application on an end user device - See Also ¶ 0074).
Regarding claim 8,
Gilling further teaches
wherein determining the at least one service API analytics parameter comprising predicting or prescribing an API future status based on the request (¶ 0057 - monitoring service 630 may identify a sequence of functions from a user that differs from traditional functions executed by other users of API provider 610. Consequently, monitoring service 630 may pause or block future API requests from the user until the issue is resolved. Additionally, monitoring service 630 may provide a notification to the API user and/or an administrator of API provider 610 indicating the suspicious activity and permitting the administrator to block the API user or permit the requests).
Regarding claim 10,
Gilling further teaches
wherein the at least one service API analytics parameter is derived based at least in part on one or more of historical API logs, or real-time API data corresponding to ongoing API invocations (¶ 0046 - In some implementations, the API path trends may be determined by comparing the sequences identified from API request information 411 to sequences that are expected from API users 120-122. The predicted sequences may be based on historical API requests to API provider 110, may be based on administrator defined sequences, or may be based on some other predictive sequence information – ¶ 0039 during a first time period, function 333 may be requested at a first rate in association with the sequence of API functions from function 322 and 327. However, during a second period, function 333 may be requested at a second rate. The monitoring service may compare the first rate and second rate to determine whether criteria are satisfied, and when satisfied may identify the function as a trend of interest that can be provided as part of a summary to an administrator.).
Regarding claim 11,
Gilling further teaches
wherein the one or more service APIs comprises one or more of a network exposure function (NEF) API, an operation administration and management (OAM) API, an enablement API, a mobile edge computing (MEC) API, a radio access network intelligent controller (RIC) API, a slice API, a client-server API, or a local UE API (¶ 0003 - The API requests may be used as part of a service that allows users to obtain, post, or provide some other interaction with a database, or may be used to implement a mobile application on an end user device – ¶ 0028 - monitoring service 130 may be capable of identifying requests associated with each API user and may further identify each session associated with each of the end users. To identify the user and session associated with each of the requests, the API provider may allocate a session ID, an API key, an authorization token, or some other identifier to the API users. For example, when an API user initiates a first API request with the API provider or registers with the API provider).
Regarding claim 16,
Gilling further teaches
wherein the consumer is one or more of a third-party application server, an application of a user equipment (UE), an API invoker, an application function (AF), or an additional network node (¶ 0014 - API users 120-122 may correspond to individual users, service providers, such as other web services,
application providers, or some other user of a web APL In some implementations, API users may correspond to companies that register subscriptions or licenses to interact with API provider 110 – ¶ 0059 - API user 720 generates API requests
750 that are received by API gateway 712, which routes the requests for processing by API provider 710. The API requests may be used as part of a service that allows users to obtain, post, or provide some other interaction with a database, or may be used to implement a mobile application on an end user device - See Also ¶ 0074).
Regarding claim 17,
Gilling further teaches
wherein, to determine the at least one service API analytics parameter, the at least one processor is operable to cause the network node to predict or prescribe an API future status based at least in part on the request (¶ 0057 - monitoring service 630 may identify a sequence of functions from a user that differs from traditional functions executed by other users of API provider 610. Consequently, monitoring service 630 may pause or block future API requests from the user until the issue is resolved. Additionally, monitoring service 630 may provide a notification to the API user and/or an administrator of API provider 610 indicating the suspicious activity and permitting the administrator to block the API user or permit the requests).
Regarding claim 18,
Gilling further teaches
wherein service API analytics are derived based on one or more of historical API logs, or real-time API data corresponding to ongoing API invocations (¶ (¶ 0046 - In some implementations, the API path trends may be determined by comparing the sequences identified from API request information 411 to sequences that are expected from API users 120-122. The predicted sequences may be based on historical API requests to API provider 110, may be based on administrator defined sequences, or may be based on some other predictive sequence information – ¶ 0039 during a first time period, function 333 may be requested at a first rate in association with the sequence of API functions from function 322 and 327. However, during a second period, function 333 may be requested at a second rate. The monitoring service may compare the first rate and second rate to determine whether criteria are satisfied, and when satisfied may identify the function as a trend of interest that can be provided as part of a summary to an administrator.).
Regarding claim 19,
Gilling further teaches
wherein the one or more service APs comprise one or more of a network exposure function (NEF) API, an operation administration and management (OAM) API, an enablement API, a mobile edge computing (MEC) API, a radio access network intelligent controller (RIC) API, a slice API, a client-server API, or a local UE API (¶ 0003 - The API requests may be used as part of a service that allows users to obtain, post, or provide some other interaction with a database, or may be used to implement a mobile application on an end user device – ¶ 0028 - monitoring service 130 may be capable of identifying requests associated with each API user and may further identify each session associated with each of the end users. To identify the user and session associated with each of the requests, the API provider may allocate a session ID, an API key, an authorization token, or some other identifier to the API users. For example, when an API user initiates a first API request with the API provider or registers with the API provider).
Regarding claim 20,
Gilling teaches a processor for wireless communication comprising:
at least one controller circuitry coupled with at least one memory and configured to cause the processor to: : receive, from a consumer of a service application programming interface (API), a request that indicates a service API analytics event, (¶ 0043 - In operation, API users 120-122 generate API requests 410 to be received by API provider 110. These requests may include various API functions to obtain, post, or replace data within one or more data repositories maintained by API provider 110. For example, an API request may be used to obtain shipping estimates for a postal service provider to a specific destination. As the API requests are obtained by API provider 110, API provider 110 may further identify and provide API request information 411 to monitoring service 130 - ¶ 0035 - monitoring service 130 may be used to provide user behavioral API analytics that makes decisions based on the initial requests and/or the responses to the requests (together API request information - ¶ 0016 -As API requests 150 are obtained by API provider 110, API request information 152 is provided to or extracted by monitoring service 130. This API request information 152 includes at least header information for the API requests obtained from API users 120-122. In some implementations, monitoring service 130 may extract header portions of the packets from API users 120-122 and relevant API attributes for the request from the header. The API attributes may include a user identifier associated with the API request, the API function (API call identifier to a service, such as GET, POST, and the like) included in the request).
wherein the service API analytics event corresponds to a type of service API information and wherein the request comprising a requirement for service API information that indicates one or more service APIs (¶ 0027 - In other implementations, rather than automatically generating a summary, monitoring service 130 may generate a summary in response to a request from administrator 160. The request may indicate a time period of interest, an initial API function for a sequence of functions, or some other attribute related to trends identified by monitoring service 130 – ¶ 0032 - a user may request a graph of usage associated with an API function by the API users – ¶ 0070 - Once the request is identified, trend module 810 may identify data relevant to the request and generate a visual representation of the data. In some examples, the generation of the summary may include identifying API path trends that qualify based on the preferences provided by the administrator and generating a summary using the identified API trends. The summary may indicate a heatmap or list of API paths or sequences based on the usage rates of the various API functions, the summary may indicate one or more API functions that are identified as possible issues in the API, may identify trends in the API paths as a function of time, or may demonstrate some other information related to the API path trends).
collect, for the one or more service APIs, service API data from one or more API sources based at least in part on the service API analytics event (¶ 0043 - information about the amount of data provided in response to an API request may be used to identify one or more API users that are obtaining an unexpected amount of data or may be used to indicate the amount of data provided to an API user in relation to other API users – ¶ 0044 - Once API request information 411 is obtained by monitoring service 130, monitoring service 130 may perform extract operation 430 to extract the various attributes from the API request information – ¶ 0052 – obtaining (501) API request information associated with requests to an API provider by an API user, wherein the API request information corresponds to a first sample rate of requests to the API provider. Operation 500 further identifies (502) a classification for the API user).
determine based at least in part on the service API data, at least one service API analytics parameter corresponding to the type of the service API information (¶ 0055 - As depicted in operational scenario 600 monitoring service 630 may use extract operation 640 to extract attributes or information from API request samples 616, wherein the attributes may include an identifier for the API user associated with the requests, API function identifiers, timestamps, or some other information. As the information is extracted for API user 620, classify operation 642 may classify API user 620 based at least in part on the attributes or statistics derived from the attributes. the classification for a user may be based on user profile input and/or statistics derived from the attributes identified in the API sample requests. The statistics may include a total quantity of requests to the API provider, sequence trends in the API requests, a total time that the user has used API provider 610, a quantity of errors in the API requests from API user 620,)and
transmit, to the consumer, the at least one service API analytics parameter (¶ 0056 - monitoring service 630 may further generate summaries 650 that can be provided to an administrator associated with API provider 610 or API user 620. The summaries may include a variety of different information including statistics derived from API request samples 616, such as the total number of requests, the total number of errors, frequently used sequences of API functions, or some other information. Additionally, when communicated to an API user, the information may include suggestions based on the statistics. The suggestions may indicate new features, sequence of functions used by other users, possible corrections to identified errors, or some other information used to suggest changes to the usage associated with the API)
However, Gilling does not explicitly teach
collect, for the one or more service APIs, service API logs from one or more API sources based at least in part on the service API analytics event; determine based at least in part on the service API logs at least one service API analytics ¶meter
Witkop teaches
collect, for the one or more service APIs, service API logs from one or more API sources based at least in part on the service API analytics event (¶ 0048 – environmental cartridge screening 304 may be used to identify API references in several environments of the enterprise databases 170. The environmental cartridges may utilize search indices 308, such as the search indices shown in Table 1, in order to identify API references within network traffic 312, in application logs 316, in gateway logs 320 (logs kept in the API gateway 105 or other similar gateways, for example), or in existing registers/repositories separate from the registry/repository of the AIR component 140. After identifying references to APis within the different environments 312, 316, 320, 324, or other environments- ¶ 0022 - The API discovery component 155 may include computer program code to cause one or more CPUs associated with the API discovery component 155 to perform discovery functions. A simple web search may not be enough for service discovery. Service information may be kept in many different types of repositories such as: code, UDDI, WSDL, Domain Name System (DNS), logs as well as documents. To search all of this information many different tools may be utilized);
determine based at least in part on the service API logs at least one service API analytics parameter (¶ 0068 - The results from the assessment performed at block 230 may provide information which may be used by the API management component 165 to configure the API gateway 105 and the API store Monitoring and Analytics may be used to provide API usage statistics – ¶ 0036 -The AP assessment component 160 may store both versions of identified "duplicate" APis and then let the market decide which one should be deleted by performing analytics on the "duplicate APis to see which is used more often or has differentiating features ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Gilling to include the teachings of Witkop. The motivation for doing so is to allow the system to provide API usage statistics (Witkop – ¶ 0068).
Regarding claim 21,
Gilling further teaches
wherein the request for the service API analytics event comprises one or more of an application service profile, an application service requirement, an API identifier, an API type, a time horizon for the service API analytics event, an area of validity, or a reporting configuration( ¶ 0027 - In other implementations, rather than automatically generating a summary, monitoring service 130 may generate a summary in response to a request from administrator 160. The request may indicate a time period of interest, an initial API function for a sequence of functions, or some other attribute related to trends identified by monitoring service 130 – ¶ 0032 - a user may request a graph of usage associated with an API function by the API users – ¶ 0070 - Once the request is identified, trend module 810 may identify data relevant to the request and generate a visual representation of the data. In some examples, the generation of the summary may include identifying API path trends that qualify based on the preferences provided by the administrator and generating a summary using the identified API trends. The summary may indicate a heatmap or list of API paths or sequences based on the usage rates of the various API functions, the summary may indicate one or more API functions that are identified as possible issues in the API, may identify trends in the API paths as a function of time, or may demonstrate some other information related to the API path trends).
Regarding claim 22,
Gilling further teaches
wherein the consumer is one or more of a third-party application server, an application of a user equipment (UE), an API invoker, an application function (AF), or an additional network node(¶ 0014 - API users 120-122 may correspond to individual users, service providers, such as other web services,
application providers, or some other user of a web APL In some implementations, API users may correspond to companies that register subscriptions or licenses to interact with API provider 110 – ¶ 0059 - API user 720 generates API requests
750 that are received by API gateway 712, which routes the requests for processing by API provider 710. The API requests may be used as part of a service that allows users to obtain, post, or provide some other interaction with a database, or may be used to implement a mobile application on an end user device - See Also ¶ 0074).
Regarding claim 23,
Gilling further teaches
wherein, to determine the at least one service API analytics parameter, the at least one controller circuitry is configured to cause the processor to predict or prescribe an API future status based on at least in part the request (¶ 0057 - monitoring service 630 may identify a sequence of functions from a user that differs from traditional functions executed by other users of API provider 610. Consequently, monitoring service 630 may pause or block future API requests from the user until the issue is resolved. Additionally, monitoring service 630 may provide a notification to the API user and/or an administrator of API provider 610 indicating the suspicious activity and permitting the administrator to block the API user or permit the requests).
Regarding claim 27,
Gilling further teaches
wherein the type of service API information comprises information characterizing the one or more service APIs, and wherein the information characterizing the one or more service APIs comprises one or more of an API availability, an API performance metric, an API usage statistic, an API invocation success rate, an API invocation failure rate, or an API invocation(¶ 0027 - In other implementations, rather than automatically generating a summary, monitoring service 130 may generate a summary in response to a request from administrator 160. The request may indicate a time period of interest, an initial API function for a sequence of functions, or some other attribute related to trends identified by monitoring service 130 – ¶ 0032 - a user may request a graph of usage associated with an API function by the API users – ¶ 0070 - Once the request is identified, trend module 810 may identify data relevant to the request and generate a visual representation of the data. In some examples, the generation of the summary may include identifying API path trends that qualify based on the preferences provided by the administrator and generating a summary using the identified API trends. The summary may indicate a heatmap or list of API paths or sequences based on the usage rates of the various API functions, the summary may indicate one or more API functions that are identified as possible issues in the API, may identify trends in the API paths as a function of time, or may demonstrate some other information related to the API path trends – ¶ 0019 - The trends may include the quantity of requests to API provider the types of requests to API provider, the sequence of requests to API provider or some other trend – See Also ¶ 0035, ¶ 0048).
Claim 26 is rejected under 35 U.S.C. 103 as being unpatentable over Gilling in view of Witkop further in view of GE et al. Publication No. US 2021/0119875 A1 (GE hereinafter).
Regarding claim 26,
Gilling does not explicitly teach
wherein the at least one processor is further operable to cause the network node to authorize, in response to receiving the request, the consumer to access the service API analytics event based at least in part on verifying one or more permissions associated with the consumer prior to collecting the service API logs.
However, GE teaches
wherein the at least one processor is further operable to cause the network node to authorize, in response to receiving the request, the consumer to access the service API analytics event based at least in part on verifying one or more permissions associated with the consumer prior to collecting the service API logs (¶ 0083 - The CAPIF-3 supports the following functions: supporting the API exposure function network element to authenticate the API invoker network element based on the identifier and the security credential of the API invoker network element; supporting the API exposure function network element to provide authorization for the API invoker network element before the API invoker network element accesses the API; supporting to perform authorization verification of the API exposure function network element when the API invoker network element accesses the API; supporting the API exposure function network element to control API access based on a policy configured by a PLMN operator; supporting the API exposure function network element to record logs of the API invoker; supporting the API exposure function network element to charge for the API invoker; and the like – ¶ 0085 -The CAPIF-5 supports the following functions: supporting the API management function network element to access logs of the API invoker; supporting the API management function network element to monitor an API invoker event; supporting the API invoker network element to configure information about the API invoker network element on the CCF, to support registration of the API invoker network element; supporting the API management function network element to configure the policy on the CCF – ¶ 0088 - authenticating the API invoker network element based on the API invoker network element identifier and other information provided by the CCF network element; acknowledging the authorization provided by the CCF network element; and synchronizing the API logs to the CCF -See ¶ 0079, ¶ 0111).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Gilling to include the teachings of GE. The motivation for doing so is to allow the system to determine a network slice corresponding to an application, so that an API invoker network element can accurately search the network slice corresponding to the application for an APL (GE – ¶ 0006).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YOUNES NAJI whose telephone number is (571)272-2659. The examiner can normally be reached Monday - Friday 8:30 AM -5: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, Oscar A 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.
/YOUNES NAJI/Primary Examiner, Art Unit 2445
Prosecution Insights