DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. In response to the Office action mailed on 5/8/2025, the applicants have filed a response: claims 1 – 3, 9 – 11 and 16 - 18 have been amended. Claims 1 – 7, 8 – 14 and 16 - 20 are pending.
Claim Rejections - 35 USC § 101
3. 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.
4. Claims 1 – 7, 9 – 14 and 16 - 20 are directed to an abstract idea without significantly more. Independent claim 1 recites a computer-implemented method for grading an application programming interface (API) specification comprising: receiving, with at least one processor, the API specification; automatically grading, with at least one processor, the API specification using a plurality of rules by: parsing, with at least one processor, the API specification into a plurality of segments; and for each rule of the plurality of rules, extracting, with at least one processor, at least one segment of the plurality of segments corresponding to the rule from the API specification and applying, with at least one processor, the rule to the at least one segment to determine compliance data for the at least one segment with the rule; based on the compliance data, automatically identifying, with at least one processor, at least one violation of at least one rule of the plurality of rules occurring in the API specification; generating, with at least one processor, a report for the API specification based on the at least one violation of the at least one rule, wherein the report comprises data associated with the at least one violation of the at least one rule and at least one score; co-displaying, with at least one processor, the report and the API specification on a user interface comprising at least one user selectable interactive feature configured to facilitate remediation of the at least one violation, the report displayed on a first portion of the user interface and the API specification displayed on a second portion of the user interface; receiving, with at least one processor, a first user input by user interaction with a first feature of the at least one user selectable interactive feature arranged in the first portion of the user interface and corresponding to a first violation of the at least one violation contained in the report; in response to receiving the first user input, emphasizing, with at least one processor, a corresponding portion of the API specification displayed on the second portion of the user interface, the corresponding portion of the API specification corresponding to a portion of the API specification that contains the first violation; remediating, with at least one processor, the emphasized corresponding portion of the API specification that contains the first violation to form a remediated API specification; in response to remediating the emphasized corresponding portion of the API specification that contains the first violation, automatically updating, with the at least one processor, the report to form a second report based on the remediated API specification; and co-displaying, with at least one processor, the second report and the remediated API specification on the user interface comprising the second report displayed on the first portion of the user interface and the remediated API specification displayed on the second portion of the user interface.
The limitations, as drafted, describe a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components. The abstract idea limitations are
“automatically grading … the API specification using a plurality of rules by: parsing … the API specification into a plurality of segments; and for each rule of the plurality of rules, extracting … at least one segment of the plurality of segments corresponding to the rule from the API specification and applying … the rule to the at least one segment to determine compliance data for the at least one segment with the rule” “based on the compliance data, automatically identifying … at least one violation of at least one rule of the plurality of rules occurring in the API specification” and “generating … a report for the API specification based on the at least one violation of the at least one rule, wherein the report comprises data associated with the at least one violation of the at least one rule and at least one score” in Prong I step 2A. Other limitations including “receiving, with at least one processor, an API specification” and “co-displaying, with at least one processor, the report and the API specification on a user interface comprising at least one user selectable interactive feature configured to facilitate remediation of the at least one violation,” “receiving, …, a first user input by user interaction with a first feature of the at least one user selectable interactive feature arranged in the first portion of the user interface …,” “in response to receiving the first user input, emphasizing, …, a corresponding portion of the API specification displayed on the second portion of the user interface …,” “remediating, …, the emphasized corresponding portion of the API specification that contains the first violation to form a remediated API specification,” “in response to remediating the emphasized corresponding portion of the API specification that contains the first violation, automatically updating, …, the report to form a second report based on the remediated API specification” and “co-displaying, …, the second report and the remediated API specification on the user interface comprising the second report displayed on the first portion of the user interface and the remediated API specification displayed on the second portion of the user interface” are considered as extra-activity solutions for gathering information which are insignificant and outputting information regarding the events is merely an applied application and insignificantly amounts to the judicial exception. Thus, these claims are directed to an abstract idea under 35 USC 101.
That is, other than reciting “receiving, … , an API specification …” “… with the at least one processor …” and “displaying, … , the report on a user interface …” nothing in the claim elements preclude the steps from practically being performed in the mind such that the “automatically grading …,” “based on the compliance data, automatically identifying … “ and “generating, … , a report for the API specification …” limitations are mental processes under Prong I of step 2A. Generation and displaying of report on a user interface as described in the specification can be performed as a manual process. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claims recite an abstract idea.
This judicial exception is not integrated into a practical application. In particular, the components in the generate step are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function of receiving information, executing a function and making a decision) such that it amounts no more than mere instructions to apply the exception using a generic computer component.
Additionally, the steps of “receiving, … , an API specification …” and “displaying, … , the report on a user interface …” are pre/post-activity solutions as gathering data that are insignificant under Prong II step 2A and 2B. See buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network) as noted in MPEP 2106.05(d)(II)(i). Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does 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 element of using a computer to perform the noted steps amounts 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.
Independent claims 9 and 16 are rejected on the same basis as independent claim 1. Additionally, dependent claims 2 – 7, 10 – 14 and 17 - 20 are similarly rejected as being directed to an abstract idea since these claims are either further detailing the abstract idea by analyzing/processing the data or the elements are insignificant. More specifically, the dependent claims do not include additional elements, alone or in combination, that are sufficient to amount to significantly more than the judicial exception.
As per claims 2, 10 and 17, wherein remediating the emphasized corresponding portion of the API specification that contains the first violation comprises automatically modifying the API specification to correct the first violation (abstract idea under mental process under Prong I step 2A); and
generating the second report, wherein the second report comprises at least one second score (abstract idea under mental process under Prong I step 2A).
As per claims 3, 11 and 18, wherein the at least one user selectable interactive feature is a selectable link corresponding to the at least one segment of the plurality of segments, the method further comprising:
receiving a selection of the selectable link from a user (additional element under Prong II step 2A);
displaying the at least one segment of the plurality of segments comprising the at least one violation of the at least one rule (additional element under Prong II step 2A); and
providing at least one recommendation to modify the at least one segment to correct the at least one violation of the at least one rule (abstract idea under mental process under Prong I step 2A).
As per claims 4, 12 and 19, generating the at least one score based on a number of unique violations and a number of the plurality of rules, wherein each rule of the plurality of rules has a corresponding weight (abstract idea under mental process under Prong I step 2A).
As per claims 5, 13 and 20, determining whether to allow or deny publication of the API specification based on the at least one score and a threshold value (abstract idea under mental process under Prong I step 2A).
As per claims 6, 14 and 20, further comprising:
comparing the at least one score to the threshold value (abstract idea under mental process under Prong I step 2A);
determining that the at least one score does not satisfy the threshold value (abstract idea under mental process under Prong I step 2A); and
denying publication of the API specification based on determining that the at least one score does not satisfy the threshold value (abstract idea under mental process under Prong I step 2A).
As per claims 7, 14 and 20, further comprising:
comparing the at least one score to the threshold value (abstract idea under mental process under Prong I step 2A);
determining the at least one score satisfies the threshold value (abstract idea under mental process under Prong I step 2A); and
automatically publishing the API specification based on determining the at least one score satisfies the threshold value (abstract idea under mental process under Prong I step 2A).
Claim Rejections - 35 USC § 103
5. 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.
6. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
7. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
8. Claims 1, 2, 5, 9, 10, 13, 16 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Lowe et al. (U.S. Publication 2018/0314622) (Lowe hereinafter) in view of Bahrami et al. (U.S. Publication 2020/0364044) (Bahrami hereinafter) and Vyas et al. (U.S. Publication 2021/0216,308) (Vyas hereinafter).
9. As per claim 1, Lowe teaches a computer-implemented method for grading an application programming interface (API) specification comprising:
receiving, with at least one processor, the API specification [“FIG. 1 illustrates a schematic diagram of an API Validator Tool, according to an exemplary embodiment. An embodiment of the present invention is directed to measuring the quality and/or maturity of an API based on a specification for the API and a set of standards for the API. As shown in FIG. 1, an API Specification 120 may be received by API Validator Tool 110, which then analyzes the API Specification 120 as compared to API Standards 130.” ¶ 0025];
automatically grading, with at least one processor, the API specification using a plurality of rules by:
parsing, with at least one processor, the API specification into a plurality of segments [“The Tool may parse the specification and determine compliance (or non-compliance) with the standards, using specialized algorithms. Engine 142 may execute the algorithms to perform various functions including: checking URL endpoints defined in the supplied swagger file are constructed based on nouns, not verbs; checking the correct HTTP response codes are declared per operation type (e.g., GET, PUT, POST, DELETE, PATCH, etc.),” ¶ 0028; standards mapped to rules, various functions mapped to segments]; and
for each rule of the plurality of rules, extracting, with at least one processor, at least one segment of the plurality of segments corresponding to the rule from the API specification and applying, with at least one processor, the rule to the at least one segment to determine compliance data for the at least one segment with the rule [“API Standards 130 may represent a set of standards for the API which may include API Convention, API Design, API Security, API Data, etc. For example, API Standards may be in various formats, including various models (e.g., maturity models) to grade API according to the constraints of REST. The standards may include a set of guidelines and rules, directed to various functions including convention,” ¶ 0027];
based on the compliance data, automatically identifying, with at least one processor, at least one violation of at least one rule of the plurality of rules occurring in the API specification [“At step 214, an engine may determine compliance or non-compliance to the API standard. For example, the engine may apply a set of checks against the content to determine compliance to the standards,” ¶ 0030];
generating, with at least one processor, a report for the API specification based on the at least one violation of the at least one rule, wherein the report comprises data associated with the at least one violation of the at least one rule and at least one score [“At step 216, the engine may generate a score, grade, rating or other indicia in response. At step 218, the results may be provided via a user interface, report and/or other form of communication,” ¶ 0030].
Lowe does not explicitly disclose but Bahrami discloses co-displaying, with at least one processor, the report and the API specification on a user interface comprising at least one user selectable interactive feature configured to facilitate remediation of the at least one violation, the report displayed on a first portion of the user interface and the API specification displayed on a second portion of the user interface [“the specification viewer module 107 may display the entire consolidated API specification in the same window as the selection buttons 339 and the Tree View 337. In other embodiments, the specification viewer module 107 may display the entire consolidated API specification in a different window from the selection buttons 339 and the Tree View 337. In addition, the specification viewer module 107 may display each of the API objects in the consolidated API specification formatted according to the style configurations.” ¶ 0054; “Referring to FIG. 4A, an illustrated screen shot 400a illustrates the GUI displaying an example consolidated API specification in a different window from the selection buttons 339 and the Tree View 337. The example consolidated API specification may include invalid information 442 and valid information 440,” ¶ 0055; display of valid and invalid information suggests a validation report];
receiving, with at least one processor, a first user input by user interaction with a first feature of the at least one user selectable interactive feature arranged in the first portion of the user interface and corresponding to a first violation of the at least one violation contained in the report [“the GUI driver 108 may be configured to receive user input indicative of annotations to be made to the consolidated API specification. For example, the user may select API objects from the Tree View 337 and may annotate text that is associated with the API objects (e.g., the user may add text, remove text, or both to text that is associated with the API objects) via the GUI displayed on the display screen,” ¶ 0056; selection of API objects from a tree view mapped to selectable link; “Referring to FIG. 4A, an illustrated screen shot 400a illustrates the GUI displaying an example consolidated API specification in a different window from the selection buttons 339 and the Tree View 337. The example consolidated API specification may include invalid information 442 and valid information 440,” ¶ 0055; display of valid and invalid information suggests a violation]; and
in response to receiving the first user input, emphasizing, with at least one processor, a corresponding portion of the API specification displayed on the second portion of the user interface, the corresponding portion of the API specification corresponding to a portion of the API specification that contains the first violation [“the display file may cause the API objects of the consolidated API specification to be displayed via the GUI on the display screen 112 according to the style configurations. For example, if the style file indicates that API objects of a first API object type (e.g., a first API definition) are to be displayed with yellow highlighting, any API object in the consolidated API specification may be displayed via the GUI on the display screen 112 with associated text highlighted yellow. Therefore, the display file may permit the user to view and annotate the information contained within the consolidated API specification via the GUI displayed on the display screen,” ¶ 0050].
It would have been obvious to one of ordinary skill in the art, having the teachings of Lowe and Bahrami available before the effective filing date of the claimed invention, to modify the capability of API validation as disclosed by Lowe to include the capability of API specification display and modification as taught by Bahrami, thereby providing a mechanism to enhance system integrity by providing an interactive mechanism to visualize API interface details.
Lowe and Bahrami do not explicitly disclose but Vyas discloses remediating, with at least one processor, the emphasized corresponding portion of the API specification that contains the first violation to form a remediated API specification [“process 500 may include receiving a new API to be implemented in the multiple systems; processing the new API and the API specifications, with the machine learning model, to identify issues with the new API; correcting the issues with the new API to generate a corrected new API; and performing one or more actions based on the corrected new API,” ¶ 0098; issue correction mapped to remediation];
in response to remediating the emphasized corresponding portion of the API specification that contains the first violation, automatically updating, with the at least one processor, the report to form a second report based on the remediated API specification; and co-displaying, with at least one processor, the second report and the remediated API specification on the user interface comprising the second report displayed on the first portion of the user interface and the remediated API specification displayed on the second portion of the user interface [“the specification platform (e.g., via the machine learning model) may correct the system level set of API specifications, based on the system level differences, to generate a corrected system level set of API specifications. In some implementations, prior to correcting the system level set of API specifications based on the differences, the specification platform may provide, for display, the differences in the set of API specifications, and may request approval to correct the system level set of API specifications,” ¶ 0028].
It would have been obvious to one of ordinary skill in the art, having the teachings of Lowe, Bahrami and Vyas available before the effective filing date of the claimed invention, to modify the capability of API validation as disclosed by Lowe and Bahrami to include the capability of identification and correcting differences in API specifications as taught by Vyas, thereby providing a mechanism to enhance system integrity and operability by providing a mechanism to provide API interface detail consistency.
10. As per claim 2, Lowe, Bahrami and Vyas teach the computer-implemented method of claim 1. Lowe further teaches wherein remediating the emphasized corresponding portion of the API specification that contains the first violation comprises generating the second report, wherein the second report comprises at least one second score [“At step 216, the engine may generate a score, grade, rating or other indicia in response. At step 218, the results may be provided via a user interface, report and/or other form of communication,” ¶ 0030].
Lowe does not explicitly disclose but Bahrami discloses automatically modifying the API specification to correct the first violation [“The “Export JSON” button may be configured to be selected by the user to save annotations that have been made to the example consolidated API specification,” ¶ 0052; “Referring to FIG. 4A, an illustrated screen shot 400a illustrates the GUI displaying an example consolidated API specification in a different window from the selection buttons 339 and the Tree View 337. The example consolidated API specification may include invalid information 442 and valid information 440,” ¶ 0055; display of valid and invalid information suggests a violation].
It would have been obvious to one of ordinary skill in the art, having the teachings of Lowe and Bahrami available before the effective filing date of the claimed invention, to modify the capability of API validation as disclosed by Lowe to include the capability of API specification display and modification as taught by Bahrami, thereby providing a mechanism to enhance system integrity by providing an interactive mechanism to visualize API interface details.
11. As per claim 5, Lowe, Bahrami and Vyas teach the computer-implemented method of claim 1. Lowe further teaches determining whether to allow or deny publication of the API specification based on the at least one score and a threshold value [“API Validator 452 may check an API score for an API Specification with the ability to fail a build if an unsatisfactory score was achieved. API Validator 452 may indicate whether a build passes or fails,” ¶ 0037].
12. As per claim 9, it is a system claim having similar limitations as cited in claim 1. Thus, claim 9 is also rejected under the same rationale as cited in the rejection of claim 1 above.
13. As per claim 10, it is a system claim having similar limitations as cited in claim 2. Thus, claim 10 is also rejected under the same rationale as cited in the rejection of claim 2 above.
14. As per claim 13, it is a system claim having similar limitations as cited in claim 5. Thus, claim 13 is also rejected under the same rationale as cited in the rejection of claim 5 above.
15. As per claim 16, it is a media claim having similar limitations as cited in claim 1. Thus, claim 16 is also rejected under the same rationale as cited in the rejection of claim 1 above.
16. As per claim 17, it is a media claim having similar limitations as cited in claim 2. Thus, claim 17 is also rejected under the same rationale as cited in the rejection of claim 2 above.
17. Claims 3, 6, 11 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Lowe, Bahrami and Vyas in further view of Krebs et al. (U.S. Patent 11,977,860) (Krebs hereinafter).
18. As per claim 3, Lowe, Bahrami and Vyas teach the computer-implemented method of claim 1. Lowe further teaches providing at least one recommendation to modify the at least one segment to correct the at least one violation of the at least one rule [“For URI Design Validator, APIs may typically have two base URIs per resource: one for acting on single instances, and the other for acting on collections of that resource. Resources should be named as nouns as opposed to verbs or actions. In order to query hierarchical and related resources, APIs should have a defined set of collections, sub - collections and items. For example, URI Design Validator may provide validation errors, such as “The word 'post' in token/post is not recommended as this should be implied by the verb 'POST' — please use nouns in the URI, " and validation messages, such as “Below are the paths that were found that show GOOD design,” ¶ 0053].
Bahrami further teaches wherein the at least user selectable one interactive feature is a selectable link corresponding to the at least one segment of the plurality of segments, the method further comprising: receiving a selection of the selectable link from a user [“the GUI driver 108 may be configured to receive user input indicative of annotations to be made to the consolidated API specification. For example, the user may select API objects from the Tree View 337 and may annotate text that is associated with the API objects (e.g., the user may add text, remove text, or both to text that is associated with the API objects) via the GUI displayed on the display screen,” ¶ 0056; selection of API objects from a tree view mapped to selectable link].
It would have been obvious to one of ordinary skill in the art, having the teachings of Lowe and Bahrami available before the effective filing date of the claimed invention, to modify the capability of API validation as disclosed by Lowe to include the capability of API specification display and modification as taught by Bahrami, thereby providing a mechanism to enhance system integrity by providing an interactive mechanism to visualize API interface details.
Lowe, Bahrami and Vyas do not explicitly disclose but Krebs discloses displaying the at least one segment of the plurality of segments comprising the at least one violation of the at least one rule [“in response to identifying the non-compliance, display an RPA file report on a graphical user interface (GUI) that comprises one or more subsets of the RPA file that do not comply with the particular rules, and a prompt to remove the one or more subsets of the RPA file that do not comply with the particular rules,” cl. 1].
It would have been obvious to one of ordinary skill in the art, having the teachings of Lowe, Bahrami, Vyas and Krebs available before the effective filing date of the claimed invention, to modify the capability of API validation as disclosed by Lowe, Bahrami and Vyas to include the capability of remediation of non-compliance in software systems as taught by Krebs, thereby providing a mechanism to enhance system operability by providing a user-based mechanism to address non-compliance instances.
19. As per claim 6, Lowe, Bahrami and Vyas teach the computer-implemented method of claim 5. Lowe further teaches comparing the at least one score to the threshold value; and determining that the at least one score does not satisfy the threshold value [“API Validator 452 may check an API score for an API Specification with the ability to fail a build if an unsatisfactory score was achieved. API Validator 452 may indicate whether a build passes or fails,” ¶ 0037].
Lowe, Bahrami and Vyas do not explicitly disclose but Krebs discloses denying publication of the API specification based on determining that the at least one score does not satisfy the threshold value [“in response to identifying the non-compliance, display an RPA file report on a graphical user interface (GUI) that comprises one or more subsets of the RPA file that do not comply with the particular rules, and a prompt to remove the one or more subsets of the RPA file that do not comply with the particular rules,” cl. 1].
It would have been obvious to one of ordinary skill in the art, having the teachings of Lowe, Bahrami, Vyas and Krebs available before the effective filing date of the claimed invention, to modify the capability of API validation as disclosed by Lowe, Bahrami and Vyas to include the capability of remediation of non-compliance in software systems as taught by Krebs, thereby providing a mechanism to enhance system operability by providing a user-based mechanism to address non-compliance instances.
20. As per claim 11, it is a system claim having similar limitations as cited in claim 3. Thus, claim 11 is also rejected under the same rationale as cited in the rejection of claim 3 above.
21. As per claim 18, it is a media claim having similar limitations as cited in claim 3. Thus, claim 18 is also rejected under the same rationale as cited in the rejection of claim 3 above.
22. Claims 4, 12 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Lowe, Bahrami and Vyas in further view of Lowe et al. (U.S. Publication 2023/0333917) (Lowe ‘917 hereinafter).
23. As per claim 4, Lowe, Bahrami and Vyas teach the computer-implemented method of claim 1. Lowe, Bahrami and Vyas do not explicitly disclose but Lowe ‘917 discloses further comprising generating the at least one score based on a number of unique violations and a number of the plurality of rules, wherein each rule of the plurality of rules has a corresponding weight [“The scores may be aggregated to calculate an overall score for the data schema, and each score for each determined data schema in the API specification may be further aggregated to calculate an overall score for the API specification. Data models, elements, and sub-properties can also be assigned weights such that non-compliance with heavily weighted models, elements and sub-properties tend to lower an API specification's overall score, and vice versa.” ¶ 0035].
It would have been obvious to one of ordinary skill in the art, having the teachings of Lowe, Bahrami, Vyas and Lowe ‘917 available before the effective filing date of the claimed invention, to modify the capability of API validation as disclosed by Lowe, Bahrami and Vyas to include the capability of API scoring as taught by Lowe ‘917, thereby providing a mechanism to enhance system integrity by providing a mechanism to enforce quality standards using weighted evaluation models.
24. As per claim 12, it is a system claim having similar limitations as cited in claim 4. Thus, claim 12 is also rejected under the same rationale as cited in the rejection of claim 4 above.
25. As per claim 19, it is a media claim having similar limitations as cited in claim 4. Thus, claim 19 is also rejected under the same rationale as cited in the rejection of claim 4 above.
26. Claims 7, 14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Lowe, Bahrami and Vyas in further view of Manzano et al. (U.S. Patent 11,281,462) (Manzano hereinafter).
27. As per claim 7, Lowe, Bahrami and Vyas teach the computer-implemented method of claim 5. Lowe further teaches comparing the at least one score to the threshold value; and determining the at least one score satisfies the threshold value [“API Validator 452 may check an API score for an API Specification with the ability to fail a build if an unsatisfactory score was achieved. API Validator 452 may indicate whether a build passes or fails,” ¶ 0037].
Lowe, Bahrami and Vyas do not explicitly disclose but Manzano discloses automatically publishing the API specification based on determining the at least one score satisfies the threshold value [“the rules for scoring an API may be applied to API 112 as it is coded (e.g., in real-time, or upon request) to the API developer. This allows the API developer to modify API 112 to ensure compliance (e.g., a minimum score) with that particular rule set. In addition, API exchange platform 108 may provide additional controls to require an API developer to meet certain minimum score requirements (for a given rule set) before the API 112 can be published to API exchange platform 108 and available to application developers—regardless of the application developer's own (possibly separate) rule-based scores for the API 112,” col. 3, line 66 – col. 4, line 9].
It would have been obvious to one of ordinary skill in the art, having the teachings of Lowe, Bahrami and Vyas and Manzano available before the effective filing date of the claimed invention, to modify the capability of API validation as disclosed by Lowe, Bahrami and Vyas to include the capability of API scoring as taught by Manzano, thereby providing a mechanism to enhance system integrity by providing a mechanism to enforce quality standards.
28. As per claim 14, it is a system claim having similar limitations as cited in claims 6 and 7. Thus, claim 14 is also rejected under the same rationale as cited in the rejection of claims 6 and 7 above.
29. As per claim 20, it is a media claim having similar limitations as cited in claims 5, 6 and 7. Thus, claim 30 is also rejected under the same rationale as cited in the rejection of claims 5, 6 and 7 above.
Response to Arguments
Claim Objections
30. Applicant’s arguments have been fully considered and are persuasive. The objection has been withdrawn.
Claim Rejections - 35 USC § 101
31. Applicant's arguments have been fully considered but they are not persuasive.
32. Applicant argues on pages 11 – 14 that the instant claims are analogous to claim 1 of example 37 in the 2019 PEG and are thus eligible subject matter. However, claim 37 recites claim limitations that improve a user interface while the instant claims recite limitations that assist in grading and remediating an API specification. The display aspects of the instant claims support the grading and mediation of the noted API specification and do not improve or otherwise alter the functioning of a GUI. As recited above, the display aspects of the instant limitations represent extra-solution activity and/or implementation of the abstract idea and are thus not eligible subject matter nor are they analogous to example 37.
33. Applicant further argues on pages 14 – 16 that the amended independent claims are analogous to claim 4 of example 23 in the 2019 PEG. However, as recited above, claim 4 of example 23 relates to improvement of a GUI, specifically by eliminating text overlap conditions, thereby improving the function of the GUI. The display aspects of the instant claims support the grading and mediation of the noted API specification and do not improve or otherwise alter the functioning of a GUI. As recited above, the display aspects of the instant limitations represent extra-solution activity and/or implementation of the abstract idea and are thus not eligible subject matter nor are they analogous to example 24.
Claim Rejections - 35 USC § 103
34. Applicant’s arguments 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.
Conclusion
35. 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.
36. Any inquiry concerning this communication or earlier communications from the examiner should be directed to WILLIAM C WOOD whose telephone number is (571)272-5285. The examiner can normally be reached Monday - Friday, 8:00 am - 4: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, Chat C Do can be reached at 571-272-3721. 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.
/WILLIAM C WOOD/Examiner, Art Unit 2193
/Chat C Do/Supervisory Patent Examiner, Art Unit 2193
Prosecution Insights