DETAILED ACTION
Claims 1-20 are presented for examination.
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 .
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
The claim 11 recites the limitations “obtaining data associated with one or more users indicative of interactions of the one or more users with an application programming interface” and “computing a score for the application programming interface based on at least a portion of the obtained data”. There recited steps, under the broadest reasonable interpretation, cover performance of the steps in the human mind, or by a human using pen and paper as a physical aid. For example, “obtaining data …” in the context of the claim encompasses a user making a manual look up at the data. Similarly, “computing a score for the API based on at least a portion of the obtain data” in the context of claim encompasses generating a score/metric, which is an evaluation that is practically capable of being performed in the human mind with the assistance of pen and paper.
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the human mind, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application because the claim recites the additional elements/limitations “an application programming interface configured to enable the one or more users to interact with an information processing system” and “wherein the computed score is indicative of a maturity level of the application programming interface”. These additional elements represent mere intended use of the data and generated score/metrics. Those limitations in the claim are thus insignificant extra information. These limitations are recited at a high-level of generality (e.g., “an application programming interface configured to enable the one or more users to interact with an information processing system”). Even when view in combination, these additional limitations/elements do not integrate the recited judicial exception into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does 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 limitations/elements do not impose any meaningful limits on practicing the abstract idea. Therefore, the additional limitations/elements cannot provide an inventive concept. The claim is not patent eligible.
Claims 12-18 are rejected under 35 USC 101 as non-statutory for at least the reasons stated above. The claims are dependent on claim 11, but do not add any feature or subject matter that would solve the non-statutory deficiencies of claim 11. For instance, claims 12-18 recites further mental steps and/or insignificant data/elements that fail to make the claims any less abstract and thus are not additional to the abstract idea. Claims 12-18 do not add any steps or elements, when considered both individually or as a combination, that would convert claim 11 into patent-eligible subject matter.
Claims 11-18 are therefore not drawn to patent-eligible subject matter as they are directed to an abstract idea without significantly more.
The claim 1 recites the limitations “obtain data associated with one or more users indicative of interactions of the one or more users with an application programming interface” and “compute a score for the application programming interface based on at least a portion of the obtained data”. There recited steps, under the broadest reasonable interpretation, cover performance of the steps in the human mind, or by a human using pen and paper as a physical aid. For example, “obtain data …” in the context of the claim encompasses a user making a manual look up at the data. Similarly, “compute a score for the API based on at least a portion of the obtain data” in the context of claim encompasses generating a score/metric, which is an evaluation that is practically capable of being performed in the human mind with the assistance of pen and paper.
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the human mind, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application because the claim recites the additional elements/limitations “an application programming interface configured to enable the one or more users to interact with an information processing system” and “wherein the computed score is indicative of a maturity level of the application programming interface”. These additional elements represent mere intended use of the data and generated score/metrics. Those limitations in the claim are thus insignificant extra information. Claim 1 further recites additional limitation/element “at least one processing platform comprising at least one processor coupled to at least one memory, the at least one processing platform, when executing program code” and “manage an application programming interface configured to enable one or more users to interact with an information processing system”. These limitations are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Even when view in combination, these additional limitations/elements do not integrate the recited judicial exception into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does 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 limitations/elements do not impose any meaningful limits on practicing the abstract idea and using a processor to perform the steps amounts to no more than mere instructions to apply the exception using a generic computer component. Therefore, the additional limitations/elements and mere instructions to apply the exception using a generic computer component cannot provide an inventive concept. The claim is not patent eligible.
Claims 2-10 are rejected under 35 USC 101 as non-statutory for at least the reasons stated above. The claims are dependent on claim 1, but do not add any feature or subject matter that would solve the non-statutory deficiencies of claim 1. For instance, claims 2-10 recite further mental steps and/or insignificant data/elements that fail to make the claims any less abstract and thus are not additional to the abstract idea. Claims 2-10 do not add any steps or elements, when considered both individually or as a combination, that would convert claim 1 into patent-eligible subject matter.
Claims 1-10 are therefore not drawn to patent-eligible subject matter as they are directed to an abstract idea without significantly more.
The claim 19 recites the limitations “obtain data associated with one or more users indicative of interactions of the one or more users with an application programming interface” and “compute a score for the application programming interface based on at least a portion of the obtained data”. There recited steps, under the broadest reasonable interpretation, cover performance of the steps in the human mind, or by a human using pen and paper as a physical aid. For example, “obtain data …” in the context of the claim encompasses a user making a manual look up at the data. Similarly, “compute a score for the API based on at least a portion of the obtain data” in the context of claim encompasses generating a score/metric, which is an evaluation that is practically capable of being performed in the human mind with the assistance of pen and paper.
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the human mind, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application because the claim recites the additional elements/limitations “an application programming interface configured to enable the one or more users to interact with an information processing system” and “wherein the computed score is indicative of a maturity level of the application programming interface”. These additional elements represent mere intended use of the data and generated score/metrics. Those limitations in the claim are thus insignificant extra information. Claim 19 further recites additional limitation/element “a non-transitory processor-readable storage medium having stored therein program code of one or more software programs, wherein the program code when executed by at least one processing platform” and “manage an application programming interface configured to enable one or more users to interact with an information processing system”. These limitations are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Even when view in combination, these additional limitations/elements do not integrate the recited judicial exception into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does 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 limitations/elements do not impose any meaningful limits on practicing the abstract idea and using a processor to perform the steps amounts to no more than mere instructions to apply the exception using a generic computer component. Therefore, the additional limitations/elements and mere instructions to apply the exception using a generic computer component cannot provide an inventive concept. The claim is not patent eligible.
Claim 20 is rejected under 35 USC 101 as non-statutory for at least the reasons stated above. The claim 20 depends on claim 19, but does not add any feature or subject matter that would solve the non-statutory deficiencies of claim 19. For instance, claim 20 recite further mental steps and/or insignificant data/elements that fail to make the claims any less abstract and thus are not additional to the abstract idea. Claim 20 does not add any steps or elements, when considered both individually or as a combination, that would convert claim 19 into patent-eligible subject matter.
Claims 19-20 are therefore not drawn to patent-eligible subject matter as they are directed to an abstract idea without significantly more.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 4-7 and 14-17 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 4 recites the limitation “a dynamic coefficient is computed for each of the one or more categories such that each dynamic coefficient contributes to the score indicative of the maturity level of the application programming interface.”. However, the claim fails to recite how the dynamic coefficient is computed and based on what data to compute.
Therefore, claim 4 is indefinite.
Claim 14 suffers the same problem as claim 4 above and therefore are also indefinite.
Claims 5-7 and 15-17 depend on claims 4 and 14, but fail to cure the deficiencies of claims 4 and 14, and therefore are also indefinite.
There’s no art rejection for claims 4-7 and 14-17. Examiner will reconsider the claims for rejection/allowance upon receive the response.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 11-13 and 18 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Overeem et al. (API-m-FAMM: A focus area maturity model for API management).
As to claim 11, Overeem teaches a method comprising:
obtaining data associated with one or more users indicative of interactions of the one or
more users with an application programming interface (The API-m-FAMM is evaluated with an embedded case study at the company the first and second author are employed at, and through case studies at four different companies. Data resulting from the application of the API-m-FAMM is collected through an Excel spreadsheet. Finally, participants evaluated the API-m-FAMM on the same criteria that were employed as part of the first evaluation cycle; page 8, right column, last paragraph – page 9, left column, first paragraph) configured to enable the one or more users to interact with an information processing system (The scope of the API-m-FAMM is the domain of API management: the API-m-FAMM aims to support organizations that expose their API(s) to third-party developers in their API management activities; page 6, right column, section 4, 4th paragraph); and
computing a score for the application programming interface based on at least a portion of the obtained data, wherein the computed score is indicative of a maturity level of the application programming interface (The rankings given by the experts in response to the questions corresponding to the four evaluation criteria, as well as their averages and standard deviation; see Table 5 and Fig. 5 and abstract).
As to claim 12, Overeem teaches wherein the data corresponds to factors in one or more categories of user interaction with the application programming interface such that, as data corresponding to one or more of the factors changes, the score indicative of the maturity level of the application programming interface changes (see Overeem: Table 5, scores for each category: Operational feasibility, Easy of user, Usefulness, Effectiveness).
As to claim 13, Overeem teaches wherein the one or more categories comprise a behavior category (see Overeem: Table 5, scores for each category: Easy of user, Usefulness) and a context category (see Overeem: Table 5, scores for each category: Operational feasibility, Effectiveness).
As to claim 18, Overeem teaches wherein the data corresponding to the factors in one or more categories of user interaction with the application programming interface is continuously obtained from feedback and error reporting by the one or more users (see Table 5, which shows data corresponding the factors are received from different users.).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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-3, 8-10 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Overeem et al. (API-m-FAMM: A focus area maturity model for API management) in view of Wang et al. (US 2021/0303454 A1).
As to claim 1, Overeem teaches an apparatus comprising:
manage an application programming interface configured to enable one or more users to
interact with an information processing system, wherein, when managing the application programming interface (The scope of the API-m-FAMM is the domain of API management:
the API-m-FAMM aims to support organizations that expose their API(s)
to third-party developers in their API management activities; page 6, right column, section 4, 4th paragraph), the at least one processing platform is further configured to:
obtain data associated with the one or more users indicative of interactions of the one or more users with the application programming interface (The API-m-FAMM is evaluated with an embedded case study at the company the first and second author are employed at, and through case studies at four different companies. Data resulting from the application of the API-m-FAMM is collected through an Excel spreadsheet. Finally, participants evaluated the API-m-FAMM on the same criteria that were employed as part of the first evaluation cycle; page 8, right column, last paragraph – page 9, left column, first paragraph); and
compute a score for the application programming interface based on at least a portion of the obtained data, wherein the computed score is indicative of a maturity level of the application programming interface (The rankings given by the experts in response to the questions corresponding to the four evaluation criteria, as well as their averages and standard deviation; see Table 5 and Fig. 5 and abstract).
Overeem does not teach at least one processing platform comprising at least one processor coupled to at least one memory.
Wang teaches at least one processing platform comprising at least one processor coupled to at least one memory (CPU, memory; paragraph [0051]) and a method for evaluating an API includes determining a specification score of the API by comparing a definition description for the API with a predetermined specification corresponding to the API. The specification score indicates a degree of matching between the definition description and the predetermined specification. Additionally, the method for evaluating an API includes determining a test score for the API by applying a predetermined test case set to a code set of the API. The test score indicates a test status for the code set. Further, the method for evaluating an API includes determining a maturity metric of the API based on the specification score and the test score (abstract).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the teaching of Wang to the system of Overeem because both are directed to the same endeavor, computing scores for API, the scores represent the maturity of the API, and Wang teaches a method, a device, and a computer program product for evaluating an application program interface (API).
As to claim 2, Overeem as modified by Wang teaches the apparatus of claim 1 wherein the data corresponds to factors in one or more categories of user interaction with the application programming interface such that, as data corresponding to one or more of the factors changes, the score indicative of the maturity level of the application programming interface changes (see Overeem: Table 5, scores for each category: Operational feasibility, Easy of user, Usefulness, Effectiveness).
As to claim 3, Overeem as modified by Wang teaches the apparatus of claim 2 wherein the one or more categories comprise a behavior category (see Overeem: Table 5, scores for each category: Easy of user, Usefulness) and a context category (see Overeem: Table 5, scores for each category: Operational feasibility, Effectiveness).
As to claim 8, Overeem as modified by Wang teaches the apparatus of claim 2 wherein the data corresponding to the factors in one or more categories of user interaction with the application programming interface is continuously obtained from feedback and error reporting by the one or more users (see Table 5, which shows data corresponding the factors are received from different users.).
As to claim 9, Overeem as modified by Wang teaches the apparatus of claim 1 wherein, when managing the application programming interface, the at least one processing platform is further configured to utilize the score to modify the application programming interface to reduce a burden on one or more computing resources associated with the information processing system (see Overeem: Throughout this work, the design, population, evaluation, and deployment of a focus area maturity model targeted towards the topic of API management has been described. The goal of this model as well as this work in general was to improve the transparency and availability of API management assessment frameworks and tools by constructing, evaluating and validating a publicly available, industry and academically grounded framework or tool that can be used by organizations that expose their API(s) to third-party developers to assess and evaluate their degree of maturity with regards to API management in order to improve upon their API management-related business processes. By constructing, evaluating, and publishing the API-m-FAMM we answered the research question posed in Section 3: How can organizations that expose their APIs to third parties evaluate their API management practices?. Aside from the main practical contributions the API-m-FAMM offers organizations in maturing their API management practices, this work provides the following scientific contributions; see page 14, section 9. Conclusion).
As to claim 10, Overeem as modified by Wang teaches the apparatus of claim 1 wherein the information processing system comprises a digital commerce system (see Overeem: ConsultComp; page 9, Exact, Uber; page 10).
As to claim 19, Overeem teaches:
manage an application programming interface configured to enable one or more users to
interact with an information processing system, wherein, when managing the application programming interface (The scope of the API-m-FAMM is the domain of API management:
the API-m-FAMM aims to support organizations that expose their API(s)
to third-party developers in their API management activities; page 6, right column, section 4, 4th paragraph), the at least one processing platform is further configured to:
obtain data associated with the one or more users indicative of interactions of the one or more users with the application programming interface (The API-m-FAMM is evaluated with an embedded case study at the company the first and second author are employed at, and through case studies at four different companies. Data resulting from the application of the API-m-FAMM is collected through an Excel spreadsheet. Finally, participants evaluated the API-m-FAMM on the same criteria that were employed as part of the first evaluation cycle; page 8, right column, last paragraph – page 9, left column, first paragraph); and
compute a score for the application programming interface based on at least a portion of the obtained data, wherein the computed score is indicative of a maturity level of the application programming interface (The rankings given by the experts in response to the questions corresponding to the four evaluation criteria, as well as their averages and standard deviation; see Table 5 and Fig. 5 and abstract).
Overeem does not teach a computer program product comprising a non-transitory processor-readable storage medium having stored therein program code of one or more software programs, the program code is executed by at least one processing platform.
Wang teaches a computer program product comprising a non-transitory processor-readable storage medium having stored therein program code of one or more software programs, the program code is executed by at least one processing platform (process 200 may be implemented as a computer software program or computer program product that is tangibly included in a machine-readable medium, for example, a non-transitory computer-readable medium such as storage unit 708. In some embodiments, some or all of the computer programs may be loaded and/or installed onto device 700 through ROM 702 and/or communication unit 709; paragraph [0053]) and a method for evaluating an API includes determining a specification score of the API by comparing a definition description for the API with a predetermined specification corresponding to the API. The specification score indicates a degree of matching between the definition description and the predetermined specification. Additionally, the method for evaluating an API includes determining a test score for the API by applying a predetermined test case set to a code set of the API. The test score indicates a test status for the code set. Further, the method for evaluating an API includes determining a maturity metric of the API based on the specification score and the test score (abstract).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the teaching of Wang to the system of Overeem because both are directed to the same endeavor, computing scores for API, the scores represent the maturity of the API, and Wang teaches a method, a device, and a computer program product for evaluating an application program interface (API).
As to claim 20, see rejection of claim 2 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Manzano et al. (US 11,281,462 B1) teaches rule-based scoring for APIs.
Sarkar (US 2025/0130870 A1) teaches optimizing application programming interface system scalability in a cloud environment by analyzing API calls data.
Dalui (API Maturity Model — Inspired byMartin Fowler) teaches a few essential measurements to build the pillar of the “API Maturity Model,” which you may refer to as guidelines part of your API adoption program. It helps to determine where you stand
today and the succeeding learning capabilities.
Xie et al. (CN 115718841 A) teaches a third party recommendation method based on overview neural network the method comprises the following steps: obtaining the user information, API information and interaction information and between the user and the API; constructing an isomeric diagram and a relational matrix between the user and the according to the obtained information; converting the user information and the information into a dense embedded vector matrix; converting the relationship matrix into user hypergraph and multiple hypergraph excavation co-occurrence relation; performing feature fusion to multiple hypergraphs to obtain the final hypergraph; based on the graph neural network learning the user feature vector and the feature vector of the semantic information; performing dot product calculation to the user feature vector and the feature vector to obtain the user preference degree of the, according to the ordering from high to low to the user for recommendation.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DIEM K CAO whose telephone number is (571)272-3760. The examiner can normally be reached Monday-Friday 8:00am-4:00pm.
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, April Blair can be reached at 571-270-1014. 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.
/DIEM K CAO/Primary Examiner, Art Unit 2196
DC
July 22, 2026
Prosecution Insights