DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
The instant application is a 371 of PCT/CN2023/075057 filed 08 February 2023 which claims foreign priority to CN202210187940.0 filed 28 February 2022. The priority claims comply with all applicable rules and regulations. Therefore, the effective filing date of the claims is 28 February 2022.
Information Disclosure Statement
The Information Disclosure Statements filed on 09 September 2024 and 12 March 2025 comply with all applicable rules and regulations. Therefore, the information referred to therein has been considered.
Drawings
No issues have been found with the drawings filed 27 August 2024.
Specification
No issues have been found with the specification filed 27 August 2024.
Claim Objections
Claims 1, 7, 9, 13, 14, and 22 are objected to because of the following informalities:
Regarding claim 1, lines 3-4—“the to-be-processed interface” lacks sufficient antecedent basis for the claim. In order to overcome this objection, lines 3-4 could be amended to state --the at least one to-be-processed interface-- in order to refer to “at least one to-be-processed interface” of line 3.
Claims 13 and 14 include similar language and are similarly analyzed.
Regarding claim 1, line 8—“a target state” appears to be referring to “a target state” of line 5. In order to overcome this objection, line 8 could be amended to state --the target state-- in order to refer to “a target state” of line 5.
Claims 13 and 14 include similar language and are similarly analyzed.
Regarding claim 7, line 4—“response out parameter, error code” should be amended to state --response out parameter, and error code-- in order to include the missing word.
Claim 22 includes similar language and is similarly analyzed.
Regarding claim 9, line 5—“the test results” lacks sufficient antecedent basis for the claim. In order to overcome this objection, line 5 could be amended to state --the test result-- in order to refer to “a test result” of lines 3-4.
Regarding claim 13, lines 3-4—“the acts” lacks sufficient antecedent basis for the claim. In order to overcome this objection, lines 3-4 could be amended to state --acts-- in order to remove the extra word.
Regarding claim 14, line 3—“the method” lacks sufficient antecedent basis for the claim. In order to overcome this objection, line 3 could be amended to state --a method--.
Appropriate correction is required.
Claim Rejections - 35 USC § 102
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-8, 11, 13, 14, and 17-23 are rejected under 35 U.S.C. 102(a)(1)/(a)(2) as being anticipated by McMahon et al. (US 2014/0289702 A1).
Regarding claim 1, McMahon teaches a method for interactive publication of an interface based on a permission, comprising:
displaying first interface information in an interactive page, e.g., interface 700 (Fig. 7, el. 700), corresponding to a first user permission, the first interface information indicating at least one to-be-processed interface, and the to-be-processed interface being an application programming interface processed based on the first user permission, e.g., the build system may maintain an initial login and selection screen where a user can login—first user permission-- and then select an SDK and version (Para. 76);
as shown at 708, an interface listing a plurality of APIs ("AddRating", "CreateAcct", and "GetRating") is provided, and the API name, title, and available actions are indicated, wherein a user may select "edit" to trigger the generation of an editing interface or "destroy" to remove the API entirely (Fig. 7, el. 708; Para. 78);
at block 304, the system receives selection of an API of interest, wherein each SDK may feature a list of available APIs (Fig. 3, el. 304; Para. 55);
configuring a to-be-processed target interface to be in a target state in response to a first operation instruction for the to-be-processed target interface, wherein the first operation instruction is realized based on the first user permission, e.g., a user may select "edit" to trigger the generation of an editing interface or "destroy" to remove the API entirely (Para. 78);
an exemplary editing interface 900 for editing the "CreateAcct" API and documentation depicted in FIG. 8, for example, if a user selected the "edit" command in interface 700 (Fig. 9, el. 900; Para. 81);
accordingly, interface element 912 may not be displayed to all users, wherein for example, a technical writer may be able to view element 912 but may not be able to change the values thereof while a developer may be able to change all elements (Fig. 9, el. 912; Para. 82);
assuming the user has some editing permissions, the user may be presented with an "edit" button that triggers a controlled editing process, where this is represented at block 306, where the system presents an editing interface to the user (Fig. 3, el. 306; Para. 56);
the technical writer may be provided with current data and a more user friendly interface for performing his or her assigned portion of the task, wherein once he or she has updated his or her portion of the data, the updates can be merged into the WADL specification and used in the automated build process, with the technical writer able to view the results as published to the SDK after the next build (Para. 32);
specification management system 120 may allow a software engineer to edit portions of the specification data that define API functionality via a more user-friendly interface, wherein for example, rather than using a separate XML editor and parsing the entire WADL file for a web service, the developer may be presented with an HTML-based page for only a particular API or portion thereof with form inputs for defining and describing parameters (Para. 33); and
under a predetermined triggering condition, according to a target state of the to-be-processed target interface, publishing the to-be-processed target interface to an open platform, e.g., server platform 110 comprising server-side application(s) 112 (Fig. 1, el. 110, 112), wherein service development platform 116 may comprise the same server or a different server that actually executes server-side application(s) 112 (Fig. 1, el. 112, 116; Para. 23. When the data service is updated, build system 118 may publish the latest version of server-side application 112 and API 114 to server platform 110 (Para. 26)), or generating second interface information corresponding to the to-be-processed target interface, the second interface information being used for displaying the to-be-processed target interface in an interactive page corresponding to a second user permission, e.g., a user can edit the descriptive and/or functional aspects of the API definition and then commit the changes. The HTML-as-edited can then be converted into XML for use in updating the WADL file corresponding to the API and an updated build can be triggered (Para. 86);
at block 308, the changes made by the user are merged into the API specification or other specification data, and then, at block 310, an updated build is triggered, wherein the updated specification data may be used as the basis of a new version that is built using the automated build system and then published to an appropriate portion of the repository (Fig. 3, el. 308, 310; Para. 57);
a user may make selections from drop-down menus, check, uncheck, or toggle switches, or fill in form fields and then press an onscreen "commit" or other button to indicate that editing is complete (Para. 64);
when the data service is updated, build system 118 may publish the latest version of server-side application 112 and API 114 to server platform 110 (Fig. 1; Para. 26).
Examiner Note: the claim language indicates two alternatives for the last limitation, i.e., “under a predetermined triggering condition, according to a target state of the to-be-processed target interface, publishing the to-be-processed target interface to an open platform” or “generating second interface information corresponding to the to-be-processed target interface, the second interface information being used for displaying the to-be-processed target interface in an interactive page corresponding to a second user permission”. Using the broadest reasonable interpretation of the claim only one of the alternatives is required.
Regarding claim 2, McMahon teaches the method of claim 1, wherein the first operation instruction comprises an interface editing instruction, e.g., a user may select "edit" to trigger the generation of an editing interface or "destroy" to remove the API entirely (McMahon-Para. 78);
an exemplary editing interface 900 for editing the "CreateAcct" API and documentation depicted in FIG. 8, for example, if a user selected the "edit" command in interface 700 (McMahon-Fig. 9, el. 900; Para. 81);
assuming the user has some editing permissions, the user may be presented with an "edit" button that triggers a controlled editing process, where this is represented at block 306, where the system presents an editing interface to the user (McMahon-Fig. 3, el. 306; Para. 56);
the configuring a to-be-processed target interface to be in a target state in response to a first operation instruction for the to-be-processed target interface comprises:
in response to the interface editing instruction for the to-be-processed target interface, editing an interface configuration parameter of the to-be-processed target interface, e.g., a user may select "edit" to trigger the generation of an editing interface or "destroy" to remove the API entirely (McMahon-Para. 78);
an exemplary editing interface 900 for editing the "CreateAcct" API and documentation depicted in FIG. 8, for example, if a user selected the "edit" command in interface 700 (McMahon-Fig. 9, el. 900; Para. 81);
accordingly, interface element 912 may not be displayed to all users, wherein for example, a technical writer may be able to view element 912 but may not be able to change the values thereof while a developer may be able to change all elements (McMahon-Fig. 9, el. 912; Para. 82);
assuming the user has some editing permissions, the user may be presented with an "edit" button that triggers a controlled editing process, where this is represented at block 306, where the system presents an editing interface to the user (McMahon-Fig. 3, el. 306; Para. 56);
the technical writer may be provided with current data and a more user friendly interface for performing his or her assigned portion of the task, wherein once he or she has updated his or her portion of the data, the updates can be merged into the WADL specification and used in the automated build process, with the technical writer able to view the results as published to the SDK after the next build (McMahon-Para. 32);
specification management system 120 may allow a software engineer to edit portions of the specification data that define API functionality via a more user-friendly interface, wherein for example, rather than using a separate XML editor and parsing the entire WADL file for a web service, the developer may be presented with an HTML-based page for only a particular API or portion thereof with form inputs for defining and describing parameters (McMahon-Para. 33);
after an editing action corresponding to the interface editing instruction is performed, configuring the to-be-processed target interface to be in a to-be-reviewed state, e.g., a user can edit the descriptive and/or functional aspects of the API definition and then commit the changes. The HTML-as-edited can then be converted into XML for use in updating the WADL file corresponding to the API and an updated build can be triggered—to-be-reviewed state-- (McMahon-Para. 86);
at block 308, the changes made by the user are merged into the API specification or other specification data, and then, at block 310, an updated build is triggered, wherein the updated specification data may be used as the basis of a new version that is built using the automated build system and then published to an appropriate portion of the repository—to-be-reviewed state-- (McMahon-Fig. 3, el. 308, 310; Para. 57);
a user may make selections from drop-down menus, check, uncheck, or toggle switches, or fill in form fields and then press an onscreen "commit" or other button to indicate that editing is complete—to-be-reviewed state-- (McMahon-Para. 64);
when the data service is updated, build system 118 may publish the latest version of server-side application 112 and API 114 to server platform 110—to-be-reviewed state-- (McMahon-Fig. 1; Para. 26);
the under a predetermined triggering condition, according to a target state of the to-be-processed target interface, generating second interface information corresponding to the to-be-processed target interface, comprises: in response to the to-be-processed target interface being in the to-be-reviewed state, generating the second interface information corresponding to the to-be-processed target interface, e.g., as shown at 708, an interface listing a plurality of APIs ("AddRating", "CreateAcct", and "GetRating") is provided, and the API name, title, and available actions are indicated, wherein a user may select "edit" to trigger the generation of an editing interface or "destroy" to remove the API entirely (McMahon-Fig. 7, el. 708; Para. 78);
the technical writer may be provided with current data and a more user friendly interface—second interface information-- for performing his or her assigned portion of the task, wherein once he or she has updated his or her portion of the data, the updates can be merged into the WADL specification and used in the automated build process, with the technical writer able to view the results as published to the SDK after the next build (McMahon-Para. 32);
specification management system 120 may allow a software engineer to edit portions of the specification data that define API functionality via a more user-friendly interface—second interface information--, wherein for example, rather than using a separate XML editor and parsing the entire WADL file for a web service, the developer may be presented with an HTML-based page for only a particular API or portion thereof with form inputs for defining and describing parameters (McMahon-Para. 33).
Examiner note: claim 1 indicates two alternatives for the last limitation, i.e., “under a predetermined triggering condition, according to a target state of the to-be-processed target interface, publishing the to-be-processed target interface to an open platform” or “generating second interface information corresponding to the to-be-processed target interface, the second interface information being used for displaying the to-be-processed target interface in an interactive page corresponding to a second user permission”. Using the broadest reasonable interpretation of the claim only one of the alternatives is required.
The language of claim 2, i.e., “generating second interface information corresponding to the to-be-processed target interface” seems to refer to one of the alternatives of claim 1. In this case, if claim 1’s “publishing” alternative is performed then claim 2’s “generating second interface information corresponding to the to-be-processed target interface” will not be performed and is not required as it is part of the other alternative.
Regarding claim 3, McMahon teaches the method of claim 2, wherein the after an editing action corresponding to the interface editing instruction is performed, configuring the to-be-processed target interface to be in a to-be-reviewed state comprises: after the editing action corresponding to the interface editing instruction is performed, testing the to-be-processed target interface to obtain a test result; and in response to the test result being normal, configuring the to-be-processed target interface to be in the to-be-reviewed state, e.g., at block 308, the changes made by the user are merged into the API specification or other specification data, and then, at block 310, an updated build is triggered, wherein for example, the updated specification data may be used as the basis of a new version that is built using the automated build system and then published to an appropriate portion of the repository, and then, the user may view the SDK as updated or, if the build fails, appropriate error messages can be provided (McMahon-Fig. 3, el. 308, 310; Para. 57);
Build system 118 may also generate code to test aspects of server-side application 112, and thus, connection 122 is illustrated to represent build system 118 invoking the functionality of server-side application 112 via API 114 by running test code, wherein when the data service is updated, build system 118 may publish the latest version of server-side application 112 and API 114 to server platform 110, and additionally, the latest SDK artifacts and test results may be made available to authorized users of server platform 110 or may be made available at development platform 116 for internal use (McMahon-Fig. 1; Para. 26).
Regarding claim 4, McMahon teaches the method of claim 1, wherein the first operation instruction comprises an interface reviewing instruction, e.g., as shown at 708, an interface listing a plurality of APIS ("AddRating", "CreateAcct", and "GetRating") is provided, wherein the API name, title, and available actions are indicated, wherein a user may select "edit" to trigger the generation of an editing interface or "destroy" to remove the API entirely, and the API name/title may be clickable to view the API documentation as currently published (McMahon-Fig. 7, el. 708; Para. 78),
Examiner note: McMahon discloses electing to edit an API and, in response, presenting the editing interface. This editing interface may also be used by the technical write/developer to review the API configurations. Therefore, the “edit” instruction would also be considered a “reviewing” instruction.
the configuring a to-be-processed target interface to be in a target state in response to a first operation instruction for the to-be-processed target interface comprises: in response to the interface review instruction for the to-be-processed target interface, displaying an interface configuration parameter of the to-be-processed target interface, e.g., a user may select "edit" to trigger the generation of an editing interface or "destroy" to remove the API entirely (McMahon-Para. 78);
an exemplary editing interface 900 for editing the "CreateAcct" API and documentation depicted in FIG. 8, for example, if a user selected the "edit" command in interface 700 (McMahon-Fig. 9, el. 900; Para. 81);
accordingly, interface element 912 may not be displayed to all users, wherein for example, a technical writer may be able to view element 912 but may not be able to change the values thereof while a developer may be able to change all elements (McMahon-Fig. 9, el. 912; Para. 82);
assuming the user has some editing permissions, the user may be presented with an "edit" button that triggers a controlled editing process, where this is represented at block 306, where the system presents an editing interface to the user (McMahon-Fig. 3, el. 306; Para. 56);
in response to a confirmation instruction input by a user, configuring the to-be-processed target interface to be in a to-be-published state, e.g., a user can edit the descriptive and/or functional aspects of the API definition and then commit the changes, wherein the HTML-as-edited can then be converted into XML for use in updating the WADL file corresponding to the API and an updated build can be triggered (McMahon-Para. 86);
at block 308, the changes made by the user are merged into the API specification or other specification data, and then, at block 310, an updated build is triggered, wherein the updated specification data may be used as the basis of a new version that is built using the automated build system and then published to an appropriate portion of the repository (McMahon-Fig. 3, el. 308, 310; Para. 57);
a user may make selections from drop-down menus, check, uncheck, or toggle switches, or fill in form fields and then press an onscreen "commit" or other button to indicate that editing is complete (McMahon-Para. 64);
when the data service is updated, build system 118 may publish the latest version of server-side application 112 and API 114 to server platform 110 (McMahon-Fig. 1; Para. 26);
the under a predetermined triggering condition, according to a target state of the to-be-processed target interface, publishing the to-be-processed target interface to an open platform comprises: in response to the to-be-processed target interface being in the to-be-published state, publishing the to-be-processed target interface to the open platform, e.g., at block 308, the changes made by the user are merged into the API specification or other specification data, and then, at block 310, an updated build is triggered, wherein the updated specification data may be used as the basis of a new version that is built using the automated build system and then published to an appropriate portion of the repository (McMahon-Fig. 3, el. 308, 310; Para. 57);
when the data service is updated, build system 118 may publish the latest version of server-side application 112 and API 114 to server platform 110 (McMahon-Fig. 1; Para. 26).
Regarding claim 5, McMahon teaches the method of claim 1 further comprising: after generating the second interface information corresponding to the to-be-processed target interface, obtaining a target user having the second user permission corresponding to the second interface information, e.g., the build system may maintain an initial login and selection screen where a user can login—second user permission-- and then select an SDK and version (McMahon-Para. 76);
as shown at 708, an interface listing a plurality of APIs ("AddRating", "CreateAcct", and "GetRating") is provided, and the API name, title, and available actions are indicated, wherein a user may select "edit" to trigger the generation of an editing interface or "destroy" to remove the API entirely (McMahon-Fig. 7, el. 708; Para. 78);
the technical writer may be provided with current data and a more user friendly interface for performing his or her assigned portion of the task, wherein once he or she has updated his or her portion of the data, the updates can be merged into the WADL specification and used in the automated build process, with the technical writer able to view the results as published to the SDK after the next build (McMahon-Para. 32);
specification management system 120 may allow a software engineer to edit portions of the specification data that define API functionality via a more user-friendly interface, wherein for example, rather than using a separate XML editor and parsing the entire WADL file for a web service, the developer may be presented with an HTML-based page for only a particular API or portion thereof with form inputs for defining and describing parameters (McMahon-Para. 33); and
pushing review task information to the target user, the review task information being used for prompting the target user to review the to-be-processed target interface, e.g., as shown at 708, an interface listing a plurality of APIs ("AddRating", "CreateAcct", and "GetRating") is provided, and the API name, title, and available actions are indicated, wherein a user may select "edit" to trigger the generation of an editing interface or "destroy" to remove the API entirely (McMahon-Fig. 7, el. 708; Para. 78).
Examiner note 1: McMahon discloses logging-in by the user and then presenting the listing of APIs to the user. The user may elect to edit an API or just view the current settings of the API. The APIs being displayed in the list would be considered “prompting” the user to review the APIs.
Examiner note 2: claim 1 indicates two alternatives for the last limitation, i.e., “under a predetermined triggering condition, according to a target state of the to-be-processed target interface, publishing the to-be-processed target interface to an open platform” or “generating second interface information corresponding to the to-be-processed target interface, the second interface information being used for displaying the to-be-processed target interface in an interactive page corresponding to a second user permission”. Using the broadest reasonable interpretation of the claim only one of the alternatives is required.
The language of claim 5, i.e., “after generating the second interface information corresponding to the to-be-processed target interface” seems to refer to one of the alternatives of claim 1. In this case, if claim 1’s “publishing” alternative is performed then claim 5’s limitations will not be performed and are not required as they are part of the other alternative.
Regarding claim 6, McMahon teaches the method of claim 1, wherein the method further comprises: before displaying the first interface information, obtaining an interface configuration parameter in response to a second operation instruction, the interface configuration parameter mapping a remote call service corresponding to the to-be-processed interface, e.g., if the user selects button 704 to create a new API, a template can be used to generate a basic WADL file and then the WADL file can be used to provide an editing interface to define the API details (McMahon-Fig. 7, el. 704; Para. 77);
interface element 912 includes a pull-down menu and text field for specifying the syntax for invoking the API, wherein for example, the pull-down menu may be used to define a POST, PUT, GET, or other command, while the text field can be used to define the syntax for invoking the command (McMahon-Fig. 9, el. 912; Para. 82);
the web service may be implemented as a representational state transfer (REST) architecture in which the clients provide calls to remote methods via HTTP requests that can include one or more (and typically several) parameters using a format specified in documentation for API 114 (McMahon-Fig. 1, el. 114; Para. 21); and
generating the first interface information based on the interface configuration parameter, e.g., If the user select button 704 to create a new API, a template can be used to generate a basic WADL file and then the WADL file can be used to provide an editing interface to define the API details (McMahon-Fig. 7, el. 704; Para. 77);
an exemplary editing interface 900 for editing the "CreateAcct" API and documentation depicted in FIG. 8, for example, if a user selected the "edit" command in interface 700 (McMahon-Fig. 9, el. 900; Para. 81);
interface element 912 includes a pull-down menu and text field for specifying the syntax for invoking the API, wherein for example, the pull-down menu may be used to define a POST, PUT, GET, or other command, while the text field can be used to define the syntax for invoking the command (McMahon-Fig. 9, el. 912; Para. 82).
Regarding claim 7, McMahon teaches the method of claim 6, wherein the interface configuration parameter comprises a first parameter, and the first parameter comprises at least one of: remote procedure call name, method name, business in parameter, internal variable in parameter, response out parameter, error code, e.g., interface element 912 includes a pull-down menu and text field for specifying the syntax for invoking the API, wherein for example, the pull-down menu may be used to define a POST, PUT, GET, or other command, while the text field can be used to define the syntax for invoking the command (McMahon-Fig. 9, el. 912; Para. 82).
Regarding claim 8, McMahon teaches the method of claim 7, wherein the interface configuration parameter further comprises a second parameter, and the second parameter is used for indicating the second user permission for processing the to-be-processed interface, e.g., if the user selects button 704 to create a new API, a template can be used to generate a basic WADL file and then the WADL file can be used to provide an editing interface to define the API details (McMahon-Fig. 7, el. 704; Para. 77);
accordingly, interface element 912 may not be displayed to all users, wherein for example, a technical writer may be able to view element 912 but may not be able to change the values thereof while a developer may be able to change all elements (McMahon-Fig. 9, el. 912; Para. 82);
the technical writer may be provided with current data and a more user friendly interface for performing his or her assigned portion of the task, wherein once he or she has updated his or her portion of the data, the updates can be merged into the WADL specification and used in the automated build process, with the technical writer able to view the results as published to the SDK after the next build (McMahon-Para. 32);
specification management system 120 may allow a software engineer to edit portions of the specification data that define API functionality via a more user-friendly interface, wherein for example, rather than using a separate XML editor and parsing the entire WADL file for a web service, the developer may be presented with an HTML-based page for only a particular API or portion thereof with form inputs for defining and describing parameters (McMahon-Para. 33).
Regarding claim 11, McMahon teaches the method of claim 1, wherein the interactive page comprises a first sub-interface and/or a second sub-interface, the first sub-interface is configured to display a to-be-processed interface that is not currently published to the open platform; the second sub-interface is configured to display a to-be-processed interface that has been currently published to the open platform, e.g., if a user selects documentation button 706, an interface listing documentation for the SDK as a whole can be provided with options similar to interface 708, and if the user select button 704 to create a new API, a template can be used to generate a basic WADL file and then the WADL file can be used to provide an editing interface to define the API details—not currently published-- (McMahon-Fig. 7; Para. 77);
as shown at 708, an interface listing a plurality of APIS ("AddRating", "CreateAcct", and "GetRating") is provided, wherein the API name, title, and available actions are indicated, wherein for example, a user may select "edit" to trigger the generation of an editing interface or "destroy" to remove the API entirely—currently published--, and the API name/title may be clickable to view the API documentation as currently published—currently published-- (McMahon-Fig. 7; Para. 78).
Examiner Note: the claim language indicates two alternatives for the last limitation, i.e., “wherein the interactive page comprises a first sub-interface” and/or “a second sub-interface”. Using the broadest reasonable interpretation of the claim only one of the alternatives is required.
Regarding claim 13, the claim is analyzed with respect to claim 1. McMahon further teaches an electronic device, e.g., one or more service development platforms 128/computing platform 200 (McMahon-Fig. 1, el. 128; Fig. 2, el. 200), comprising:
a processor, e.g., one or more processors 204 (McMahon-Fig. 2, el. 204), and a memory, e.g., memory 220 (McMahon-Fig. 2, el. 220), communicatively connected with the processor; the memory storing computer executable instructions which, when executed by the processor, e.g., components for developing a data service embodied in memory and provide specification management functionality in accordance with aspects of the present subject matter (McMahon-Para. 38), implement the acts.
Regarding claim 14, the claim is analyzed with respect to claim 1. McMahon further teaches a non-transitory computer readable storage medium, e.g., memory 220 (McMahon-Fig. 2, el. 220), wherein the computer readable storage medium stores computer executable instructions, e.g., components for developing a data service embodied in memory and provide specification management functionality in accordance with aspects of the present subject matter (McMahon-Para. 38), which, when executed by a processor, e.g., one or more processors 204 (McMahon-Fig. 2, el. 204), implement the method.
Regarding claim 17, the claim is analyzed with respect to claim 2.
Regarding claim 18, the claim is analyzed with respect to claim 3.
Regarding claim 19, the claim is analyzed with respect to claim 4.
Regarding claim 20, the claim is analyzed with respect to claim 5.
Regarding claim 21, the claim is analyzed with respect to claim 6.
Regarding claim 22, the claim is analyzed with respect to claim 7.
Regarding claim 23, the claim is analyzed with respect to claim 8.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 9 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over McMahon in view of Prabhakar et al. (US 2016/0294667 A1).
Regarding claim 9, McMahon teaches the method of claim 6.
McMahon further teaches wherein the method further comprises: after generating the first interface information, testing the to-be-processed interface corresponding to the first interface information to obtain a test result, e.g., build system 118 may also generate code to test aspects of server-side application(s) 112, wherein connection 122 is illustrated to represent build system 118 invoking the functionality of server-side application 112 via API 114 by running test code, wherein when the data service is updated, build system 118 may publish the latest version of server-side application 112 and API 114 to server platform 110, and additionally, the latest SDK artifacts and test results may be made available to authorized users of server platform 110 or may be made available at development platform 116 for internal use (McMahon-Fig. 1; Para. 26).
McMahon does not clearly teach displaying the test results on the interactive page.
Prabhakar teaches displaying the test results on the interactive page, e.g., as shown in FIG. 3, the API catalog can display a plurality of entries for recently published APIs 311, for example, “Yahoo Search” and “Currency Exchange” APIs; and a plurality of entries 313 that have been recently reviewed—displaying the test results-- (Fig. 3; Para. 59).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify McMahon to include displaying the test results on the interactive page, using the known method of displaying an API catalog with a list of recently reviewed APIs, as taught by Prabhakar, in combination with the API development and testing system of McMahon, for the purpose of providing an indication to the user that a particular API has been reviewed, and allowing the user to make a more informed decision based on the indication.
Regarding claim 10, McMahon in view of Prabhakar teaches the method of claim 9, wherein the testing the to-be-processed interface corresponding to the first interface information to obtain a test result comprises: obtaining corresponding test data based on the interface configuration parameter; and testing the to-be-processed interface based on the corresponding test data to obtain the test result, e.g., build system 118 may also generate code to test aspects of server-side application(s) 112, wherein connection 122 is illustrated to represent build system 118 invoking the functionality of server-side application 112 via API 114 by running test code, wherein when the data service is updated, build system 118 may publish the latest version of server-side application 112 and API 114 to server platform 110, and additionally, the latest SDK artifacts and test results may be made available to authorized users of server platform 110 or may be made available at development platform 116 for internal use (McMahon-Fig. 1; Para. 26).
Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Talmor et al. (US 2022/0398093 A1)—Talmor et al. discloses users 112A-Z may be human beings that are functioning in one or more development roles (e.g., designer, developer, reviewer, tester, manager, or documenter) and performing one or more development tasks (e.g., design, development, reviewing, testing, verifying, documenting) (Para. 16).
Haze (US 2020/0082307 A1)—Haze discloses users in the user landscape 104 can be developers, testers, analysts, administrators, and other types of users who may have a need to use software interfaces or artifacts (Para. 19).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEREMY DUFFIELD whose telephone number is (571)270-1643. The examiner can normally be reached Monday - Friday, 7:00 AM - 3:00 PM (ET).
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, Yin-Chen Shaw can be reached at (571) 272-8878. 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.
20 March 2026
/Jeremy S Duffield/Primary Examiner, Art Unit 2498