DETAILED ACTION
Claims 1-20 are pending.
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 § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The following claim language is unclear:
As per claim 1, line 8-11 recite “the first agent being programmed to monitor usage of a first cloud environment resource by a first integration flow of the plurality of integration flows and of a second integration flow of the plurality of integration flows” then lines 17-19 recite “accessing second resource usage data generated by the second agent and describing use of the second cloud environment resource by the second integration flow”. It is unclear from the context of the claim what is the relationship between the first and second agent. From the claim language it seems like the first agent monitors both the first and second integration flow but then the second resource usage is generated by the second agent. Is the monitored data from the first passed over to a second agent? How does the resource usage data generated by the second agent relate to the monitored usage done by the first agent? What is the role of the second agent?
Claim 1, line 17 recites “the second agent” this limitation lacks sufficient antecedent basis in the claim. Further, the limitation render the claim indefinite as it is not clear how the second agent works with the first agent. Further clarification is required.
Claims 2-9 are dependent on claim 1 and fail to cure the deficiencies set forth above for claim 1. Therefore, it is rejected under the same rationale above.
Claim 10 recites a method type claim having similar limitations as claim 1 above. Therefore, it is rejected under the same rationale above.
Claims 11-18 are dependent on claim 10 and fail to cure the deficiencies set forth above for claim 10. Therefore, it is rejected under the same rationale above.
Claim 19 recites a media/product type claim having similar limitations as claim 1 above. Therefore, it is rejected under the same rationale above.
Claim 20 is dependent on claim 19 and fail to cure the deficiencies set forth above for claim 19. Therefore, it is rejected under the same rationale above.
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kolev et al. (US 11,601,326 B1) in view of Bougon et al. (US 2021/0142254 A1).
Kolev and Bougon were cited in the previous Office Action.
Regarding claim 1, Kolev teaches an integration platform system (Fig. 9, Platform 900; Col. 2, lines 28-35: Integration system) comprising:
at least one computing device implementing a cloud environment (Col. 1, lines 1-2: a cloud computing environment), the at least one computing device being programmed to execute:
an integration runtime, the integration runtime being configured to run a plurality of integration flows associated with a first tenancy at the cloud environment, a first integration flow of the plurality of integration flows configured to interface at least one message between a first software component and a second software component (Col. 2, lines 43-55: As used herein, an “integration flow” refers to a software instance for integrating multiple applications via message passing. Referring to FIG. 1, integration flow 105 may be defined by a tenant (i.e., a customer of integration middleware) in a multi-tenant cloud computing environment to specify how messages are integrated between systems such as, for example, the sender system 110 (e.g., a system of a buyer executing an application that submits a purchase order using a first communication protocol) and the receiver system 115 (e.g., a system of a seller executing an application that receives the purchase order using a second communication protocol). In some embodiments, each tenant may have multiple integration flows.; Col. 5, lines 29-32: Architecture or framework 400 includes an example of a productive tenant 405 having defined a number of integration flows 410 that integrate multiple applications (not shown)).
Kolev teaches a monitor system that is able to “detect an anomaly or problem in applications currently executing in a distributed computing environment. For example, the provider might restart, provide additional computing resources to, for example, applications or other remedies in response to a detected anomaly or problem to improve performance.” (Col. 1, lines 26-31). Further, “a monitoring system and process herein may evaluate a rate of successfully processed messages, per integration flow.” (Col. 3, lines 29-31). Lastly, Kolev teaches “FIG. 8 is an outward-facing user interface related to a system and process for detection and characterization of integration flows, in accordance with an example embodiment. FIG. 8 is a human-machine interface display 800 in accordance with some embodiments. The display 800 includes a graphical representation 805 or dashboard that might be used to manage or monitor a problem detection and characterization of integration flows (e.g., associated with a multi-tenant cloud provider).” (Col. 8, lines 28-36)
Kolev does not expressly teach a first agent associated with the integration runtime, the first agent being programmed to monitor usage of a first cloud environment resource by a first integration flow of the plurality of integration flows and of a second integration flow of the plurality of integration flows; and
an integration inspect service, the integration inspect service being programmed to perform operations comprising:
accessing first resource usage data generated by the first agent and describing use of the first cloud environment resource by the first integration flow;
accessing second resource usage data generated by the second agent and describing use of the second cloud environment resource by the second integration flow; and
serving, to a user computing device, a user interface based at least in part on the first resource usage data.
However, Bougon teaches a first agent associated with the integration runtime, the first agent being programmed to monitor usage of a first cloud environment resource by a first integration flow [software application service] of the plurality of integration flows [software application services] and of a second integration flow of the plurality of integration flows ([0006]; [0022]; [0033] A cost-to-serve service (CTS) module 105 is configured and implemented with each of the resources to spawn a plurality of CTS agents 107 to each resource, input, controller etc. to monitor and to run on every public cloud hardware host, collect service usage statistics for every service (i.e., integration flow) and instance in use and send these metrics to the Cost-To-Serve Service module 105 to determine real-time usage and costs of the deployed resources in the configured pod architecture…Each CTS agent 107 receives data to send for processing by the CTS service module 105 and for storing at a CTS metric database 110.; Fig. 2; [0034] The CTS framework 200 enables an analysis of cost attribution across multiple customers and multiple applications, services, and features; [0035] The CTS analytics display 220 receives data from a CTS service 205, which includes components or a graphic APIs 207 for a CTS store 210, the transaction processor 215, APIs 217 for alerts stores 225, alert processors 230, and APIs 227 for metric stores 235 with CTS metric processors 240. The CTS metrics processors 240 aggregate metrics from the CTS Store 210 for cost attribution (organization, user, persona, cloud, feature, etc.).; [0036] In this case, the distributed streaming platform 231 is an APACHE® KAFKA® platform for processing and assessing events in real-time from each of the CTS agents 249. The CTS agents 249 include service#1 (250), service#2 (255) to Service #n (260). The CTS agents 249 are distributed to each resource to monitor and send data of instances 1 to N from each resource. ); and
an integration inspect service, the integration inspect service being programmed to perform operations comprising:
accessing first resource usage data generated by the first agent and describing use of the first cloud environment resource by the first integration flow ([0033] Each CTS agent 107 receives data to send for processing by the CTS service module 105 and for storing at a CTS metric database 110. The data sent is analyzed and displayed by a CTS analytics engine 120.; [0037]; Fig. 2, shows CTS agents associated with each of the APIs 207, 217, and 227 at each runtime 205; Fig. 9);
accessing second resource usage data generated by the second agent and describing use of the second cloud environment resource by the second integration flow ([0033] Each CTS agent 107 receives data to send for processing by the CTS service module 105 and for storing at a CTS metric database 110. The data sent is analyzed and displayed by a CTS analytics engine 120.; [0037]; Fig. 2, shows CTS agents associated with each of the APIs 207, 217, and 227 at each runtime 205; Fig. 9); and
serving, to a user computing device, a user interface based at least in part on the first resource usage data ([0033] Each CTS agent 107 receives data to send for processing by the CTS service module 105 and for storing at a CTS metric database 110. The data sent is analyzed and displayed by a CTS analytics engine 120.; Fig. 9; [0043] Additionally, a processing system 920 runs loads 915 to measure and produce the CTS metrics 920 as instructed by instructions in memory 922. The processing system 920 uses a processor configured for metric processing 925 and implements various CTS models 930. The results are displayed by an analysis engine 935 that, via a user interface, can display multiple CTS analytics in a dashboard.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Bougon with the teachings of Kolev to spawn agents on each cloud resource to monitor metrics such as costs, storage, IOPS, etc. for a given service deployed on a cloud in a multi-tenant environment. The modification would have been motivated by the desire of allowing users of services to review resource usage patterns of their hosted services.
Regarding claim 2, Kolev teaches integration flow of the plurality of integration flows (Col. 2, lines 43-55: As used herein, an “integration flow” refers to a software instance for integrating multiple applications via message passing.).
In addition, Bougon teaches the at least one computing device being further programmed to execute a second agent associated with the integration runtime, the second agent being programmed to monitor usage of a second cloud environment resource by the at least one integration flow [software application service] of the plurality of integration flows [software application services], the user interface also being based at least in part on second resource usage data generated by the second agent ([0006]; [0022]; [0033] A cost-to-serve service (CTS) module 105 is configured and implemented with each of the resources to spawn a plurality of CTS agents 107 to each resource, input, controller etc. to monitor and to run on every public cloud hardware host, collect service usage statistics for every service (i.e., integration flow) and instance in use and send these metrics to the Cost-To-Serve Service module 105 to determine real-time usage and costs of the deployed resources in the configured pod architecture…Each CTS agent 107 receives data to send for processing by the CTS service module 105 and for storing at a CTS metric database 110. The data sent is analyzed and displayed by a CTS analytics engine 120.; Fig. 9; [0043] Additionally, a processing system 920 runs loads 915 to measure and produce the CTS metrics 920 as instructed by instructions in memory 922. The processing system 920 uses a processor configured for metric processing 925 and implements various CTS models 930. The results are displayed by an analysis engine 935 that, via a user interface, can display multiple CTS analytics in a dashboard.).
Regarding claim 3, Kolev teaches further programmed to execute:
a multitenant service, the multitenant service being programmed to provide a service to at least one executable at the first tenancy and at least one executable at a second tenancy at the cloud environment (Col. 2, lines 40-50 Referring to FIG. 1, integration flow 105 may be defined by a tenant (i.e., a customer of integration middleware) in a multi-tenant cloud computing environment to specify how messages are integrated between systems such as, for example, the sender system 110 (e.g., a system of a buyer executing an application that submits a purchase order using a first communication protocol) and the receiver system 115 (e.g., a system of a seller executing an application that receives the purchase order using a second communication protocol). In some embodiments, each tenant may have multiple integration flows.). and at least one integration flow of the plurality of integration flows (Col. 2, lines 43-55: As used herein, an “integration flow” refers to a software instance for integrating multiple applications via message passing ; Col. 5, lines 29-32: Architecture or framework 400 includes an example of a productive tenant 405 having defined a number of integration flows 410 that integrate multiple applications (not shown)).
In addition, Bougon teaches a multitenant service agent, the multitenant service agent being programmed to monitor usage of the multitenant service by at least one integration flow of the plurality of integration flows [software instances] ([0006] systems implementing cost-to-serve agents, which are executed on hosted public cloud hardware and collect service usage statistics in a multi-tenant environment.).
Regarding claim 4, Kolev teaches at least one integration flow of the plurality of integration flows (Col. 2, lines 43-55: As used herein, an “integration flow” refers to a software instance for integrating multiple applications via message passing ; Col. 5, lines 29-32: Architecture or framework 400 includes an example of a productive tenant 405 having defined a number of integration flows 410 that integrate multiple applications (not shown)).
In addition, Bougon teaches the integration inspect service being further programmed to perform operations comprising accessing multitenant service resource usage data generated by the multitenant service agent and describing use of the multitenant service by the at least one integration flow [software instance] of the plurality of integration flows, the user interface also being based at least in part on the multitenant service resource usage data (Abstract: a CTS agent transaction module to publish a set of metrics established by the CTS agent for each instance and usage type; [0028]; [0033] metrics database).
Regarding claim 5, Bougon teaches the first agent being programmed to perform operations comprising writing the first resource usage data to an intermediate storage at the cloud environment, and the integration inspect service being further programmed to perform operations comprising accessing the first resource usage data from the intermediate storage ([0033] Each CTS agent 107 receives data to send for processing by the CTS service module 105 and for storing at a CTS metric database 110. The data sent is analyzed and displayed by a CTS analytics engine 120.).
Regarding claim 6, Kolev teaches the integration inspect service being further programmed to perform operations comprising:
determining that the first resource usage data describes use of the first cloud environment resource by the first integration flow that does not meet a threshold usage (Col 4, line 50 through Col. 5, line 11: In some aspects, the present disclosure refers to a detection of a “significant” increase of failed messages. Some embodiments herein are related to and concerned with increases in failed messages of integration flows that are impactful to the operation of the integration flows. Accordingly, the term “significant” increase of failed messages is analogous to an “impactful” increase in failed messages that negatively affects an integration flow. For example, embodiments herein might not be interested in or concerned with the failure of individual messages since, for example, a failure of 1 out of 100 messages is not significant to impact or disrupt the operation of an integration flow (even though the failed message will have to be resent). However, 40 out of 100 messages indicating a service is unreachable might compromise an integration flow to the extent that it no longer functions at an acceptable level. In some embodiments, an increase in failed messages after an event of about at least 20% relative to failed messages in a reference interval before the event is indicative of the event causing a problem. In some other embodiments, an increase in failed messages after an event of about at least 40% relative to failed messages in a reference interval before the event is indicative of the event triggering the creation of a problem. In some embodiments, the value of 40% might be selectively adjusted, based on, for example, a desired quality of service for a particular integration flow. For example, in a use case where every message is considered important for a particular integration flow, a threshold of 2% might be set for that integration flow, or for the tenant.); and
sending, via the user interface, an alert to the user computing device, the alert describing at least one of the first cloud environment resource and the first integration flow (FIG. 8 is an outward-facing user interface related to a system and process for detection and characterization of integration flows, in accordance with an example embodiment. FIG. 8 is a human-machine interface display 800 in accordance with some embodiments. The display 800 includes a graphical representation 805 or dashboard that might be used to manage or monitor a problem detection and characterization of integration flows (e.g., associated with a multi-tenant cloud provider). In particular, selection of an element (e.g., an integration flow via a touchscreen or computer mouse pointer 810) might result in the display of a popup window that contains configuration data. Display 800 may also include a user selectable “Edit System” icon 815 to request system changes (e.g., to investigate problems associated with integration or improve system performance).).
Regarding claim 7, Kolev teaches integration platform system of claim 1, the integration inspect service being further programmed to perform operations comprising:
determining that the first resource usage data describes use of the first cloud environment resource by the first integration flow that does not meet a threshold usage (Col. 4, lines 3-6: As an example, event 205 might correspond to a middleware software update, where the software was executing properly and); and
responsive to determining that the first resource usage data describes use of the first cloud environment resource by the first integration flow that does not meet a threshold usage, modifying, at least one parameter of the first integration flow (Col. 4, lines 3-19: the middleware software was updated at some point in time (i.e., the event). An analysis of message states after the software update event during a current interval of time can be compared to an analysis of message states during an interval of time before the software update (i.e., during a reference interval), to determine whether message failures increased significantly after the software update event. Note that this message state analysis may be performed for each integration flow. In the instance the message failures after the software update event significantly increased relative to the failed messages in the reference interval before the software update event, then the software update event can be deemed to have caused the problem for some reason (not yet determined). As illustrated by this example, the event is not static.).
Regarding claim 8, Kolev teaches the integration inspect service being further programmed to perform operations comprising:
providing, via the user interface, a first screen displaying usage of first cloud environment resource during a first time period, the first screen comprising a user interface element; receiving, an indication that the user interface element has been selected; and responsive to the indication that the user interface element has been selected, providing, via the user interface, a second screen displaying usage of the first cloud environment resource by the first integration flow over the first time period and usage of the first cloud environment resource by a second integration flow over the first time period (Col. 8, lines 28-42: FIG. 8 is an outward-facing user interface related to a system and process for detection and characterization of integration flows, in accordance with an example embodiment. FIG. 8 is a human-machine interface display 800 in accordance with some embodiments. The display 800 includes a graphical representation 805 or dashboard that might be used to manage or monitor a problem detection and characterization of integration flows (e.g., associated with a multi-tenant cloud provider). In particular, selection of an element (e.g., an integration flow via a touchscreen or computer mouse pointer 810) might result in the display of a popup window that contains configuration data. Display 800 may also include a user selectable “Edit System” icon 815 to request system changes (e.g., to investigate problems associated with integration or improve system performance).).
Regarding claim 9, Bougon teaches the first cloud environment resource being at least one of a memory resource, a network resource, a database resource, and a central processing unit (CPU) resource ([0063]).
Regarding claim 10, it is a method type claim having similar limitations as claim 1 above. Therefore, it is rejected under the same rationale above.
Regarding claim 11, it is a method type claim having similar limitations as claim 2 above. Therefore, it is rejected under the same rationale above.
Regarding claim 12, it is a method type claim having similar limitations as claim 3 above. Therefore, it is rejected under the same rationale above.
Regarding claim 13, it is a method type claim having similar limitations as claim 4 above. Therefore, it is rejected under the same rationale above.
Regarding claim 14, it is a method type claim having similar limitations as claim 5 above. Therefore, it is rejected under the same rationale above.
Regarding claim 15, it is a method type claim having similar limitations as claim 6 above. Therefore, it is rejected under the same rationale above.
Regarding claim 16, it is a method type claim having similar limitations as claim 7 above. Therefore, it is rejected under the same rationale above.
Regarding claim 17, it is a method type claim having similar limitations as claim 8 above. Therefore, it is rejected under the same rationale above.
Regarding claim 18, it is a method type claim having similar limitations as claim 9 above. Therefore, it is rejected under the same rationale above.
Regarding claim 19, it is a media/product type claim having similar limitations as claim 1 above. Therefore, it is rejected under the same rationale above.
Regarding claim 10, it is a method type claim having similar limitations as claim 3 above. Therefore, it is rejected under the same rationale above.
Response to Arguments
Applicant's arguments filed on 05/13/2026 have been fully considered but they are not persuasive.
In Remarks Applicant argues:
Bougon does not teach or suggest monitoring multiple components executed within a single runtime […] The “services” and “instances” of Bougon, however, are not components that exist within a common runtime.
In view of the above, examiner submits the following
As to point (II)
Examiner respectfully disagrees with the Applicant. Bougon as remapped refers to Fig. 2 and its corresponding description. For instance, Bougon teaches a CTS Framework 205 which abstracts determining the actual cost to serve at each runtime. In [0035] Bougon teaches “The CTS analytics display 220 receives data from a CTS service 205, which includes components or a graphic APIs 207 for a CTS store 210, the transaction processor 215, APIs 217 for alerts stores 225, alert processors 230, and APIs 227 for metric stores 235 with CTS metric processors 240. The CTS metrics processors 240 aggregate metrics from the CTS Store 210 for cost attribution (organization, user, persona, cloud, feature, etc.).”
[0036] The transaction processor 215, the alert processor 230, and the CTS metrics processor 240 are configured to interface with a distributed streaming platform 231. In this case, the distributed streaming platform 231 is an APACHE® KAFKA® platform for processing and assessing events in real-time from each of the CTS agents 249. The CTS agents 249 include service#1 (250), service#2 (255) to Service #n (260). The CTS agents 249 are distributed to each resource to monitor and send data of instances 1 to N from each resource.
As such, Bougon teaches agents monitoring components of a CTS service 205. As such, the combination of Kolev and Bougon reasonably teach the argued limitations and therefore the combination is maintained.
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 JORGE A CHU JOY-DAVILA whose telephone number is (571)270-0692. The examiner can normally be reached Monday-Friday, 6:00am-5:00pm.
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, Aimee J Li can be reached at (571)272-4169. 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.
/JORGE A CHU JOY-DAVILA/Primary Examiner, Art Unit 2195
Prosecution Insights