DETAILED ACTION
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 1/27/2026 has been entered.
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
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, 3 – 5, 7, 9, 11 – 14, 16 and 18 - 20 are directed to an abstract idea without significantly more. Independent claim 1 recites a computer-implemented method for remediating 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 indicating a first compliance 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 comprising a selection 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, wherein the first portion of the user interface dynamically interacts with the second portion of the user interface; in response to receiving the first user input, automatically 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; receiving, with the at least one processor, a second user input comprising a selection of at least one second user selectable interactive feature embedded in the corresponding portion of the API specification, the at least one second user selectable interactive feature configured to facilitate remediation of the at least one violation; automatically remediating, with at least one processor, the emphasized corresponding portion of the API specification that contains the first violation by automatically modifying the emphasized corresponding portion of the API specification to correct the first violation and provide a remediated API specification; in response to modifying the emphasized corresponding portion of the API specification that contains the first violation, automatically generating, with at least one processor, a second report based on the remediated API specification, the second report comprising at least one second score indicating an improved compliance metric compared to the first compliance metric; 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; and automatically publishing, with at least one processor, the remediated API specification based on determining the at least one second score satisfies a threshold value.
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 indicating a first compliance metric” 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 …,” “automatically remediating, …, the emphasized corresponding portion of the API specification that contains the first violation to form a remediated API specification,” “in response to modifying 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 … ” “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” and “automatically publishing … the remediated API specification …” 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 …, “ “generating, … , a report for the API specification …” and “automatically publishing … the remediated 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 …,” and “automatically publishing … the remediated API specification …” 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 3 – 5, 7, 11 – 14 and 18 - 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 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 second score and 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 second score to the threshold value (abstract idea under mental process under Prong I step 2A); and determining the at least one second score satisfies the threshold value (abstract idea under mental process under Prong I step 2A).
As per claims 14 and 20, further comprising: comparing the at least one second score to the threshold value (abstract idea under mental process under Prong I step 2A); and determining that the at least one second score does not satisfy 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, 5, 7, 9, 13, 14, 16 and 20 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), Vyas et al. (U.S. Publication 2021/0216,308) (Vyas hereinafter) and Manzano et al. (U.S. Patent 11,281,462) (Manzano hereinafter).
9. As per claim 1, Lowe teaches a computer-implemented method for remediating 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 indicating a first compliance metric [“Engine 142 of the API Validator Tool 110 may analyze compliance metrics and generate an API Quality Rating,” ¶ 0029; “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 comprising a selection 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], wherein the first portion of the user interface dynamically interacts with the second portion of the user interface [“if the API specification includes three API pages and the user is currently viewing and/or annotating a second API page, the temporary file may include data representative of only the second API page,” ¶ 0084]; and
in response to receiving the first user input, automatically 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; object display with yellow highlighting based on style file settings suggests automatic emphasis]; and
receiving, with the at least one processor, a second user input comprising a selection of at least one second user selectable interactive feature embedded in the corresponding portion of the API specification, the at least one second user selectable interactive feature configured to facilitate remediation of the at least one violation [“receiving a second API documentation, the second API documentation including a second plurality of API objects; determining the API format associated the second API documentation; responsive to the API format associated with the second API documentation being the same as or similar to at least one API format of the one or more API formats: identifying one or more related API objects of the second plurality of API objects, the one or more related API objects of the second plurality of API objects being related to the one or more API objects of the first plurality of API objects to be annotated; generating a second temporary file that includes data representative of the second API documentation; generating a second application file that includes data representative of one or more functions to be applied to the second temporary file; and automatically applying the one or more functions to the second temporary file, wherein the one or more functions update data representative of at least one API object of the second plurality of API objects,” Cl. 6; updating based on second user input suggests remediation].
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 automatically remediating, with at least one processor, the emphasized corresponding portion of the API specification that contains the first violation by automatically modifying the emphasized corresponding portion of the API specification to correct the first violation and provide a remediated API specification [“process 400 may include correcting the system level set of API specifications, based on the system level differences, to generate a corrected system level set of API specifications (block 450). For example, the device (e.g., using computing resource 224, processor 320, memory 330, storage component 340, and/or the like ) 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,” ¶ 0077; “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 automatic remediation];
in response to modifying the emphasized corresponding portion of the API specification that contains the first violation, automatically generating, with at least one processor, a second report based on the remediated API specification, the second report comprising at least one second score indicating an improved compliance metric compared to the first compliance metric [“In a second implementation, alone or in combination with the first implementation, 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,” ¶ 0099]; 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.
Lowe, Bahrami and Vyas do not explicitly disclose but Manzano discloses automatically publishing, with at least one processor, the remediated API specification based on determining the at least one second score satisfied a 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.
10. As per claim 5, Lowe, Bahrami, Vyas and Manzano 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 second score and 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].
25. As per claim 7, Lowe, Bahrami, Vyas and Manzano teach the computer-implemented method of claim 5. Lowe further teaches comparing the at least one second score to the threshold value; determining the at least one second 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].
11. 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.
12. 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.
13. 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 14, it is a system claim having similar limitations as cited in claim 7. Thus, claim 14 is also rejected under the same rationale as cited in the rejection of claim 7 above.
16. 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.
17. As per claim 20, it is a media claim having similar limitations as cited in claims 5 and 7. Thus, claim 20 is also rejected under the same rationale as cited in the rejection of claims 5 and 7 above.
18. Claims 3, 11 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Lowe, Bahrami, Vyas and Manzano in further view of Krebs et al. (U.S. Patent 11,977,860) (Krebs hereinafter).
19. As per claim 3, Lowe, Bahrami, Vyas and Manzano 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, Vyas and Manzano 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, Manzano and Krebs available before the effective filing date of the claimed invention, to modify the capability of API validation as disclosed by Lowe, Bahrami, Vyas and Manzano 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, Vyas and Manzano 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.
Response to Arguments
Claim Rejections - 35 USC § 101
26. Applicant's arguments have been fully considered but they are not persuasive.
27. In response to applicant’s assertions on pages 12 – 18 that the claims are not directed to an abstract idea, each claim and claim limitation individually and as a whole are identified and analyzed as recited in the above rejections. The abstract idea limitations are clearly identified.
28. In response to applicant’s assertions on pages 18 – 20 that the claims recite an inventive concept, each claim and claim limitation individually and as a whole are identified and analyzed as recited in the above rejections. The abstract idea and pre/post solution activity limitations are clearly identified and analyzed in light of the noted MPEP section. Additionally, applicant indicates that the claims amount to an improvement in technology in light of Alice, but does not specifically identify what technology or technological field is improved. Finally, the combination of specific claim features in not unconventional in the art as evidenced by the cited prior art references.
Claim Rejections - 35 USC § 103
29. Applicant's arguments filed have been fully considered but they are not persuasive.
30. Upon further detailed review of the previously cited references, the subject rejections have been updated in accordance with the claim amendments to include additional sections of the cited references. As recited above, Bahrami at claim 6 discloses the “receiving … a second user input …” limitation, and Vyas discloses the “automatically remediating …” limitation at paragraphs [077] and [0098] and the “in response to modifying …” limitation at paragraph [0099].
Conclusion
31. 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