DETAILED ACTION
This action is response to application number 18/610,647, dated on 03/20/2024.
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 § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated or alternatively unpatentable over Ward et al. (US 2020/0380422 A1).
Claim 1, Ward discloses a method for negotiated allocation of commoditized network resource management in a wireless communication network (negotiating allocation of the network resource and providing quote/recommendations to the clients; abstract; In many environments, operators of provider networks that implement different types of virtualized computing, storage, and/or other network-accessible functionality allow customers to reserve or purchase access to resources in any of several different resource acquisition modes. For example, a customer may reserve a virtual compute resource instance for a relatively long duration, such as one year or three years, or a customer may purchase resources for shorter terms on an ad-hoc basis as needed. For some types of resource reservations, at least a portion of the price paid by the customer may fluctuate over time in response to changing demand and supply of the resources within the provider network. The provider network operator may have to try to ensure that a number of potentially competing demands are met, e.g., that all guaranteed commitments to clients (such as long-term reservations that have already been paid for) are honored, that the dynamically-varying component of resource pricing does not get so high that customer satisfaction suffers, that the provider's data center investment is justified by a reasonable level of resource utilization and revenue, and so on. In business environments where clients may choose from among multiple providers for network-based computing options, provider network operators may wish to maintain high levels of customer satisfaction and customer retention, e.g., by making resource acquisition easy and economical, and by reducing the complexity of client resource budget management as much as possible; ¶4; The provider network may support several different purchasing modes (which may also be referred to herein as reservation modes) in one embodiment: for example, long-term reservations, on-demand resource allocation, or spot-price-based resource allocation. Using the long-term reservation mode, a client may make a low, one-time, upfront payment for a resource instance, reserve it for a specified duration such as a one or three year term, and pay a low hourly rate for the instance; the client would be assured of having the reserved instance available for the term of the reservation. Using on-demand mode, a client could pay for capacity by the hour (or some appropriate time unit), without any long-term commitments or upfront payments. In the spot-price mode, a client could specify the maximum price per unit time that it is willing to pay for a particular type of resource, and if the client's maximum price exceeded a dynamic spot price determined at least in part by supply and demand, that type of resource would be provided to the client. In some embodiments, dynamically resizable pools of resource instances may be set aside for the different reservation types or modes—e.g., long-term reserved instances may be allocated from one pool, on-demand instances from another, and so on. During periods when the supply of the requested resource type exceeded the demand, the spot price may become significantly lower than the price for on-demand mode. In some implementations, if the spot price increases beyond the maximum bid specified by a client, a resource allocation may be interrupted—i.e., a resource instance that was previously allocated to the client may be reclaimed by the resource manager and may be allocated to some other client that is willing to pay a higher price. Other purchasing modes or combinations of modes may be implemented by the resource manager in some embodiments; ¶35; Fig. 3), the method comprising:
updating, by a commoditization processor based on data obtained from a network data analysis function (NWDAF), a commoditizable session-allocatable network resource (CSANR) demand model indicating a present and/or predicted demand for one or more CSANRs of the wireless communication network (acquiring data from the data analysis function (agents; Fig. 1, els. 140A, 140 B) to update the network resource pools (Fig. 1, els. 120A, 120B) and on-demand instance pools (Fig.1, els. 123A, 123B) model and obtaining the knowledge of the trends of past or current resource usage and make projections about future usage and provide recommendation and offers to the clients; pricing optimizer 181, which may exist as a separate entity in some embodiments and may be incorporated as an element of the resource manager 180 in other embodiments, may be configurable to obtain information from a variety of data sources to generate recommendations on the instances that a client 148 should acquire or reserve. For example, in the embodiment illustrated in FIG. 1, the pricing optimizer 181 may obtain resource usage records or statistics from one or more provider-side metrics agents, such as agents 140A and 140B, which may provide information regarding the usage of various types of instances 130 by a client 148 over some selected period of time. The pricing optimizer 181 may use its knowledge of the trends of past or current resource usage by a given client 148 to make projections about future usage of different types of resources by the client 148. In some embodiments, resource usage metrics may also or instead be obtained from client-side devices external to the provider network 110. For example, in one implementation the pricing optimizer 181 or the resource manager 180 may provide a downloadable or otherwise installable client-side metrics agent such as 190A to a client such as 148A, and the client 148A may install and activate the agent or agents in the client's data center or client-managed premises. The client-side metrics agent 190 may gather resource usage information from various client devices 160 (e.g., 160A and 160B in client network 150A of client 148A, or 160D and 160E in client network 150B of client 148B), and transmit the usage information to the pricing optimizer 181. The pricing optimizer 181 may use the client-side usage metrics to help generate recommendations for the kinds of instances 130 that the client should consider for use. In some cases, the pricing optimizer 181 may obtain usage records from both provider-side metrics agents 140 and client-side metrics agents 190; ¶51; Various instance pool sizes may also be changed as a result of other factors in addition to the types of events mentioned above (such as instances being freed or allocated) in some embodiments. FIG. 22 is a flow diagram illustrating aspects of the operation of a resource manager 180 configured to resize instance pools based at least on part on usage trends for on-reserved instances and on-demand instances, according to at least one embodiment. The resource manager 180 may gather metrics on the variations in the number of active or allocated reserved instances and/or on-demand instances over time (element 2201). Based on the metrics, the resource manager 180 may identify usage trends and develop projections for expected future usage of the different types of instances. Projections may be developed for varying future time periods in some embodiments. For example, by examining hour-by-hour usage data for on-demand instances over a period of a few months, the resource manager 180 may be able to project that the number of on-demand instance acquisition requests typically rises by X % between 6 am and 8 am on Mondays. Accordingly, the resource manager may ensure that sufficient available interruptible-without-notification instances are set aside to meet the X % increase—e.g., by reducing the number of enhanced-interruptibility instances at the appropriate times. Longer-term trends may also be identified on the basis of past usage in some embodiments—e.g., the resource manager 180 may be able to predict that the total number of reserved instances is going to rise by 30% over the next three months, and/or that the fraction of reserved instance slots that are unused at any given time is likely to rise by 20% over the next three months; ¶115; Based at least in part on such short-term and/or longer-term projections, the resource manager 180 may make a determination as to whether any of the instance pools or sub-pools, such as the enhanced-interruptibility sub-pools, need to be resized (element 2209). If the resource manager 180 determines that one or more pools or sub-pools should be resized, it may determine when such resizing should be performed, and move instances in or out of the appropriate pools accordingly (element 2213). If no changes to current pool sizes are needed, the resource manager may resume monitoring the usage of various types of resources and make new projections as needed, e.g., repeating the steps illustrated in elements 2201, 2205 and 2209. In some embodiments projections of future needs for various types of instances may be made based on a predetermined schedule. In other embodiments projections may be developed in response to threshold conditions—e.g., if the number of available instances falls to less than 10% of the total instances in an availability zone, an analysis of past usage trends and corresponding future projections may be initiated. In addition to changing the sizes of various pools and sub-pools, the pricing rates associated with different interruptibility settings may also be adjusted based on trend analysis in some embodiments. For example, in one embodiment usage trends may predict a rise in demand for enhanced-interruptibility instances by a web retailing client during a forthcoming retail sales period, and the resource manager 180 may raise prices for enhanced interruptibility instances based on the prediction; ¶116);
generating, by the commoditization processor, one or more CSANR offers for purchase of the one or more CSANRs at an associated one or more commodity prices determined from present CSANR pricing computed for the one or more CSANRs based on the CSANR demand model (generating quote and recommendation to client; Fig. 22; Fig. 25; Fig. 27; projections, the resource manager 180 may make a determination as to whether any of the instance pools or sub-pools, such as the enhanced-interruptibility sub-pools, need to be resized (element 2209). If the resource manager 180 determines that one or more pools or sub-pools should be resized, it may determine when such resizing should be performed, and move instances in or out of the appropriate pools accordingly (element 2213). If no changes to current pool sizes are needed, the resource manager may resume monitoring the usage of various types of resources and make new projections as needed, e.g., repeating the steps illustrated in elements 2201, 2205 and 2209. In some embodiments projections of future needs for various types of instances may be made based on a predetermined schedule. In other embodiments projections may be developed in response to threshold conditions—e.g., if the number of available instances falls to less than 10% of the total instances in an availability zone, an analysis of past usage trends and corresponding future projections may be initiated. In addition to changing the sizes of various pools and sub-pools, the pricing rates associated with different interruptibility settings may also be adjusted based on trend analysis in some embodiments. For example, in one embodiment usage trends may predict a rise in demand for enhanced-interruptibility instances by a web retailing client during a forthcoming retail sales period, and the resource manager 180 may raise prices for enhanced interruptibility instances based on the prediction; ¶116; In some embodiments, a client 148 may provide an application package to the resource manager 180 and ask for a quote for completing execution of the application. The resource manager may analyze the application package in response to the quote request, and may determine and provide a quote responsive to the request, taking into account various factors such as the current and/or expected future pricing of EPs 2305 appropriate for the client's application. The client 148 may receive the quote and indicate a bid responsive to the quote, e.g., as part of pricing constraint information provided with the application package. The resource manager 180 may respond to the bid affirmatively, by scheduling execution of the client's application on a suitable EP, or, if the bid is found to be insufficient, the resource manager 180 may reject the bid at least temporarily. A client 148 may ask for bid to complete execution of an application after a portion of the application has already been executed in some embodiments. For example, if an application is run for a while and then stopped as a result of a price-based interruption event, the client may submit a quote request to the resource manager to obtain an estimate of how much it might cost to complete the remaining portion of the application execution. In some implementations, if a bid responsive to a quote is initially rejected, that same bid may later be found acceptable as a result of price changes that have occurred since the initial rejection; thus, the execution of an application may be scheduled if and when the bid becomes acceptable; ¶122);
outputting the one or more CSANR offers to a tenant of the wireless communication network via an interface of a network orchestrator function in communication with the commoditization processor; receiving, from the tenant responsive to the outputting, a purchase decision indicating a purchased quantity of at least one of the CSANRs at a purchase price corresponding to an accepted one of the one or more CSANR offers; and directing, automatically by the network orchestrator function, adjustment of a present tenant network resource allocation including adjusting allocation of the at least one of the CSANRs to the tenant in accordance with the purchased quantity (outputting offers/quotes, receiving tenant bit based on indicated purchase quantity; Fig. 2, step 4 shows resource manager providing quote for the client request submitted through application package (Fig. 24, el. 2405) and client submit bid in response to quote and if the bid is accepted, automatically adjust the present tenant network resource allocation in accordance with the purchased quantity; In some embodiments, a client 148 may provide an application package to the resource manager 180 and ask for a quote for completing execution of the application. The resource manager may analyze the application package in response to the quote request, and may determine and provide a quote responsive to the request, taking into account various factors such as the current and/or expected future pricing of EPs 2305 appropriate for the client's application. The client 148 may receive the quote and indicate a bid responsive to the quote, e.g., as part of pricing constraint information provided with the application package. The resource manager 180 may respond to the bid affirmatively, by scheduling execution of the client's application on a suitable EP, or, if the bid is found to be insufficient, the resource manager 180 may reject the bid at least temporarily. A client 148 may ask for bid to complete execution of an application after a portion of the application has already been executed in some embodiments. For example, if an application is run for a while and then stopped as a result of a price-based interruption event, the client may submit a quote request to the resource manager to obtain an estimate of how much it might cost to complete the remaining portion of the application execution. In some implementations, if a bid responsive to a quote is initially rejected, that same bid may later be found acceptable as a result of price changes that have occurred since the initial rejection; thus, the execution of an application may be scheduled if and when the bid becomes acceptable; ¶122; The quote may include a fixed price that the client would be billed for completing the execution of the application in some embodiments. In one implementation, several alternate quotes may be provided, each with an associated time period for completing the application execution—e.g., one quote for completing the application within a week, another quote for completing the application within two weeks, and so on. In another implementation, the resource manager 180 may provide several alternate quotes for completing different fractions of execution (or different numbers of total client transactions, in the case of transactional workloads)—e.g., the resource manager 180 may provide a first quote for completing 50 simulation runs, another quote for 100 simulation runs, and so on. When the quote or set of quotes is determined, either by the resource manager 180 alone or as a result of cooperation between the resource manager 180 and the pricing optimizer 181, the quote may be provided to the client 148, as indicated by the arrow labeled “4” in FIG. 25. In response to the quote or quotes, the client 148 may submit a bid, as indicated by the arrow labeled “5”. If the bid is acceptable, the resource manager 180 may schedule the execution of the client's application if a suitable EP 2305 is available. If no appropriate EP is currently available, or if the bid is too low, the client's application package may be stored in application repository 2390 for later execution; ¶128).
Claim 2, Ward discloses wherein the directing the adjustment of the present tenant network resource allocation comprises issuing a request to a network exposure function (NEF) to adjust the allocation of the least one of the CSANRs to the tenant based on the purchased quantity (communicating messages/requests between various network entities implementing the functions in order to adjust the present tenant network resource allocation in accordance with the purchased quantity by various message between the network entities; The quote may include a fixed price that the client would be billed for completing the execution of the application in some embodiments. In one implementation, several alternate quotes may be provided, each with an associated time period for completing the application execution—e.g., one quote for completing the application within a week, another quote for completing the application within two weeks, and so on. In another implementation, the resource manager 180 may provide several alternate quotes for completing different fractions of execution (or different numbers of total client transactions, in the case of transactional workloads)—e.g., the resource manager 180 may provide a first quote for completing 50 simulation runs, another quote for 100 simulation runs, and so on. When the quote or set of quotes is determined, either by the resource manager 180 alone or as a result of cooperation between the resource manager 180 and the pricing optimizer 181, the quote may be provided to the client 148, as indicated by the arrow labeled “4” in FIG. 25. In response to the quote or quotes, the client 148 may submit a bid, as indicated by the arrow labeled “5”. If the bid is acceptable, the resource manager 180 may schedule the execution of the client's application if a suitable EP 2305 is available. If no appropriate EP is currently available, or if the bid is too low, the client's application package may be stored in application repository 2390 for later execution; ¶128).
Claims 3, 15, Ward discloses receiving, from the tenant at a network interface of the wireless communication network, a request for adjustment of one or more quality-of-service (QoS) parameters (receiving tenant request for adjusting QoS parameter of communication for the application according to Fig. 24, el. 2405; In some embodiments the AP 2405A may include a set of preferred or required resource specifications 2415, such as a minimum CPU speed, CPU vendor or architecture details, minimum main memory requirements, an operating system version, application server version, database management system vendor and version, and so on. Some of the resource specifications may be labeled as mandatory, i.e., the resource manager 180 may be unable to execute the application if the mandatory requirements are not met. Non-mandatory resource specifications may serve as hints or advisories to the resource manager; e.g., the resource manager may in some implementations make a best effort to find execution platforms that meet non-mandatory specifications; ¶123); and
determining, by a policing interface of the wireless communication network, whether to permit the request for adjustment based at least on the present tenant network resource allocation (determining to perform the client request based on present tenant network resource allocation and implemented policies; For example, in making the recommendation, the pricing optimizer may take into account data about the client's resource usage during earlier time periods (e.g., during the last month or the last three months) as indicated by the usage records, the pricing policies and/or current prices of different types of resources in the various resource pools, and one or more optimization goals of the client. Several different types of client optimization goals may be taken into account in various embodiments, including for example client budget limits, and/or goals for a target number of available resource instances that the client wishes to acquire. Using these various types of information, the pricing optimizer may determine a recommended number and/or types of resource instances that the client should access over some future term, and provide a notification of the recommendation to the client; ¶36; Each pool (or sub-pool) may have an associated pricing policy for its instances, as well as other properties such as interruptibility settings for the instances that happen to be assigned to the pool or sub-pool. Additional details regarding the organization of the different types of pools, various pricing policies and interruptibility policies supported in different embodiments, and the logic that may be used to move instances from one pool or sub-pool to another, will be provided below. It is noted that the pools may represent logical collections or aggregations, so that, for example, the presence of two instances in the same pool or sub-pool may not necessarily imply anything about the physical location of the hardware used for the two instances. Although the instances 130 illustrated in FIG. 1 are shown as belonging to availability zones 120, in other embodiments the provider network 110 may be organized differently: e.g., in some embodiments availability zones may not be implemented. Availability zones 120 may be grouped into geographic regions (not shown in FIG. 1) in some embodiments. Instance pools may be implemented within availability zones in some implementations (e.g., each availability zone may have its own reserved instance pool), while in other implementations an instance pool or sub-pool may span multiple availability zones; ¶50; The resource instances 130 of a provider network may be grouped into classes or categories based on several different dimensions in some embodiments, and the pricing policies associated with different classes may differ. FIGS. 2a and 2b illustrate example resource instance classification approaches, according to at least some embodiments. FIG. 2a illustrates an approach in which instances are classified based in part on the timing or duration of instance allocations—i.e., on when instances are obtained by clients and when they are released by the clients. Three high-level types 201 of resource instances are shown: reserved instances 203, on-demand instances 205, and spot-instances 207, each with respective pricing policies 203P, 205P and 207P; ¶53; FIG. 26 is a flow diagram illustrating aspects of the operation of a resource manager 180 configured to schedule execution of client-provided applications on execution platforms 2305 with dynamically changing pricing per unit of execution, according to at least some embodiments. As shown in element 2601, the resource manager 180 may determine the next application package 2405 for which it is to attempt execution scheduling. An application package 2405 that has just been submitted by a client 148 may be the next one to be scheduled, or, if there are one or more application packages 2405 in the application repository 2390 whose executables are currently not running, an application packages from the repository may be the next one to be scheduled. The resource manager 180 may in some implementations maintain a queue or list of schedulable applications, ranked based on the basis of one or more priority criteria such as the bid value associated with each application package 2405, and may pick the highest priority application package from such a queue or list for consideration as the next application package to be scheduled. In some implementations, multiple such queues or lists may be maintained, e.g., different queues may be maintained for different sizes and/or other characteristics of supported execution platforms. One queue may be maintained for EPs 2305 that comprise JVMs, another queue for Python execution platforms, and so on, for example; ¶129).
Claims 4, 16, Ward discloses the request for adjustment is received subsequent to the directing adjustment of the present tenant network resource allocation, such that the determining whether to permit the request for adjustment is based at least on the present tenant network resource allocation accounting for the adjustment (determining to perform the client request based on present tenant network resource allocation accounting for the adjustment and implemented policies; For example, in making the recommendation, the pricing optimizer may take into account data about the client's resource usage during earlier time periods (e.g., during the last month or the last three months) as indicated by the usage records, the pricing policies and/or current prices of different types of resources in the various resource pools, and one or more optimization goals of the client. Several different types of client optimization goals may be taken into account in various embodiments, including for example client budget limits, and/or goals for a target number of available resource instances that the client wishes to acquire. Using these various types of information, the pricing optimizer may determine a recommended number and/or types of resource instances that the client should access over some future term, and provide a notification of the recommendation to the client; ¶36).
Claims 5, 17, Ward discloses the request for adjustment is received prior to the generating the one or more CSANR offers; the generating the one or more CSANR offers is responsive to determining not to permit the request for adjustment; and the generating the one or more CSANR offers comprises generating at least one CSANR offer that accommodates the request for adjustment (generating one or more offer is responsive to determining not to permit the request for adjustment and generating one offer that accommodates the request; In some implementations where for example multiple interruptibility settings are supported, if a client 148 sends an upgrade request with a specified bid for a desired target interruptibility setting, and the resource manager 180 determines that the request is unacceptable, the resource manager 180 may attempt to find another interruptibility setting for which the bid is acceptable. If such an alternative setting is found, the client may be notified. For example, the client may bid $D for an upgrade from interruptibility level I1 to level I3. If the resource manager finds that $D is insufficient to enhance the interruptibility from level I1 to level I3, but is acceptable to enhance the interruptibility level from I1 to level I2, the resource manager 180 may inform the client that level I2 is acceptable, and may set the interruptibility level of the instance to I2 if the client agrees. In some embodiments, the client 148 may be able to request that the resource manager 180 select the best possible interruptibility level for a specified price that the client is willing to pay, and the resource manager may determine the specific interruptibility setting (or the length of the advance warning for access revocation) to be used for the client's instance; ¶113; In some embodiments, a client 148 may provide an application package to the resource manager 180 and ask for a quote for completing execution of the application. The resource manager may analyze the application package in response to the quote request, and may determine and provide a quote responsive to the request, taking into account various factors such as the current and/or expected future pricing of EPs 2305 appropriate for the client's application. The client 148 may receive the quote and indicate a bid responsive to the quote, e.g., as part of pricing constraint information provided with the application package. The resource manager 180 may respond to the bid affirmatively, by scheduling execution of the client's application on a suitable EP, or, if the bid is found to be insufficient, the resource manager 180 may reject the bid at least temporarily. A client 148 may ask for bid to complete execution of an application after a portion of the application has already been executed in some embodiments. For example, if an application is run for a while and then stopped as a result of a price-based interruption event, the client may submit a quote request to the resource manager to obtain an estimate of how much it might cost to complete the remaining portion of the application execution. In some implementations, if a bid responsive to a quote is initially rejected, that same bid may later be found acceptable as a result of price changes that have occurred since the initial rejection; thus, the execution of an application may be scheduled if and when the bid becomes acceptable; ¶122).
Claims 6, 18, Ward discloses wherein the generating the one or more CSANR offers comprises: detecting, based on the updating the CSANR demand model, a change in the CSANR demand model in excess of a predetermined threshold; and automatically generating the one or more CSANR offers responsive to the detecting (During periods when the supply of the requested resource type exceeded the demand, the spot price may become significantly lower than the price for on-demand mode. In some implementations, if the spot price increases beyond the maximum bid specified by a client, a resource allocation may be interrupted—i.e., a resource instance that was previously allocated to the client may be reclaimed by the resource manager and may be allocated to some other client that is willing to pay a higher price. Other purchasing modes or combinations of modes may be implemented by the resource manager in some embodiments; ¶35; Based at least in part on such short-term and/or longer-term projections, the resource manager 180 may make a determination as to whether any of the instance pools or sub-pools, such as the enhanced-interruptibility sub-pools, need to be resized (element 2209). If the resource manager 180 determines that one or more pools or sub-pools should be resized, it may determine when such resizing should be performed, and move instances in or out of the appropriate pools accordingly (element 2213). If no changes to current pool sizes are needed, the resource manager may resume monitoring the usage of various types of resources and make new projections as needed, e.g., repeating the steps illustrated in elements 2201, 2205 and 2209. In some embodiments projections of future needs for various types of instances may be made based on a predetermined schedule. In other embodiments projections may be developed in response to threshold conditions—e.g., if the number of available instances falls to less than 10% of the total instances in an availability zone, an analysis of past usage trends and corresponding future projections may be initiated. In addition to changing the sizes of various pools and sub-pools, the pricing rates associated with different interruptibility settings may also be adjusted based on trend analysis in some embodiments. For example, in one embodiment usage trends may predict a rise in demand for enhanced-interruptibility instances by a web retailing client during a forthcoming retail sales period, and the resource manager 180 may raise prices for enhanced interruptibility instances based on the prediction; ¶116).
Claims 7, 19, Ward discloses wherein the generating the one or more CSANR offers comprises: receiving a request for a CSANR offer from the tenant; and generating the one or more CSANR offers automatically in response to and based on the request (abstract; Fig. 25 shows receiving tenant request (Fig. 25, step 1) and generating offers automatically in response (Fig. 25, step 4); The quote may include a fixed price that the client would be billed for completing the execution of the application in some embodiments. In one implementation, several alternate quotes may be provided, each with an associated time period for completing the application execution—e.g., one quote for completing the application within a week, another quote for completing the application within two weeks, and so on. In another implementation, the resource manager 180 may provide several alternate quotes for completing different fractions of execution (or different numbers of total client transactions, in the case of transactional workloads)—e.g., the resource manager 180 may provide a first quote for completing 50 simulation runs, another quote for 100 simulation runs, and so on. When the quote or set of quotes is determined, either by the resource manager 180 alone or as a result of cooperation between the resource manager 180 and the pricing optimizer 181, the quote may be provided to the client 148, as indicated by the arrow labeled “4” in FIG. 25. In response to the quote or quotes, the client 148 may submit a bid, as indicated by the arrow labeled “5”. If the bid is acceptable, the resource manager 180 may schedule the execution of the client's application if a suitable EP 2305 is available. If no appropriate EP is currently available, or if the bid is too low, the client's application package may be stored in application repository 2390 for later execution; ¶128).
Claims 8, 20, Ward discloses wherein the request for the CSANR offer includes a tenant-initiated bid for a bidded-on CSANR at a bidded-on commodity price (request including a tenant-initiated bid for the resources; The resource manager may revoke access to an interruptible instance (with or without a revocation notification to the client currently accessing the instance, and with or without a delay notification, depending on the interruptibility setting) for a variety of reasons. For example, access may be revoked if a fulfillment request for an existing reservation is received from another client, or if a higher bid for the same type of instance is received from a different client. Instances may be added to the available pool or one of the enhanced-interruptibility sub-pools for a number of reasons as well—e.g., if a client holding a reservation decides to resell the reservation, or if a reservation expires, or if the demand for on-demand instances falls. In some embodiments where interruptions with notifications indicating delay intervals are supported, the delay interval for a given resource instance may itself be variable based on the amount the client is willing to bid—e.g., for a higher bid, a longer delay may be allowed than the delay for a lower bid. In another implementation the delay may vary with the currently advertised price for enhanced-interruptibility instances—e.g., if demand for interruptible-with-notification instances falls, the delay period may be allowed to increase while keeping the price fixed, or the price may be allowed to fall while keeping the delay fixed; ¶46; The spot pricing policy 307P may allow a client 148 to specify the maximum hourly price that the client is willing to pay, and the resource manager 180 may set a spot price for a given set of resource instances 130 dynamically based on the prices clients are willing to pay and on the number of instances available to support the spot model. If a client 148's bid meets or exceeds the current spot price, an instance may be allocated to the client. If the spot price rises beyond the bid of the client using a spot instance 207, access to the instance by the client may be revoked (e.g., the instance may be shut down); ¶54; In some implementations where for example multiple interruptibility settings are supported, if a client 148 sends an upgrade request with a specified bid for a desired target interruptibility setting, and the resource manager 180 determines that the request is unacceptable, the resource manager 180 may attempt to find another interruptibility setting for which the bid is acceptable. If such an alternative setting is found, the client may be notified. For example, the client may bid $D for an upgrade from interruptibility level I1 to level I3. If the resource manager finds that $D is insufficient to enhance the interruptibility from level I1 to level I3, but is acceptable to enhance the interruptibility level from I1 to level I2, the resource manager 180 may inform the client that level I2 is acceptable, and may set the interruptibility level of the instance to I2 if the client agrees. In some embodiments, the client 148 may be able to request that the resource manager 180 select the best possible interruptibility level for a specified price that the client is willing to pay, and the resource manager may determine the specific interruptibility setting (or the length of the advance warning for access revocation) to be used for the client's instance; ¶113; In some embodiments, a client 148 may provide an application package to the resource manager 180 and ask for a quote for completing execution of the application. The resource manager may analyze the application package in response to the quote request, and may determine and provide a quote responsive to the request, taking into account various factors such as the current and/or expected future pricing of EPs 2305 appropriate for the client's application. The client 148 may receive the quote and indicate a bid responsive to the quote, e.g., as part of pricing constraint information provided with the application package. The resource manager 180 may respond to the bid affirmatively, by scheduling execution of the client's application on a suitable EP, or, if the bid is found to be insufficient, the resource manager 180 may reject the bid at least temporarily. A client 148 may ask for bid to complete execution of an application after a portion of the application has already been executed in some embodiments. For example, if an application is run for a while and then stopped as a result of a price-based interruption event, the client may submit a quote request to the resource manager to obtain an estimate of how much it might cost to complete the remaining portion of the application execution. In some implementations, if a bid responsive to a quote is initially rejected, that same bid may later be found acceptable as a result of price changes that have occurred since the initial rejection; thus, the execution of an application may be scheduled if and when the bid becomes acceptable; ¶122).
Claim 9, Ward discloses wherein the generating the one or more CSANR offers comprises generating at least one CSANR offer that is a counter-bid to the tenant-initiated bid (generating counter-bid; The resource manager may revoke access to an interruptible instance (with or without a revocation notification to the client currently accessing the instance, and with or without a delay notification, depending on the interruptibility setting) for a variety of reasons. For example, access may be revoked if a fulfillment request for an existing reservation is received from another client, or if a higher bid for the same type of instance is received from a different client. Instances may be added to the available pool or one of the enhanced-interruptibility sub-pools for a number of reasons as well—e.g., if a client holding a reservation decides to resell the reservation, or if a reservation expires, or if the demand for on-demand instances falls. In some embodiments where interruptions with notifications indicating delay intervals are supported, the delay interval for a given resource instance may itself be variable based on the amount the client is willing to bid—e.g., for a higher bid, a longer delay may be allowed than the delay for a lower bid. In another implementation the delay may vary with the currently advertised price for enhanced-interruptibility instances—e.g., if demand for interruptible-with-notification instances falls, the delay period may be allowed to increase while keeping the price fixed, or the price may be allowed to fall while keeping the delay fixed; ¶46; The spot pricing policy 307P may allow a client 148 to specify the maximum hourly price that the client is willing to pay, and the resource manager 180 may set a spot price for a given set of resource instances 130 dynamically based on the prices clients are willing to pay and on the number of instances available to support the spot model. If a client 148's bid meets or exceeds the current spot price, an instance may be allocated to the client. If the spot price rises beyond the bid of the client using a spot instance 207, access to the instance by the client may be revoked (e.g., the instance may be shut down); ¶54; In some implementations where for example multiple interruptibility settings are supported, if a client 148 sends an upgrade request with a specified bid for a desired target interruptibility setting, and the resource manager 180 determines that the request is unacceptable, the resource manager 180 may attempt to find another interruptibility setting for which the bid is acceptable. If such an alternative setting is found, the client may be notified. For example, the client may bid $D for an upgrade from interruptibility level I1 to level I3. If the resource manager finds that $D is insufficient to enhance the interruptibility from level I1 to level I3, but is acceptable to enhance the interruptibility level from I1 to level I2, the resource manager 180 may inform the client that level I2 is acceptable, and may set the interruptibility level of the instance to I2 if the client agrees. In some embodiments, the client 148 may be able to request that the resource manager 180 select the best possible interruptibility level for a specified price that the client is willing to pay, and the resource manager may determine the specific interruptibility setting (or the length of the advance warning for access revocation) to be used for the client's instance; ¶113; In some embodiments, a client 148 may provide an application package to the resource manager 180 and ask for a quote for completing execution of the application. The resource manager may analyze the application package in response to the quote request, and may determine and provide a quote responsive to the request, taking into account various factors such as the current and/or expected future pricing of EPs 2305 appropriate for the client's application. The client 148 may receive the quote and indicate a bid responsive to the quote, e.g., as part of pricing constraint information provided with the application package. The resource manager 180 may respond to the bid affirmatively, by scheduling execution of the client's application on a suitable EP, or, if the bid is found to be insufficient, the resource manager 180 may reject the bid at least temporarily. A client 148 may ask for bid to complete execution of an application after a portion of the application has already been executed in some embodiments. For example, if an application is run for a while and then stopped as a result of a price-based interruption event, the client may submit a quote request to the resource manager to obtain an estimate of how much it might cost to complete the remaining portion of the application execution. In some implementations, if a bid responsive to a quote is initially rejected, that same bid may later be found acceptable as a result of price changes that have occurred since the initial rejection; thus, the execution of an application may be scheduled if and when the bid becomes acceptable; ¶122).
Claim 10, Ward discloses wherein at least one of the one or more CSANR offers is for purchase of defined units of an indicated one of the CSANRs at an indicated unit prince (offers is for purchase of defined units, unit prince; Various embodiments of methods and apparatus for managing dynamic pricing, reservation and allocation of network-accessible resources are described. Networks set up by an entity such as a company or a public sector organization to provide one or more services (such as various types of cloud-based computing or storage) accessible via the Internet and/or other networks to a distributed set of clients may be termed provider networks in this document. Such a provider network may include numerous data centers hosting various resource pools, such as collections of physical and/or virtualized computer servers, storage devices, networking equipment and the like, needed to implement and distribute the infrastructure and services offered by the provider. The resources may in some embodiments be offered to clients in units called “instances,” such as virtual or physical compute instances or storage instances; ¶34; In one embodiment, the pricing optimizer may be used to provide recommendations for reservations or allocations of execution units (such as CPU-minutes CPU-hours, floating point operations (FLOPs), and the like) instead of, or in addition to, reservations or allocations of entire resource instances; ¶40; Clients may specify bids for execution units such as CPU-seconds, CPU-minutes, CPU-hours, floating point operations (FLOPs), integer operations, or CPU cycles (for one or more different CPU types supported by the resource manager). For other types of execution platforms and/or other types of applications, which may be disk I/O intensive or network intensive, execution units may include such metrics as total gigabytes of data read/written to a storage device, total number of I/O operations performed, or total gigabytes of data transferred over a network. Bids and/or prices may be expressible for combinations of units in some embodiments, e.g., CPU-seconds with a disk I/O transfer limit; ¶48; Excess resource capacity of a provider resource may be reserved and allocated in units of resource instances in many of the embodiments described above. In some embodiments and for certain kinds of client applications, it may be beneficial to manage and schedule resources at other granularities in addition to, or instead of, entire resource instances. FIG. 23 illustrates a system 2300 in which the resource manager 180 is configurable to determine a dynamically varying price per execution unit (expressed for example in units such as CPU-seconds, CPU-minutes, CPU-hours, MegaFLOPs, Megahertz, Gigahertz and the like) of excess resource capacity, and use the price to select client-provided applications for execution, according to at least some embodiments; ¶117).
Claim 11, analyzed with respect to claims 1 and 2.
Claim 12, Ward discloses wherein the network orchestrator function comprises a pricing interface block configured to interface communications between the network orchestrator function, the commoditization processor, the computational platform of the tenant, and the QoS interface (Fig. 1 shows various network entities providing functions comprising pricing optimizer block (el. 181), configured to interface communications between the network resource management database (el. 191), resource manager (el. 180) and interface manager (el. 182), to the implement the computational platform of the tenant function; In the illustrated embodiment, system 100 includes a resource manager 180, a pricing optimizer 181, and an interface manager 182. As noted earlier, in some embodiments the functionality of the interface manager 182 may be implemented by a subcomponent of the resource manager 180 and/or a subcomponent of the pricing optimizer 181. The interface manager 182 may in some embodiments implement one or more programmatic interfaces allowing clients 148 to search for, browse, reserve and acquire instances 130 to obtain various types of services, e.g., to run and/or access various applications; ¶50; The pricing optimizer 181, which may exist as a separate entity in some embodiments and may be incorporated as an element of the resource manager 180 in other embodiments, may be configurable to obtain information from a variety of data sources to generate recommendations on the instances that a client 148 should acquire or reserve. For example, in the embodiment illustrated in FIG. 1, the pricing optimizer 181 may obtain resource usage records or statistics from one or more provider-side metrics agents, such as agents 140A and 140B, which may provide information regarding the usage of various types of instances 130 by a client 148 over some selected period of time. The pricing optimizer 181 may use its knowledge of the trends of past or current resource usage by a given client 148 to make projections about future usage of different types of resources by the client 148. In some embodiments, resource usage metrics may also or instead be obtained from client-side devices external to the provider network 110. For example, in one implementation the pricing optimizer 181 or the resource manager 180 may provide a downloadable or otherwise installable client-side metrics agent such as 190A to a client such as 148A, and the client 148A may install and activate the agent or agents in the client's data center or client-managed premises. The client-side metrics agent 190 may gather resource usage information from various client devices 160 (e.g., 160A and 160B in client network 150A of client 148A, or 160D and 160E in client network 150B of client 148B), and transmit the usage information to the pricing optimizer 181. The pricing optimizer 181 may use the client-side usage metrics to help generate recommendations for the kinds of instances 130 that the client should consider for use. In some cases, the pricing optimizer 181 may obtain usage records from both provider-side metrics agents 140 and client-side metrics agents 190; ¶51).
Claim 13, Ward discloses the NWDAF; the NEF; and a policy control function (PCF) coupled with the NWDAF, the NEF, and a cellular core network (obtaining from a network data analysis function (NWDAF) (exemplary agents; Fig. 1, els. 140A, 140 B) resource usage, the network data analysis function coupled with a policy control function and network exposure function; In the illustrated embodiment, system 100 includes a resource manager 180, a pricing optimizer 181, and an interface manager 182. As noted earlier, in some embodiments the functionality of the interface manager 182 may be implemented by a subcomponent of the resource manager 180 and/or a subcomponent of the pricing optimizer 181. The interface manager 182 may in some embodiments implement one or more programmatic interfaces allowing clients 148 to search for, browse, reserve and acquire instances 130 to obtain various types of services, e.g., to run and/or access various applications. . . Each pool (or sub-pool) may have an associated pricing policy for its instances, as well as other properties such as interruptibility settings for the instances that happen to be assigned to the pool or sub-pool. Additional details regarding the organization of the different types of pools, various pricing policies and interruptibility policies supported in different embodiments, and the logic that may be used to move instances from one pool or sub-pool to another, will be provided below; ¶50; The pricing optimizer 181, which may exist as a separate entity in some embodiments and may be incorporated as an element of the resource manager 180 in other embodiments, may be configurable to obtain information from a variety of data sources to generate recommendations on the instances that a client 148 should acquire or reserve. For example, in the embodiment illustrated in FIG. 1, the pricing optimizer 181 may obtain resource usage records or statistics from one or more provider-side metrics agents, such as agents 140A and 140B, which may provide information regarding the usage of various types of instances 130 by a client 148 over some selected period of time. The pricing optimizer 181 may use its knowledge of the trends of past or current resource usage by a given client 148 to make projections about future usage of different types of resources by the client 148. In some embodiments, resource usage metrics may also or instead be obtained from client-side devices external to the provider network 110. For example, in one implementation the pricing optimizer 181 or the resource manager 180 may provide a downloadable or otherwise installable client-side metrics agent such as 190A to a client such as 148A, and the client 148A may install and activate the agent or agents in the client's data center or client-managed premises. The client-side metrics agent 190 may gather resource usage information from various client devices 160 (e.g., 160A and 160B in client network 150A of client 148A, or 160D and 160E in client network 150B of client 148B), and transmit the usage information to the pricing optimizer 181. The pricing optimizer 181 may use the client-side usage metrics to help generate recommendations for the kinds of instances 130 that the client should consider for use. In some cases, the pricing optimizer 181 may obtain usage records from both provider-side metrics agents 140 and client-side metrics agents 190; ¶51; Fig. 29 shows the system coupled with other devices el. 3060 via networks el. 3050 including the a cellular core network).
Claim 14, Ward discloses wherein the cellular core network is a sixth generation (6G) cellular core network (implementation of the system disclosed by Ward in a core network which may include a sixth generation (6G) cellular core network as shown in Fig. 9 as networks el. 3050).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KOUROUSH MOHEBBI whose telephone number is (571)270-7908. The examiner can normally be reached 7:30AM-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, Sujoy Kundu can be reached on 571-272-8586. 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.
/KOUROUSH MOHEBBI/Primary Examiner, Art Unit 2471