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 .
This action is responsive to the communication filed 9/20/2023.
Claims 1-20 are presented for examination.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirely as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-6, 8-13 and 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over Sagar (US 11734265 B1) in view of Sun (CN 100479366 C, English translation provided by Google Patents).
Regarding to claim 1, Sagar discloses: A method (see lines 60-62 of col. 4 and claim 1; “the process may be performed by one or more processors of the GraphQL server 202 executing code comprising the components therein” and “A method for API management by a GraphQL server”) comprising:
receiving, at an application programming interface (API) of a middle-tier platform, an initial API method call including a request identifier associated with a processing request and a data parameter (see Fig. 2 and lines 55-60 of col. 2; “The GraphQL API gateway 116 receives the GraphQL API query requests 112 (also referred to as requests 112) from the clients 104. The requests 112 may comprise query payloads that specify an operation name, the variables and fields whose values are to be retrieved (e.g., an application/JSON content type and a JSON-encoded body)”);
writing the data parameter and the request identifier to a record of a datastore (see Fig. 2, lines 37-40 of col. 4; “The query log 210 saves the GraphQL API requests 112 made on a particular GraphQL API 110 by various clients 104 over some predetermined time period (e.g., the last N days/weeks/months)”. Note: according to lines 55-60 of col. 2, each of the requests 112 received would include payload of operation name as claimed request identifier and variables or fields as claimed data parameter, and thus saving such requests 112 discussed at lines 37-40 of col. 4 is reasonable to be considered as including saving or writing the data parameters and request identifier of the received requests 112);
executing, by a first intermediary processing procedure, a query of the datastore, wherein the query of the datastore retrieves the record of the datastore (see lines 37-47 of col. 4; “The impact service 212 uses the query log 210 to estimate any potential impact due to change of field names using predefined metrics and to compile a list the client IDs impacted”. It is understood to one with ordinary skill in the art that use query log 210 to perform the functions discussed at lines 37-47 of col. 4 would include at least a query of the query log 210 to retrieve details of the information associated with saved requests 112”);
performing, by a second intermediary processing procedure, additional intermediary processing (see Fig. 2, lines 62-3 of cols. 2-3 and lines 33-44 of col. 7; “The validation service 118 validates the request 112 by retrieving the schema defining the GraphQL API from the schema store 120 and verifying the syntactic structure and field names in the request 112 against the schema. Once the query payload is validated, the validation service 118 calls the resolution service 122” and “If the request validation service 218 determines that some fields names in the request payload don't match the schema 121 … the request validation service 218 looks up the new field names in the field mapper 208, which stores the mapping of old field names and new field names as values and an identifier of the GraphQL API as a key. The request validation service 218 then updates the payload of the API request 112”);
making a secondary API call to a backend system (see Fig. 2, lines 66-3 of cols. 2-3 and lines 46-55 of col. 7; “Once the query payload is validated, the validation service 118 calls the resolution service 122, which uses the field resolvers 124 associated with the fields in the query to fetch the data from the corresponding data source 106”, “The request validation service 218 passes the updated API request to the resolution service 122, which knows all the field resolvers 224 mapped to the various fields in the API request. The resolution service 122 takes in the updated API request and calls the field resolvers 224 assigned to the respective fields in the updated API request … it is able to fetch the corresponding field name from the data source 106”);
receiving a second data parameter from the backend system in response to the secondary API call (see Fig. 2, lines 66-3 of cols. 2-3; lines 54-57 of col. 7; “uses the field resolvers 124 associated with the fields in the query to fetch the data from the corresponding data source 106”, “Since the original field in the updated API request has been made the alias, the field resolver 224 is called on the new field name and it is able to fetch the corresponding field name from the data source 106. The request validation service 218 collects the field values obtained by the field resolver 224 from the data source 106”); and
generating a response to the processing request (see Fig. 2, lines 66-8 of cols. 2-3 and lines 56-58 of col. 7; “combines the retrieved data as defined in the schema, and returns a response 114 to the GraphQL API gateway 116” and “The request validation service 218 collects the field values obtained by the field resolver 224 from the data source 106 and returns as response to the GraphQL API gateway 116”).
Sagar does not disclose:
wherein the record of the datastore includes a batch field;
writing a value of false to the batch field;
However, Sun discloses: wherein the record of the data[store] includes a batch field; writing a value of false to the batch field (see 2nd paragraph of page 16; “The data acquisition response message is shown in Table 15, which includes data encoding, data content, total batch number and completion flag (Completion-Flag). If it is not the last batch of data, set the result flag to False, otherwise set the result flag to True”. A batch of data/record includes a batch completion flag to indicate whether a last batch of data is reached or not).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the process of saving and retrieving API requests at query log for further processes from Sagar by including a batch completion flag to indicate last batch data from Sun, and thus the combination of Sagar and Sun would disclose the missing limitations from Sagar, since it would provide a clear mechanism to know whether the corresponding data is last data to be saved or retrieved (see 2nd paragraph of page 16 from Sun).
Regarding to Claim 2, the rejection of Claim 1 is incorporated and further the combination of Sagar and Sun discloses: wherein the first intermediary processing procedure is a batch process (see lines 37-47 of col. 4 from Sagar; “The query log 210 saves the GraphQL API requests 112 made on a particular GraphQL API 110 by various clients 104 over some predetermined time period (e.g., the last N days/weeks/months). The impact service 212 uses the query log 210 to estimate any potential impact due to change of field names using predefined metrics and to compile a list the client IDs impacted. The notification service 222 creates a notification message 226 containing the estimated metrics and the list of client IDs, and sends the notification message 226 to an admin for the GraphQL API as notification of the potential impact of the field name change”. The usage of query log 210 to determine potential impact and notify the result of determination are performed for batch of API requests from clients over predetermined time period, and thus such intermediary processing procedure is a batch process).
Regarding to Claim 3, the rejection of Claim 2 is incorporated and further the combination of Sagar and Sun discloses: wherein the first intermediary processing procedure updates the batch field to a value of true before completing execution (see lines 37-47 of col. 4 from Sagar and 2nd paragraph of page 16 from Sun; “The query log 210 saves the GraphQL API requests 112 made on a particular GraphQL API 110 by various clients 104 over some predetermined time period (e.g., the last N days/weeks/months). The impact service 212 uses the query log 210 to estimate any potential impact due to change of field names using predefined metrics and to compile a list the client IDs impacted” and “completion flag (Completion-Flag). If it is not the last batch of data, set the result flag to False, otherwise set the result flag to True”. After retrieving last corresponding batch data, i.e., last API request of predetermined time period but before performing the estimation of any potential impact (i.e., before completing the first intermediary processing procedure), the completion flag is updated to true to indicate last batch data or last API request is retrieved for further processed).
Regarding to Claim 4, the rejection of Claim 1 is incorporated and further the combination of Sagar and Sun discloses: wherein the query of the datastore includes the request identifier and the value of false to the batch field as lookup parameters of the query (see 2nd paragraph of page 16 from Sun, lines 55-60 of col. 2 and lines 37-40 of col. 4 from Sagar; “The data acquisition response message is shown in Table 15, which includes data encoding, data content, total batch number and completion flag (Completion-Flag). If it is not the last batch of data, set the result flag to False, otherwise set the result flag to True”. The completion flag as lookup parameters of the query to determine whether the query is completed or not. As explained at the rejection of claim 1 above, the API requests saved to query log 210 contains operation name, i.e., claimed request identifier as the content for the API requests, and thus the data content from Sun at the combination system is the request identifier of the corresponding API request).
Regarding to Claim 5, the rejection of Claim 1 is incorporated and further the combination of Sagar and Sun discloses: wherein the initial API method call is received from a user interface (see Figs. 2, 4, lines 55-56 of col. 2 and lines 58-66 of col. 9 from Sagar; “receives the GraphQL API query requests 112 (also referred to as requests 112) from the clients 104” and “each of the clients is implemented in a separate one of the electronic devices 400 (e.g., in end user devices where the software 428 represents the software to implement clients to interface directly and/or indirectly with the automatic GraphQL data source field change handler service (e.g., software 428 represents a web browser”). Note: it is understood that a web browser is a user interface).
Regarding to Claim 6, the rejection of Claim 5 is incorporated and further the combination of Sagar and Sun discloses: wherein a user interface object is associated with the initial API method call (see Figs. 2, 4, lines 55-56 of col. 2 and lines 58-66 of col. 9 from Sagar; “receives the GraphQL API query requests 112 (also referred to as requests 112) from the clients 104” and “each of the clients is implemented in a separate one of the electronic devices 400 (e.g., in end user devices where the software 428 represents the software to implement clients to interface directly and/or indirectly with the automatic GraphQL data source field change handler service (e.g., software 428 represents a web browser”). Using a web browser of a client device to send initial API request to the gateway, then there must be a web browser object is associated with the initial API request).
Regarding to Claim 8, Claim 8 is a system claim corresponds to method Claim 1 and is rejected for the same reason set forth in the rejection of Claim 1 above (note: see Fig. 4A, lines 49-56 of col. 9 from Sagar to teach limitations related to “at least one computer including a processor, wherein the at least one computer is configured to”).
Regarding to Claim 9, Claim 9 is a system claim corresponds to method Claim 2 and is rejected for the same reason set forth in the rejection of Claim 2 above.
Regarding to Claim 10, Claim 10 is a system claim corresponds to method Claim 3 and is rejected for the same reason set forth in the rejection of Claim 3 above.
Regarding to Claim 11, Claim 11 is a system claim corresponds to method Claim 4 and is rejected for the same reason set forth in the rejection of Claim 4 above.
Regarding to Claim 12, Claim 12 is a system claim corresponds to method Claim 5 and is rejected for the same reason set forth in the rejection of Claim 5 above.
Regarding to Claim 13, Claim 13 is a system claim corresponds to method Claim 6 and is rejected for the same reason set forth in the rejection of Claim 6 above.
Regarding to Claim 15, Claim 15 is a product claim corresponds to method Claim 1 and is rejected for the same reason set forth in the rejection of Claim 1 above (note: see Fig. 4A, lines 49-56 of col. 9 from Sagar to teach limitations related to “non-transitory computer readable storage medium … cause the one or more computer processors to perform steps”).
Regarding to Claim 16, Claim 16 is a product claim corresponds to method Claim 2 and is rejected for the same reason set forth in the rejection of Claim 2 above.
Regarding to Claim 17, Claim 17 is a product claim corresponds to method Claim 3 and is rejected for the same reason set forth in the rejection of Claim 3 above.
Regarding to Claim 18, Claim 18 is a product claim corresponds to method Claim 4 and is rejected for the same reason set forth in the rejection of Claim 4 above.
Regarding to Claim 19, Claim 19 is a product claim corresponds to method Claim 5 and is rejected for the same reason set forth in the rejection of Claim 5 above.
Claims 7, 14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Sagar (US 11734265 B1) in view of Sun (CN 100479366 C, English translation provided by Google Patents) and further in view of Jones et al. (US 9647889 B1, hereafter Jones).
Regarding to Claim 7, the rejection of Claim 6 is incorporated, the combination of Sagar and Sun does not disclose: wherein a user activation of the user interface object initiates the initial API method call.
However, Jones discloses: wherein a user activation of the user interface object initiates the initial API method call (see lines 2-11 of col. 7; “The management console may be exposed to the customers as a webpage, by interacting with the webpage (e.g., through a browser application) the customer may cause API calls to be generated”. The corresponding browser objection related to API call generation is active by user to cause API calls to be generated).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify API request generation from the combination of Sagar and Sun by including interacting with a webpage using a browser to generate API calls to resource service provider from Jones, and thus the combination of Sagar, Sun and Jones would disclose the missing limitations from the combination of Sagar and Sun, since it would provide a more detail method to generate API calls via a browser application (see lines 2-11 of col. 7).
Regarding to Claim 14, Claim 14 is a system claim corresponds to method Claim 7 and is rejected for the same reason set forth in the rejection of Claim 7 above.
Regarding to Claim 20, Claim 20 is a product claim corresponds to method Claims 6 and 7 and is rejected for the same reason set forth in the rejection of Claims 6-7 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Tosmur (US 20210233163 A1) discloses: one or more API calls, code invocation which can be initiated by directly a browser (see [0292]).
Brown (US 20180322213 A1) discloses: The entry of the search string into the address bar causes the browser to programmatically initiate the search by the browser formulating the programmatic call to an API (Application Programming Interface) of the search engine (such as Google) (see [0096]).
Hatoun (US 20060069605 A1) discloses: payload of the request is saved (see [0056]).
Barbour et al. (US 20170053336 A1) discloses: If the job is still being processed the salesman process 504 may return a “false” indicator indicating the job is not complete while if the job is complete and the scoring data for the job available, a “true” indicator may be returned (see [0082]).
Thakadu et al. (US 20140237594 A1) discloses: the data expiry unit may store the API call names and API call parameters (e.g., input variables, source IP address, destination IP address, user ID, etc.) up to a time period (see [0017]).
Devarao et al. (US 20190163759 A1) discloses: a middle tier system as an intermediary between clients and database system receives requests from clients and uses such received requests to generate one or more requests to database system (see [0023]).
Yao (US 20190129938 A1) discloses: a first API as a trigger API to trigger two different action APIs (see [0024] and [0048]).
Thompson (US 20160301739 A1) discloses: execution of a second backend API may depend on the outcome results received from the execution of a first backend API (see [0055]).
Nelson et al. (US 10970048 B2) discloses: interfacing with the first information flow object via a front-end application programing interface (API) and interfacing with the second information flow object via a back-end API (see claim 1).
Nelson et al. (US 20210208853 A1) discloses: executing a first set of functions of the front-end API, wherein the first set of functions asynchronously call for an execution of the first information flow object; executing a second set of functions of the back-end API, wherein the second set of functions asynchronously call for an execution of the second information flow object (see claim 1).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZHI CHEN whose telephone number is (571)272-0805. The examiner can normally be reached on M-F from 9:30AM to 5:30PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Y Blair can be reached on 571-270-1014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR to authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/Zhi Chen/
Patent Examiner, AU2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196