DETAILED ACTION
Status of Claims
This action is in reply to the granted petition to revive filed on 01/15/2026.
Claims 21-40 have been added.
Claims 1-20 have been canceled.
Claims 21-40 are currently pending and have been examined.
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 .
Response to Arguments
Applicant' s arguments filed 07/02/2025 have been considered but are moot in view of the new ground(s) of rejection applied to new/added claims.
Claim Interpretations
The following is a quotation of 35 U.S.C. 112(f):
(f) ELEMENT IN CLAIM FOR A COMBINATION.—An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims include one or more elements which are being interpreted as invoking 35 U.S.C. 112(f).
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element is limited by the description in the specification when 35 U.S.C. 112(f), is invoked. As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f):
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as "configured to" or "so that"; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f). The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f), is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f). The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f), is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function. Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f), except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f), except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are: Claims 21, 24, 25, 31: “cloud observer” (AppSpec pg. 50-51); The remaining terms do not have a mapping to corresponding structure (see 112 rejections below), claim 23: “an inter-cloud coordination module”; claim 26: “an array of cloud-selection modules”, “a distributor”, and “an output selector”; claims 39 and 40: “multicast distributor”.
Because these claim limitations are being interpreted under 35 U.S.C. 112(f) they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have the limitation(s) above interpreted under 35 U.S.C. 112(f), applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f).
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(a) and 112 (b):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
(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.
Claims 23, 26, 39 and 40 are rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor at the time the application was filed, had possession of the claimed invention.
Claims 23 and 26:
Claims 23 and 26 stand rejected under 112(b) as described below for reciting limitations invoking 35 U.S.C. 112(f) without sufficient structure, and “[w]hen a claim containing a computer-implemented 35 U.S.C. 112(f) claim limitation is found to be indefinite under 35 U.S.C. 112(b) for failure to disclose sufficient corresponding structure (e.g., the computer and the algorithm) in the specification that performs the entire claimed function, it will also lack written description under section 112(a).”
Claims 39 and 40:
Claims 39 and 40 stand rejected under 112(b) as described below for reciting limitations invoking 35 U.S.C. 112(f) without sufficient structure, and “[w]hen a claim containing a computer-implemented 35 U.S.C. 112(f) claim limitation is found to be indefinite under 35 U.S.C. 112(b) for failure to disclose sufficient corresponding structure (e.g., the computer and the algorithm) in the specification that performs the entire claimed function, it will also lack written description under section 112(a).”
In addition, claim 40 recites:
A method of assigning service requests originating from a plurality of client devices to a plurality of clouds, each cloud having respective computing resources, the method comprising: at each cloud observer, comprising a respective processor, of a set of cloud observers:
monitoring a respective set of clouds, of said plurality of clouds, to acquire individual cloud valuations pertinent to a set of predefined cloud characteristics, for all clouds of said set of clouds;
determining a cloud merit level pertinent to each cloud valuation to produce merit data for said each cloud of said respective set of clouds;
communicating said merit data to each multicast distributor of a set of multicast distributors, so that said each multicast distributor possesses global merit data for each cloud characteristic for each cloud of said plurality of clouds, each multicast distributor being communicatively coupled to a respective subset of placement units of the set of placement units.
Claim 39 recites equivalent limitations.
AppSpec does not provide written description support for the cloud observers computing merit data in the “multicast distributor” embodiment to which the claims are directed. The description for the “multicast distributor” embodiment is found in FIG. 53 and pg. 52, li. 1-7 of AppSpec, reproduced below for convenience:
“FIG. 53 illustrates a third exemplary connectivity scheme 5300 of cloud observers 4830 to service-placement units 4840 of the distributed service-placement engine 4820 through multicast units 5340. Each cloud observer 4830 has a channel 5330 to each multicast unit 5340 carrying updates of cloud information. Each multicast unit 5340 combines updates of cloud information received from the cloud observers 4830 and broadcasts the combined updates to a respective set of service-placement units 4840 through channels 5310. Thus, each service-placement unit 4840 receives cloud information through a single channel 5310.”
As shown there is no suggestion of the observers propagating the cloud “merit” data (canonicalized/normalized cloud data) in the embodiment that includes the multicast unit and thus does not have explicit support. Furthermore, there cannot be implicit support because every method of computing cloud “merit” data disclosed in AppSpec requires the computing entity to be in possession of the full set of cloud information, which no single cloud observer has in the embodiment illustrated in FIG. 53 and described above.
Claims 23, 26, and 33-40 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Claims 23 and 26:
The following claim limitations each invoke 35 U.S.C. 112(f): claim 23: “an inter-cloud coordination module to enable placement of a service…”; claim 26: “an array of cloud-selection modules for concurrent cloud allocations for independent tasks…”, “a distributor for directing said individual tasks to said cloud-selection modules according to a scheme of realizing load balancing”, and “an output selector for directing task-placement decisions of said array of cloud-selection modules to an output buffer to be directed to respective clients”; claim 39 and 40: “each multicast distributor multicasting said global merit data to said respective subset of placement units”. However, Applicant’s as-filed Specification (AppSpec) fails to clearly link any structure disclosed therein to the recited function(s) and the claim(s) accordingly are rejected under 112(b) (MPEP 2181(II)). Below is a summary of the nearest identifiable disclosure of structure in AppSpec:
Claim 23: The recited “an inter-cloud coordination module” appears in FIG. 30 as box within the “enhanced cloud selection module” and is described in AppSpec pg. 38, li. 13 – pg. 39, li. 8: “the basic cloud-selection module 260 complemented with an inter-cloud coordination module 3025 to form an enhanced cloud-selection module 3020. The inter-cloud coordination module performs processes related to implementation of service tasks using multiple clouds as described below with reference to FIG. 32 to FIG. 46…Optionally, the inter-cloud coordination module 3025 may also be installed in a client device to perform some of the functions of inter-cloud coordination as is the case for client 110B. The enhanced placement engine 3000 exchanges control data with a client 110 through a path 3110 and exchanges control data with multiple clouds through paths 3120.” There is no further mention of the element nor suggestion of an algorithm or other structure sufficient to implement the recited function “to enable placement of a service requiring implementation of multiple tasks in multiple clouds”.
Claim 26: The recited “an array of cloud-selection modules”, “a distributor”, and “an output selector” elements of claim 26 are elements of FIG. 33, described at AppSpec pg. 39, li. 9-19, which “illustrates a scheme 3300 of using an array 3340 of cloud-selection modules 3350 for concurrent cloud selection” (pg. 39, li. 9-10) which at most merely repeats the same functions recited in the claim. There is no further description that clearly links any structure to the individual elements or the “scheme of 3300” as a whole. Even assuming they are intended as functions performed by a processor, there is no description in the form of an algorithm as to how any of the functions are intended to be carried out; “a rejection under 35 U.S.C. 112(b) is appropriate if the specification discloses no corresponding algorithm associated with a computer or microprocessor” (MPEP 2181(II)).
Claim 39 and 40: The recited “multicast distributor” is described at AppSpec pg. 3, li. 8-15 which essentially repeats the language for the element recited in the claim. AppSpec pg. 52, li. 3-6 describe a “multicast unit”: “Each cloud observer 4830 has a channel 5330 to each multicast unit 5340 carrying updates of cloud information. Each multicast unit 5340 combines updates of cloud information received from the cloud observers 4830 and broadcasts the combined updates to a respective set of service-placement units 4840 through channels 5310.” FIG. 53 illustrates the “multicast unit 5340” as an inverted triangle. There is no further mention of the element nor suggestion of an algorithm or other structure sufficient to implement the recited function of “multicasting said global merit data to said respective subset of placement units”.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f);
(b) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure and clearly links the structure to the function so that one of ordinary skill in the art would recognize it as such, applicant should clarify the record by stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Claims 33-38:
Claims 33-38 are each dependent upon claims now cancelled (claims 33, 34 and 36-38: claim 12; claim 35: claim 14). In order to advance prosecution, claim 12 dependency has been construed as claim 32 and claim 14 as claim 34.
Subject Matter Allowable Over Prior Art
Claims 39 and 40 would be allowable if the rejections under 35 U.S.C. 112 set forth in this Office action are overcome. Examiner refers to the references cited but not relied upon in the conclusion section of this action regarding prior art pertinent to the embodiment illustrated in FIG. 53.
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 21-23, 31, 32, and 37 are rejected under 35 U.S.C. 103 as being unpatentable over Bildhauer et al. (US 2018/0115468 A1) in view of Trihinas (“Monitoring Elastically Adaptive Multi-Cloud Services”, 2018, included with the 06/16/2021 Non-Final OA).
Claims 21 and 32:
Bildhauer discloses the limitations as shown in the following rejections:
A distributed system for assigning service requests originating from a plurality of client devices (service consumer/admin device/”external entity”) to a plurality of clouds (cloud/service providers), each cloud having respective computing resources (¶0036, 0062, 0075; FIG. 2, 5)
a set of placement units (multi-staged/service broker), each comprising a respective hardware processor, communicatively coupled to said plurality of clouds and said plurality of client devices through a communication network (¶0065-0066, 0077-0079, 0113; FIG. 5)
a set of…cloud observers (sensor adaptors, see below regarding “mutually interconnected”) , each cloud observer coupled to: a respective subset of placement units; and a respective set of clouds of said plurality of clouds to acquire from each cloud of said respective set of clouds a respective set of valuations of a set of predefined cloud characteristics (static and dynamic capabilities/attributes) said each cloud observer configured to:…canonicalize (format into capability records) said global valuations to produce corresponding global merit data (capability profiles); and communicate said global merit data to each placement unit of said respective subset of placement units; (¶0060-0061, 0065-0067, 0078-0080, 0084; FIG. 5). Exemplary quotations:
“static and dynamic parameters of the used cloud computing environment are continuously measured and assessed (¶0060)…the collecting static capabilities may comprise receiving messages by the multi-staged broker from a sensory adapter connected to at least one of the at least two infrastructure systems. The messages may be indicative of static characteristic values of the at least two infrastructure systems. In typical cases, the static capabilities may be received from all connected cloud systems” (¶0065).
“a computer or IT device 532 being installed in a cloud computing environment 534 which acts as sensor 518 that receives status information of the cloud computing environment or computing devices 536 located in the cloud computing environment and sends, 538, the event to the adapter 508. One example of an active event sensor is the active sensor adapter 502 which actively detects 540 events generated by an IT device 542 of a cloud computing environment 544 through a sensor 516, the events containing status information about the cloud computing environment” (¶0080)
said each placement unit configured to: receive from any client device client-defined service-specific data (service definition) comprising: definitions of a set of tasks (service components/“parts”); significance data comprising a significance level of each task for said each cloud characteristic (requirements, polices); and allocate a preferred (most suitable) cloud for said each task according to said global merit data and said significance data (¶0061-0063, 0067-0071, 0077, 0086, 0089, 0101, 0120).
Bildhauer does not detail the network topology of the sensor adapters and does not specifically disclose they are mutually interconnected or configured to: communicate said respective set of valuations to each other cloud observer, so that said each cloud observer possesses global valuations for said each cloud characteristic for each cloud of said plurality of clouds. Bildhauer also only explicitly depicts single broker platform.
Trihinas, however, is directed to a system and methods for monitoring distributed cloud environments which employs a plurality of monitoring servers (cloud observers) (pg. 803, § 3.2) to provide cloud monitoring services to a plurality of resource provisioning stakeholders (placement units); and further discloses exemplary topologies (pg. 806-807, § 3.4 and Fig. 6) including a set of mutually interconnected (P2P and/or Hybrid topologies) cloud observers (monitoring servers), each cloud observer coupled to: a respective subset of placement units (resource provisioner stakeholders); and a respective set of clouds of said plurality of clouds to acquire from each cloud of said respective set of clouds a respective set of valuations (monitoring/performance data) of a set of predefined cloud characteristics; said each cloud observer configured to: communicate said respective set of valuations to each other cloud observer; (“Fig. 6b depicts a Peer-2-Peer topology, where Monitoring Servers are distributed across the network forming a P2P gossip network. For JCatascopia, gossip is a compressed message exchanged between peers to periodically discover the state of other Monitoring Servers participating in the network, as well as…In this arrangement, all Monitoring Servers (peers) have the same monitoring responsibilities (e.g., receive, process, store metrics) with some peers also acting as seeds.”)
It would have been obvious to one of ordinary skill in the art prior to the filing date of the claimed invention to modify Bildhauer to employ the distributed cloud monitoring system of Trihinas because “JCatascopia is a suitable monitoring system to support a fully automated cloud resource provisioning system with proven interoperability, scalability, fault-tolerance and with a low runtime footprint. Most importantly, our framework is able to reduce network traffic by 41 percent over state-of-the-art solutions and consequently the monitoring cost” (pg. 813, § 5; pg. 801, col. 1).
Claims 22 and 37:
The combination of Bildhauer/Trihinas discloses the limitations as shown in the rejections above. Bildhauer further discloses:
said placement unit comprises: a network interface configured to: receive said global merit data; receive service requests and associated service requirements from client devices of said plurality of client devices; and communicate identifiers of allocated clouds per service request to respective client devices (¶0041, 0067-0068, 0074-0075, 0115-0116; FIG. 2, 5)
a storage medium (service provider registry and/or service provider database) for maintaining cloud characterization data; and a cloud selection module (¶0084-0085, 0078, 0081).
Claim 23:
The combination of Bildhauer/Trihinas discloses the limitations as shown in the rejections above. Bildhauer further discloses an inter-cloud coordination module installed in said each placement unit and in said any client device to enable placement of a service requiring implementation of multiple tasks in multiple clouds (¶0089, 0101-0102) disclosing deployment of service components on multiple clouds.
Claim 31:
The combination of Bildhauer/Trihinas discloses the limitations as shown in the rejections above. Furthermore, the combination of Bildhauer/Trihinas the set of cloud observers comprises geographically distributed (across multiple domains) individual cloud observers; and the set of placement units comprises geographically distributed individual placement units (see at least Trihinas pg. 800, col. 2; pg. 806, sect. 3.4; Bildhauer ¶0052-0053, 0062).
Claims 24, 25, 28-30, 33, 36 and 38 are rejected under 35 U.S.C. 103 as being unpatentable over Bildhauer in view of Trihinas in further view of Neeraj et al. (“A Ranking Based Model for Selecting Optimum Cloud Geographical Region”, 2019).
Claims 24 and 25:
The limitations of claims 24 and 25 essentially describe that the canonicalization/normalization technique employed is min-max normalization, which is not disclosed by Bilhauer/Trihinas.
Neeraj, however, discloses (pg. 793, Abstract; pg. 794, § II) an analogous cloud broker and service placement selection method, wherein: the set of predefined cloud characteristics comprises: type-1 (“positive”) characteristics, where increasing a respective characteristic value increases a respective cloud appraisal; and type-2 (“negative”) characteristics, where decreasing a respective characteristic value increases a respective cloud appraisal; said each cloud observer is configured to: examine, for said each cloud characteristic, corresponding valuations of all clouds to determine a respective minimum valuation and a respective maximum valuation; and convert a value of said each cloud characteristic to a respective merit value that is bounded between predefined limits, regardless of characteristic type…convert a specific value of a type-1 characteristic to a respective merit value, bounded between 0 and 1, determined as a ratio of a difference between said specific value and said respective minimum value to a difference between said respective maximum value and said respective minimum value; and convert a specific value of a type-2 characteristic to a respective merit value, bounded between 0 and 1, determined as a ratio of a difference between said respective maximum value and said specific value to a difference between said respective maximum value and said respective minimum value (pg. 794, § II):
PNG
media_image1.png
250
453
media_image1.png
Greyscale
For clarity of record, from AppSpec pg. 27:
PNG
media_image2.png
283
625
media_image2.png
Greyscale
It would have been obvious to one of ordinary skill in the art prior to the filing date of the claimed invention to modify Bildhauer/Trihinas to employ the selection technique of Neeraj because it provides a scalable, low overhead technique to select the optimum cloud service provider (CSP) to place requested service(s) (Neeraj pg. 797, col. 1, para. 1; pg. 793, Abstract); and generally represents the simple substitution of one CSP ranking/selection method with an equivalent alternative.
Claims 28-30, 36 and 38:
The combination of Bildhauer/Trihinas discloses the limitations as shown in the rejections above. The combination of Bildhauer/Trihinas does not specifically account for CSP distance between the requester and the candidate cloud (location merit for each client-cloud pair) when making the selection and does not specifically disclose the limitations of claims 28-30 and 38.
Neerja, however, discloses an analogous cloud broker and method for service ranking and "service selection model which selects services required by the cloud consumer from the optimum CGR" (Cloud Geographical Region) (pg. 794, § III, para. 1) which considers "distance from the cloud consumer" (location merit) as a part of global merit data (CSP attributes) and significance data (consumer selection weights), where the distances are min-max normalized as a negative (type 2) attribute ("it should be close (less distance) to the cloud consumer, minimum cost") and is accordingly evaluated as a function of distances from a client device's location to: (1) a respective cloud; (2) nearest cloud of the plurality of clouds; and (3) furthest cloud of the plurality of clouds) in at least pg. 793, § I para. 3; pg. 794, § III and Table 1; pg. 794, § IV.
It would have been obvious to one of ordinary skill in the art prior to the filing date of the claimed invention to modify Bildhauer/Trihinas to employ the selection technique of Neeraj because it provides a scalable, low overhead technique to select the optimum cloud service provider (CSP) to place requested service(s) (Neeraj pg. 797, col. 1, para. 1; pg. 793, Abstract); and generally represents the simple substitution of one CSP ranking/selection method with an equivalent alternative.
Claim 33:
The combination of Bildhauer/Trihinas discloses the limitations as shown in the rejections above. The combination of Bildhauer/Trihinas does not specifically disclose wherein said respective composite task-cloud merit is determined as a sum of products of merit levels and significance levels for all characteristics of said set of predefined cloud characteristics.
Neerja, however, discloses an analogous cloud broker and method for service ranking and "service selection model which selects services required by the cloud consumer from the optimum CGR" (Cloud Geographical Region) (pg. 794, § III, para. 1), wherein said respective composite task-cloud merit (aggregate preference is determined as a sum of products of merit levels and significance levels (weights) for all characteristics (attributes) of said set of predefined cloud characteristics:
PNG
media_image3.png
224
448
media_image3.png
Greyscale
It would have been obvious to one of ordinary skill in the art prior to the filing date of the claimed invention to modify Bildhauer/Trihinas to employ the selection technique of Neeraj because it provides a scalable, low overhead technique to select the optimum cloud service provider (CSP) to place requested service(s) (Neeraj pg. 797, col. 1, para. 1; pg. 793, Abstract); and generally represents the simple substitution of one CSP ranking/selection method with an equivalent alternative.
Claim 26 is rejected under 35 U.S.C. 103 as being unpatentable over Bildhauer in view of Trihinas in further view of Amato et al. (“Cloud Brokering as a Service”, 2013).
Claims 26:
As described in the rejections under 112(b) above, the precise meets and bounds of claim 26 are unclear. But in view of AppSpec pg. 39, li. 9-19, it appears the critical subject matter claim 26 is attempting to capture is parallel/concurrent handling of incoming service placement requests, which is not specifically disclosed by Bildhauer/Trihinas.
Amato, however, discloses an analogous cloud brokering system and method, including (pg. 13, § IV; pg. 13-14, Fig. 3-5): an array of cloud-selection modules (workers/application server instances) for concurrent cloud allocations for independent tasks; an input buffer (front-end interface) for holding service requests and definitions of individual tasks of each requested service; a distributor (load balancer) for directing said individual tasks to said cloud-selection modules according to a scheme of realizing load balancing; and an output selector for directing task-placement decisions of said array of cloud-selection modules to an output buffer (available proposals/results queue) to be directed to respective clients.
It would have been obvious to one of ordinary skill in the art prior to the filing date of the claimed invention to modify the broker architecture of Bildhauer/Trihinas with the distributed broker design disclosed by Amato because it is an extensible dynamic architecture that facilitates efficient multi-user utilization via enhanced scalability (Amato pg. 16, col. 1, para. 1; pg. 13, § IV), “The great advantage of the proposed approach is the scalability. Besides it allows the concurrency, is open and available to enable easy extensions to existing components and add new components” (pg. 16).
Claims 27, 34, and 35 are rejected under 35 U.S.C. 103 as being unpatentable over Bildhauer in view of Trihinas in further view Malawski (“Scheduling Multilevel Deadline-Constrained Scientific Workflows on Clouds Based on Cost Optimization”, 2015, included with the 02/01/2022 Final OA).
Claims 27, 34, and 35:
The combination of Bildhauer/Trihinas discloses the limitations as shown in the rejections above. As noted above, Bildhauer discloses a single request being divided into multiple service components, but does not specifically disclose the components having explicit dependencies, and the combination of Bildhauer/Trihinas does not specifically disclose said client-defined service-specific data indicate interdependence of tasks of the set of tasks or the remaining limitations of claims 27, 34, and 35.
Malawski, however, discloses (pg. 2, col. 1; pg. 3-4, § 4) an analogous method for placing tasks of a multi-service request amongst multiple clouds, wherein requests specify a workflow comprising tasks/components with interdependencies (said client-defined service-specific data indicate interdependence of tasks of the set of tasks), under a deadline constraint including (pg. 3-4, § 4 and 5; pg. 4, Fig. 2) sort said set of tasks into hierarchical layers (levels), based on said client-defined service-specific data, wherein: each task of a first layer is independent (has no predecessor); tasks of each layer are independent of each other; and each task of a layer succeeding the first layer depends on at least one task of at least one preceding layer; said each placement unit is configured to process tasks of said hierarchical layers sequentially, starting with said first layer; and concurrently allocate tasks of a same layer to at least one cloud. Exemplary quotation
“a workflow is divided into several levels that can be executed sequentially and tasks within one level not do depend on each other (see Figure 2). Each level represents a set of tasks that can be partitioned in several groups (A, B, etc.) that share computational cost and input/output size. We assume that only one task group is executed on a specific cloud instance” (pg. 3, § 4).
PNG
media_image4.png
338
306
media_image4.png
Greyscale
It would have been obvious to one of ordinary skill in the art prior to the filing date of the claimed invention to modify Bildhauer/Trihinas’s component placement to support dependent tasks/components and the scheduling thereof as disclosed by Malawski’s method of level-based workflow scheduling to allow large task sets to be scheduled to multiple cloud service providers under deadline at optimal cost (Malawski pg. 1).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure:
The following are directed to multi-cloud distributed monitoring implementations and/or propagation/distribution of cloud service information particularly relevant to the embodiment illustrated in AppSpec FIG. 53: US 20180130106 A1; US 20140115028 A1; US 20200267231 A1; “DARGOS: A highly adaptable and scalable monitoring architecture for multi-tenant Clouds is directed to distributed multi-cloud monitoring” and “Distributed, application-level monitoring for heterogeneous clouds using stream processing”.
The following are directed to multi-cloud broker implementations: “Cloud Integrator: Building Value-Added Services on the Cloud”, “HS4MC Hierarchical SLA-based Service Selection for Multi-Cloud Environments”, “Greedy Multi-cloud Selection Approach to Deploy an Application Based on Microservices”, US 20110314082 A1, US 20110238515 A1, US 20120198073 A1.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 of a general nature or relating to the status of this application or concerning this communication or earlier communications from the Examiner should be directed to Paul Mills whose telephone number is 571-270-5482. The Examiner can normally be reached on Monday-Friday 11:00am-8:00pm. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, April Blair can be reached at 571-270-1014.
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.
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.
/P. M./
Paul Mills
05/29/2026
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights