DETAILED ACTION
Claims 1-9 are pending in this application.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 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 1, 2, 4, 6 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over J.P. No. 2018081431 A to Hideyuki et al. in view of U.S. Pub. No. 20140280703 A1 to Vaks et al.
As to claim 1, Hideyuki teaches an API management system comprising:
a processor (processing units/processing means) and
a memory (memory); and
an API processing time estimation unit (API management system 1/Estimated API Processing Unit 17) that acquires information of an execution request (processing request) of an API, estimates a required time required for a predetermined information processing apparatus to execute the API in response to the information of the execution request of the API (the processing time required for executing the program part related to the processing request) by analyzing a processing content of the API indicated by the information of the execution request of the API (the request processing unit for transmitting the execution result to the client computer and the processing time required for executing the program part related to the processing request A performance value management unit that manages the value as a value…According to the present invention, since the processing time required to execute the program part is managed as the actual value, the actual value can be used to help estimate the processing time of the program part to be executed in the future) (“…According to the present invention, since the processing time required to execute the program part is managed as the actual value, the actual value can be used to help estimate the processing time of the program part to be executed in the future…In the present embodiment, the actual value of the API processing time is managed by one or a plurality of methods to help estimate the processing time when the API is used in the future. Furthermore, in this embodiment, the total processing time can be estimated even when a plurality of APIs provided by a plurality of server computers whose internal states are black boxes are used. Furthermore, in this embodiment, it is determined whether or not the API processing time desired by the API user is in time for the time desired by the API user, and the determination result is notified. Further, in the present embodiment, API execution is controlled according to the determination result whether or not the desired time is met. The API execution control includes cancellation of API execution, adjustment of API execution timing, and the like.
A method in which the API management system 1 estimates the processing time of the API group under the management will be described with reference to FIGS…The estimation API processing unit 17 is an example of a “processing time estimation unit”. The estimation API processing unit 17 has a function of estimating the processing time of the designated API and outputting the estimation result. The API management system 1 has a function for estimating the API processing time as an estimation API. The API management system 1 discloses the estimated API to the client 3. When the client 3 designates an API for which the processing time is desired to be estimated and sends a request to the estimated API, the estimated API processing unit 17 estimates the processing time of the designated API using the estimated API. The estimated API estimates the time required for processing the designated API by referring to the API processing result value T1 for the designated API. The estimation API processing unit 17 transmits the estimation result as a response from the client communication unit 11 to the client 3. The estimation API processing unit 17 is configured by a computer program for estimation API processing for realizing the functions described above. A processing flow for estimating the processing time will be described later…”).
Hideyuki is silent with reference to determines a communication scheme used for transmitting a request for causing the predetermined information processing apparatus to execute the API to be either synchronous communication or asynchronous communication based on the estimated time.
Vaks teaches determines a communication scheme used for transmitting a request for causing the predetermined information processing apparatus to execute the API to be either synchronous communication or asynchronous communication based on the estimated time (Steps 302/303) (“…In step 303, one or more computing devices in the service platform 200 may determine whether the service request received in step 301 should be processed synchronously (i.e., may select synchronous processing mode) or asynchronously (i.e., may select asynchronous processing mode). For example, a computer server in the service bus 210 may perform the determination in step 303 based on the expected response time determined in step 302 for the service request. If the expected response time indicates that the service request is likely to be a short-running service request, then the service bus 210 may determine that the service request should be processed synchronously (303:Sync). In this case, the service bus 210 may route the service request to a synchronous processing infrastructure 240 in step 304, and may keep open the calling thread within the service bus 210. Alternatively, if the expected response time indicates that the service request is likely to be a long-running service request, then the service bus 210 may determine that the service request should be processed asynchronously (303:Async). In this case, the service bus 210 may route the service request to a messaging bus 220 and then asynchronous processing infrastructure 230 in steps 307-308, and may close the calling thread within the service bus 210… As discussed above, the determination in step 303 for a service request may be based on the expected response time of the service request. One or more computer servers within the service bus 210, or other devices in the service platform 200, may compare the expected response time of the service request to a response time threshold. If the expected response time is greater than the threshold (e.g., 1 second, 2 seconds, . . . , 5 seconds, etc.), then the service request will be designated for asynchronous processing (303:Async). Otherwise, the service request will be designated for synchronous processing (303:Sync). If the expected response time from step 302 is a percentile (e.g., fastest 10% of service requests, fastest 50% of service requests, etc.), or an enumerated value (e.g., very short running, short running, average, long running very long running, etc.), then the thresholds/comparisons in step 303 may be adjusted accordingly…” paragraphs 0039/0041).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Hideyuki with the teaching of Vaks because the teaching of Vaks would improve the system of Hideyuki by providing a technique for optimally executing computing tasks.
As to claim 2, Hideyuki teaches the API management system according to claim 1, wherein the API processing time estimation unit (Estimation API Processing Unit 17) estimates the required time based on a processing content of an API specified by information storing a relationship between a parameter characterizing the processing content of the API and a required time related to the API, and the acquired information of the execution request of the API (“…The estimation API processing unit 17 is an example of a “processing time estimation unit”. The estimation API processing unit 17 has a function of estimating the processing time of the designated API and outputting the estimation result. The API management system 1 has a function for estimating the API processing time as an estimation API. The API management system 1 discloses the estimated API to the client 3. When the client 3 designates an API for which the processing time is desired to be estimated and sends a request to the estimated API, the estimated API processing unit 17 estimates the processing time of the designated API using the estimated API. The estimated API estimates the time required for processing the designated API by referring to the API processing result value T1 for the designated API. The estimation API processing unit 17 transmits the estimation result as a response from the client communication unit 11 to the client 3. The estimation API processing unit 17 is configured by a computer program for estimation API processing for realizing the functions described above. A processing flow for estimating the processing time will be described later…”).
As to claim 4, Vaks teaches the API management system according to claim 1, wherein the API processing time estimation unit estimates the required time by analyzing information of a communication scheme specified by the information of the execution request of the API and information of a processing type (Steps 302/303) (“…In step 303, one or more computing devices in the service platform 200 may determine whether the service request received in step 301 should be processed synchronously (i.e., may select synchronous processing mode) or asynchronously (i.e., may select asynchronous processing mode). For example, a computer server in the service bus 210 may perform the determination in step 303 based on the expected response time determined in step 302 for the service request. If the expected response time indicates that the service request is likely to be a short-running service request, then the service bus 210 may determine that the service request should be processed synchronously (303:Sync). In this case, the service bus 210 may route the service request to a synchronous processing infrastructure 240 in step 304, and may keep open the calling thread within the service bus 210. Alternatively, if the expected response time indicates that the service request is likely to be a long-running service request, then the service bus 210 may determine that the service request should be processed asynchronously (303:Async). In this case, the service bus 210 may route the service request to a messaging bus 220 and then asynchronous processing infrastructure 230 in steps 307-308, and may close the calling thread within the service bus 210… As discussed above, the determination in step 303 for a service request may be based on the expected response time of the service request. One or more computer servers within the service bus 210, or other devices in the service platform 200, may compare the expected response time of the service request to a response time threshold. If the expected response time is greater than the threshold (e.g., 1 second, 2 seconds, . . . , 5 seconds, etc.), then the service request will be designated for asynchronous processing (303:Async). Otherwise, the service request will be designated for synchronous processing (303:Sync). If the expected response time from step 302 is a percentile (e.g., fastest 10% of service requests, fastest 50% of service requests, etc.), or an enumerated value (e.g., very short running, short running, average, long running very long running, etc.), then the thresholds/comparisons in step 303 may be adjusted accordingly…” paragraphs 0039/0041).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Hideyuki with the teaching of Vaks because the teaching of Vaks would improve the system of Hideyuki by providing a technique for optimally executing computing tasks.
As to claim 6, Vaks teaches the API management system according to claim 1, further comprising a UI function unit that receives an execution request of an API indicating a plurality of selectable communication schemes from another information processing apparatus, wherein the API processing time estimation unit estimates a required time required to execute the API based on the received execution request by analyzing a processing content of the API indicated by the execution request, and determines a communication scheme with the terminal regarding the API related to the execution request of the API from the plurality of communication schemes based on the estimated required time (Steps 302/303) (“…In step 303, one or more computing devices in the service platform 200 may determine whether the service request received in step 301 should be processed synchronously (i.e., may select synchronous processing mode) or asynchronously (i.e., may select asynchronous processing mode). For example, a computer server in the service bus 210 may perform the determination in step 303 based on the expected response time determined in step 302 for the service request. If the expected response time indicates that the service request is likely to be a short-running service request, then the service bus 210 may determine that the service request should be processed synchronously (303:Sync). In this case, the service bus 210 may route the service request to a synchronous processing infrastructure 240 in step 304, and may keep open the calling thread within the service bus 210. Alternatively, if the expected response time indicates that the service request is likely to be a long-running service request, then the service bus 210 may determine that the service request should be processed asynchronously (303:Async). In this case, the service bus 210 may route the service request to a messaging bus 220 and then asynchronous processing infrastructure 230 in steps 307-308, and may close the calling thread within the service bus 210… As discussed above, the determination in step 303 for a service request may be based on the expected response time of the service request. One or more computer servers within the service bus 210, or other devices in the service platform 200, may compare the expected response time of the service request to a response time threshold. If the expected response time is greater than the threshold (e.g., 1 second, 2 seconds, . . . , 5 seconds, etc.), then the service request will be designated for asynchronous processing (303:Async). Otherwise, the service request will be designated for synchronous processing (303:Sync). If the expected response time from step 302 is a percentile (e.g., fastest 10% of service requests, fastest 50% of service requests, etc.), or an enumerated value (e.g., very short running, short running, average, long running very long running, etc.), then the thresholds/comparisons in step 303 may be adjusted accordingly…” paragraphs 0039/0041).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Hideyuki with the teaching of Vaks because the teaching of Vaks would improve the system of Hideyuki by providing a technique for optimally executing computing tasks.
As to claim 9, Hideyuki teaches an API management method of causing an information processing apparatus to execute API processing time estimation processing comprising:
acquiring information of an execution request of an API (processing request); and
estimating a required time required for a predetermined information processing apparatus to execute the API in response to the information of the execution request of the API by analyzing a processing content of the API indicated by the information of the execution request of the API.
Hideyuki is silent with reference to determining a communication scheme used for transmitting a request for causing the predetermined information processing apparatus to execute the API to be either synchronous communication or asynchronous communication based on the estimated time (the request processing unit for transmitting the execution result to the client computer and the processing time required for executing the program part related to the processing request A performance value management unit that manages the value as a value…According to the present invention, since the processing time required to execute the program part is managed as the actual value, the actual value can be used to help estimate the processing time of the program part to be executed in the future) (“…According to the present invention, since the processing time required to execute the program part is managed as the actual value, the actual value can be used to help estimate the processing time of the program part to be executed in the future…In the present embodiment, the actual value of the API processing time is managed by one or a plurality of methods to help estimate the processing time when the API is used in the future. Furthermore, in this embodiment, the total processing time can be estimated even when a plurality of APIs provided by a plurality of server computers whose internal states are black boxes are used. Furthermore, in this embodiment, it is determined whether or not the API processing time desired by the API user is in time for the time desired by the API user, and the determination result is notified. Further, in the present embodiment, API execution is controlled according to the determination result whether or not the desired time is met. The API execution control includes cancellation of API execution, adjustment of API execution timing, and the like.
A method in which the API management system 1 estimates the processing time of the API group under the management will be described with reference to FIGS…The estimation API processing unit 17 is an example of a “processing time estimation unit”. The estimation API processing unit 17 has a function of estimating the processing time of the designated API and outputting the estimation result. The API management system 1 has a function for estimating the API processing time as an estimation API. The API management system 1 discloses the estimated API to the client 3. When the client 3 designates an API for which the processing time is desired to be estimated and sends a request to the estimated API, the estimated API processing unit 17 estimates the processing time of the designated API using the estimated API. The estimated API estimates the time required for processing the designated API by referring to the API processing result value T1 for the designated API. The estimation API processing unit 17 transmits the estimation result as a response from the client communication unit 11 to the client 3. The estimation API processing unit 17 is configured by a computer program for estimation API processing for realizing the functions described above. A processing flow for estimating the processing time will be described later…”).
Vaks teaches determining a communication scheme used for transmitting a request for causing the predetermined information processing apparatus to execute the API to be either synchronous communication or asynchronous communication based on the estimated time (Steps 302/303) (“…In step 303, one or more computing devices in the service platform 200 may determine whether the service request received in step 301 should be processed synchronously (i.e., may select synchronous processing mode) or asynchronously (i.e., may select asynchronous processing mode). For example, a computer server in the service bus 210 may perform the determination in step 303 based on the expected response time determined in step 302 for the service request. If the expected response time indicates that the service request is likely to be a short-running service request, then the service bus 210 may determine that the service request should be processed synchronously (303:Sync). In this case, the service bus 210 may route the service request to a synchronous processing infrastructure 240 in step 304, and may keep open the calling thread within the service bus 210. Alternatively, if the expected response time indicates that the service request is likely to be a long-running service request, then the service bus 210 may determine that the service request should be processed asynchronously (303:Async). In this case, the service bus 210 may route the service request to a messaging bus 220 and then asynchronous processing infrastructure 230 in steps 307-308, and may close the calling thread within the service bus 210… As discussed above, the determination in step 303 for a service request may be based on the expected response time of the service request. One or more computer servers within the service bus 210, or other devices in the service platform 200, may compare the expected response time of the service request to a response time threshold. If the expected response time is greater than the threshold (e.g., 1 second, 2 seconds, . . . , 5 seconds, etc.), then the service request will be designated for asynchronous processing (303:Async). Otherwise, the service request will be designated for synchronous processing (303:Sync). If the expected response time from step 302 is a percentile (e.g., fastest 10% of service requests, fastest 50% of service requests, etc.), or an enumerated value (e.g., very short running, short running, average, long running very long running, etc.), then the thresholds/comparisons in step 303 may be adjusted accordingly…” paragraphs 0039/0041).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Hideyuki with the teaching of Vaks because the teaching of Vaks would improve the system of Hideyuki by providing a technique for optimally executing computing tasks.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over J.P. No. 2018081431 A to Hideyuki et al. in view of U.S. Pub. No. 20140280703 A1 to Vaks et al. as applied to claim 1 above, and further in view of U.S. Pub. No. 2013/0326520 A1 to Demircioglu.
As to claim 7, Hideyuki as modified by Vaks teaches the API management system however it is silent with reference to a UI function unit that displays information of the determined communication scheme.
Demircioglu teaches a UI function unit (User Interface Component 114) that displays information of the determined communication scheme (“…Thus, when synchronous program 100 invokes a user interface thread, component 116 determines whether the program invoking the user interface thread is synchronous or asynchronous. If it is synchronous, then system 100 determines whether the user interface thread might be prematurely killed. If so, component 116, using component 114, generates an asynchronous user interface display and covers the synchronous user interface display generated by program 110. Component 116 then blocks the code in program 110 from further execution until the processing corresponding to the synchronous user interface thread has been completed. Then, component 116 removes the asynchronous user interface display, uncovering the synchronous user interface display generated by program 110, and component 116 unblocks program 110 so that it can continue processing. In this way, since the asynchronous user interface display is generated and covers the synchronous user interface display, system 100 will not kill the synchronous user interface display, since it is no longer precluding user inputs, because the asynchronous user interface display is covering it. Thus the processing corresponding to the synchronous user interface display has been completed, and the asynchronous user interface display is removed. Processing returns to the synchronous user interface display, and program 110 is unblocked so that it can continue its processing…” paragraph 0023).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Hideyuki and Vaks with the teaching of Demircioglu because the teaching of Demircioglu would improve the system of Hideyuki and Vaks by providing a graphical user interface for displaying information for user consumption.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over J.P. No. 2018081431 A to Hideyuki et al. in view of U.S. Pub. No. 20140280703 A1 to Vaks et al. as applied to claim 1 above, and further in view of U.S. Pub. No. 2015/0095923 A1 to Sand.
As to claim 8, Hideyuki as modified by Vaks teaches the API management system however it is silent with reference to a UI function unit that displays an input screen for accepting an input of a processing content of the API in the information of the execution request of the API from a user.
Sand teaches a UI function unit that displays an input screen for accepting an input of a processing content of the API in the information of the execution request of the API from a user (“…As also shown in FIG. 2, API notebook tool 202 includes an API specification processing engine 210 (e.g., to parse and interpret an API specification, as further described herein), an API client generation engine 212 (e.g., to dynamically generate API clients based on the API specification and a request for a client for calling an API for a service, as further described herein), an API help generation engine 214 (e.g., to generate help API clients based on the API specification and a request for a client for calling an API for a service), and a user interface processing component 220 (e.g., for processing user input for user requests submitted to the API notebook tool, for generating user output in response to the user requests, and/or for processing various configuration input and/or user authorization verifications, as further described herein). The processing performed by each of these components is further described below. In some implementations, one or more of these functions can be performed by another device or function such that the API specification processing and/or the user interface processing can be performed using another device or function, which can provide respective input to the API notebook tool. As another example implementation, various components can be implemented as a common component, such as the API client generation engine that can be implemented to also perform the API specification processing…” paragraph 0043).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Hideyuki and Vaks with the teaching of Vaks because the teaching of Vaks would improve the system of Hideyuki and Vaks by providing a graphical user interface for displaying information for user consumption.
Allowable Subject Matter
Claims 3 and 5 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Reasons for Allowance
The following is an examiner’s statement of reasons for allowance:
The closest prior art of records, (J.P.O No. 2018081431 A to Hideyuki et al. and of U.S. Pub. No. 20140280703 A1 to Vaks et al.), taken alone or in combination do not specifically disclose or suggest the claimed recitations (claims 3 and 5), when taken in the context of claims as a whole.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Pat. No. 11,842,224 B1 issued to Sharfi and directed to synchronous and asynchronous responses to data requests from remote devices.
U.S. Pub. No. 2019/0268442 A1 to Punani et al. and directed to systems and methods of implementing rate limiting in a representational state transfer (REST) application programming interface (API) system.
U.S. Pat. No. 9,300,759 B1 issued to Jorgensen and directed to API calls with dependencies.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLES E ANYA whose telephone number is (571)272-3757. The examiner can normally be reached Mon-Fir. 9-6pm.
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, KEVIN YOUNG can be reached at 571-270-3180. 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.
/CHARLES E ANYA/Primary Examiner, Art Unit 2194