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
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.
Response to Arguments
Applicant's arguments filed 28 June 2026 have been fully considered but they are not persuasive.
In response to applicant’s arguments that “McMahon does not disclose at least the highlighted features of clarified claim 1,” stated on page 11, the examiner respectfully disagrees.
McMahon discloses displaying an interface 700 for viewing/managing APIs and documentation of an SDK. As shown at 708, an interface listing a plurality of APIS ("AddRating", "CreateAcct", and "GetRating") is provided. The API name, title, and available actions are indicated. For example, a user may select "edit" to trigger the generation of an editing interface or "destroy" to remove the API entirely. The API name/title may be clickable to view the API documentation as currently published (Fig. 7; Para. 77, 78).
McMahon further discloses displaying 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, then interface 900 may be generated by parsing the WADL file and generating an HTML page (Figs. 8, 9; Para. 81). Interface element 912 includes a pull-down menu and text field for specifying the syntax for invoking the API. Changes at element 912 can result in changes to the documentation as shown at 812 and can also propagate out to code generation elements of the build system. Accordingly, interface element 912 may not be displayed to all users. 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; Para. 82).
McMahon also discloses a computing device may access one or more computer-readable media that tangibly embody computer-readable instructions which, when executed by at least one computer, cause the at least one computer to implement one or more embodiments of the present subject matter (Para. 93).
In other words, a user, e.g., a technical writer or developer, may elect to view the currently-published API or edit the API using the editing interface. The version of the editing interface provided to the user depends on the user role such that a technical writer may not be able to edit certain values while a developer may be able to edit all elements. Configuring the to-be-processed interface/API to be in one of the states could be interpreted to be configuring the to-be-processed interface/API to either be displayed for viewing or displayed for editing based on the user role. The states/executable action scripts could be interpreted as the instructions that are executed by the processor to display the API for viewing and display the API for editing based on the different user roles.
Therefore, the claim 1 limitations are taught by the cited prior art.
The examiner suggests amending the independent claims to clarify specifically how the to-be-processed interface is configured to be in a particular state and how the executable action scripts correspond to the particular state.
Claim Objections
Claims 10 and 14 are objected to because of the following informalities:
Regarding claim 10, line 2—“a test result” appears to be referring to “a test result” of claim 9, line 4. In order to overcome this objection, line 2 could be amended to state --the test result--.
Regarding claim 14, line 4—“the method comprising” should be amended to include a colon after “comprising”.
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 at least one 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 interface from the at least one to-be-processed interface to be in a state of a plurality of states in response to a first operation instruction for the to-be-processed interface, wherein the first operation instruction is realized based on the first user permission, wherein each of the plurality of states corresponds to a different one of a plurality of executable actions scripts, 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, executing an executable action script, from the plurality of executable action scripts, that corresponds to the state of the to-be-processed interface, wherein executing the executable action script comprises publishing the to-be-processed 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 interface, the second interface information being used for displaying the to-be-processed 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 interface, publishing the to-be-processed interface to an open platform” or “generating second interface information corresponding to the to-be-processed interface, the second interface information being used for displaying the to-be-processed 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 the to-be-processed interface to be in the state of the plurality of states in response to the first operation instruction for the to-be-processed interface comprises:
in response to the interface editing instruction for the to-be-processed interface, editing an interface configuration parameter of the to-be-processed 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 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); and
wherein generating the second interface information corresponding to the to-be-processed interface, comprises: in response to the to-be-processed interface being in the to-be-reviewed state, generating the second interface information corresponding to the to-be-processed 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 interface, publishing the to-be-processed interface to an open platform” or “generating second interface information corresponding to the to-be-processed interface, the second interface information being used for displaying the to-be-processed 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 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 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 configuring the to-be-processed interface to be in the to-be-reviewed state comprises: after the editing action corresponding to the interface editing instruction is performed, testing the to-be-processed interface to obtain a test result; and in response to the test result being normal, configuring the to-be-processed 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.
and wherein the configuring the to-be-processed interface to be in the state of the plurality of states in response to the first operation instruction for the to-be-processed interface comprises: in response to the interface review instruction for the to-be-processed interface, displaying an interface configuration parameter of the to-be-processed 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 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); and
wherein publishing the to-be-processed interface to the open platform comprises: in response to the to-be-processed interface being in the to-be-published state, publishing the to-be-processed 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 interface, obtaining a 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 user, the review task information being used for prompting the user to review the to-be-processed 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 the state of the plurality of states of the to-be-processed interface, publishing the to-be-processed interface to an open platform” or “generating second interface information corresponding to the to-be-processed interface, the second interface information being used for displaying the to-be-processed 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 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, or 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 a method for interactive publication of an interface, the method comprising the steps.
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 result on the interactive page.
Prabhakar teaches displaying the test result 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 result 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.
Tremblay et al. (US 2022/0343250 A1)—Tremblay et al. discloses allowing the user to develop or write all of these API calls in the code (Para. 613).
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
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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.
01 September 2026
/Jeremy S Duffield/Primary Examiner, Art Unit 2498
Prosecution Insights