Patent Description:
<CIT> relates generally to computer services, and more specifically to accessing network services using the Universal Description, Discovery and Integration (UDDI) model, which provides a protocol for providing a requestor of a service location with one or more service locations. In the UDDI model, a client requests a location of a service from a UDDI server. The server then queries the UDDI registry to map the client request to a service location. Then, the server returns a service location to the client. Typically, the client then uses the service location to access the service.

<CIT> relates to telecommunication-systems and in-particular to domain name server (DNS) resolution systems. The DNS server may perform the latency calculations based on the location of the UE and each server, and return a list of servers that provide the requested service in the DNS response.

Aspects of the present application include a method for recommending and implementing edge computing services according to independent claim <NUM>. Further embodiments of the method are provided in dependent claims <NUM>-<NUM>.

Aspects of the present application further include a system for recommending and implementing edge computing services, according to independent claim <NUM>. Further embodiments of the system are provided in dependent claims <NUM>-<NUM>.

Further aspects of the present application include another method for recommending and implementing edge computing services, according to independent claim <NUM>.

The present application describes an edge computing recommendation and implementation system that enables an individual user and/or an entity to specify latency and/or computing service requirements, receive a recommendation for one or more service provider computing site(s), automatically procure resources necessary to provide the desired computing services, and provide the requested computing service(s) at a selected provider computing site.

<FIG> shows an example system <NUM> for providing and implementing edge computing recommendations to provide one or more computing service(s). In examples, a client device <NUM> may access a provider system <NUM> through a service portal <NUM>. In some examples, client device <NUM> may not be associated with a particular customer site. For example, client device <NUM> may be a laptop, a phone, or other wireless or wired computing device accessing the service portal <NUM> through one or more private or public networks. In other examples, client device <NUM> may be a device associated with provider system <NUM> that can be used (e.g., by representatives of the provider) in demonstrating available provider solutions for a particular customer. In other examples, a client device <NUM> that is part of a customer site <NUM> may be used to access service portal <NUM>.

In examples, the service portal <NUM> may comprise one or more computing systems, programs, applications, or combination(s) thereof to implement an interface for recommendation system <NUM>. Service portal <NUM> may, for example, interface with one or more other systems of provider system <NUM> to authenticate and authorize a particular client device <NUM>, <NUM> in using the recommendation system <NUM>. Service portal <NUM> may also interface with other portions of provider system <NUM> to allow a customer of provider system <NUM> to view, maintain, update, or otherwise utilize information relating to the customer's use of computing services offered by the provider system <NUM>. In some examples, service portal <NUM> and recommendation system <NUM> may be combined into a single device and/or system.

In examples, the provider system <NUM> may comprise multiple provider computing sites <NUM>, <NUM>, <NUM>, <NUM> each of which may comprise an edge computing site. In examples, provider computing sites <NUM>, <NUM>, <NUM>, <NUM> may be geographically dispersed to allow provider system <NUM> to efficiently provide edge computing services to customer sites, such as customer site <NUM>. Although only four provider computing sites <NUM>, <NUM>, <NUM>, <NUM> are depicted, any number of provider computing sites may be provided. In examples, a customer site <NUM> benefits from obtaining computing services from a provider computing site <NUM>, <NUM>, <NUM>, or <NUM> nearby the customer site <NUM> (to reduce latency). Further, provider computing sites <NUM>, <NUM>, <NUM>, <NUM> may not all have the same computing resources available. As discussed further herein, present systems and methods may be used to allow a customer or potential customer to find a provider computing site that has (or can be altered to have) the necessary resources available to provide a desired computing service and is close enough to a customer site to meet a customer's latency requirements.

For example, client device <NUM> may access a service portal <NUM> associated with the provider system <NUM>. The service portal <NUM> may receive a service request (e.g., through a user interface rendered on client device <NUM>) for one or more provider computing sites <NUM>, <NUM>, <NUM>, and/or <NUM> to provide computing services (e.g., host an application, host content, etc.) on behalf of a customer. Client device <NUM> may be at the customer site <NUM> or may be located elsewhere when the service request is submitted to the service portal <NUM>. In some examples, client device <NUM> and client device <NUM> are the same device.

The service request comprises customer information that includes, e.g., a location of the customer site(s) <NUM>, and the computing service being requested. The service request may also include a latency threshold or a latency requirement that indicates a maximum amount of time it should take data to reach one or more customer site <NUM> from the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM>. Although only one customer site <NUM> is depicted, multiple customer sites may be specified in the request. The latency threshold may, for example, be <NUM> or less, <NUM> or less, <NUM> or less and so on. Although specific thresholds are given, various latency thresholds may be specified. In some examples, the threshold may be based on the type of operations that will be performed by the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM>. For example, a service request may include a first latency threshold for a first type of application to be hosted and a second latency threshold for a second type of application to be hosted. In other examples, the threshold may be based on the type of data stored by the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM>.

The service request may also include the physical address/location (such as a street address) of the customer site(s) <NUM>. Additionally, the service request may indicate the type of services requested or otherwise specify the required capabilities (e.g., number of servers, server size, storage capabilities, security certifications, bandwidth, etc.) that are needed to provide the requested services. For example, the service request may include a request for a particular type of edge computing device to be allocated to the customer at the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> (e.g., a server of a particular size, that performs various actions, processes particular types of data, hosts a particular type of content). The service request may also include a request for a particular number of edge computing devices at the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> to perform the requested task(s). In examples, the service request may comprise a single request message received by the service portal <NUM>, or it may comprise a series of messages that are received, e.g., in response to prompts provided by the service portal <NUM> to client device <NUM>.

Information from the service request may be extracted by the service portal <NUM> and forwarded to the recommendation system <NUM>. Recommendation system <NUM> may use the information to determine which of the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> to recommend for customer site <NUM>. In order to make a recommendation, the recommendation system <NUM> may perform several functions: (<NUM>) determining, based on a rough latency estimate, which of the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> meet the latency requirement(s) specified in the service request; (<NUM>) determining which of the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> currently have available resources to provide the service(s) specified in the service request; (<NUM>) if required resources to provide the service(s) are not available at one or more of the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM>, determining whether such resources could be added; and (<NUM>) if required resources can be (and would need to be) added, estimating when such resources could be added; and (<NUM>) determining costs associated with providing the requested service(s) from one or more of the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM>.

For example, recommendation system <NUM> may forward the location/address information for customer site(s) <NUM> to a location system <NUM>. Location system <NUM> may convert the location/address information (such as a street address) for the customer site(s) <NUM> to global positioning system (GPS) coordinates. In some examples, the location system <NUM> may return the GPS coordinates for customer site(s) <NUM> to the recommendation system <NUM>, where the GPS coordinates are used by the recommendation system <NUM> to further process the service request. In other examples, the recommendation system <NUM> requests that the location system <NUM> determine (and return) all of the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> that are within a particular service radius from customer site(s) <NUM>. For example, recommendation system <NUM> and/or location system <NUM> may also store location information (such as GPS coordinates) of all of the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM>. The recommendation system <NUM> and/or location system <NUM> may then use the GPS coordinates of both the customer site(s) <NUM> and the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> to determine which of the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> are within the service radius of customer site(s) <NUM>.

In examples, the service radius may be determined (by recommendation system <NUM> and/or location system <NUM>) based on the latency requirement(s) in the service request. In an example (e.g., where the provider system <NUM> comprises an optical fiber network), the service radius may be based, at least in part, on the speed of light. For example, the speed of light is <NUM>,<NUM> miles per second, which is equivalent to <NUM> miles per millisecond. If the specified latency requirement is less than or equal to <NUM>, the allowable service radius between a customer site <NUM> and a location of the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> is <NUM> miles. Distance between the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> and the customer site <NUM> can be used as a rough estimate of latency. In this example, a provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> that is located outside of the <NUM> mile radius may not be considered a potential provider computing site since it could not meet the specified <NUM> latency requirement. In some examples, one or more provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> that are outside of this example <NUM> mile radius may still be considered or otherwise identified as an alternative edge computing device/site. Alternative provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> may be selected for use by a customer, e.g., if other options are not available and/or desirable.

In examples, the rough latency estimate (and radius calculation) may be based on a straight line distance between the customer site(s) and the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM>. The rough latency estimate (and radius calculation) may also be altered or otherwise updated/refined based on known communication line path(s) (e.g., fiber paths) between the customer site(s) <NUM> and the locations of (or near) the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM>. For example, if the fiber path is relatively straight between the user/entity and the edge computing device/site, the calculation may be relatively accurate. However, if the fiber path follows various curves in a road, the calculation may need to be adjusted/altered to account for potentially longer distances along the fiber path(s). In examples, recommendation system <NUM> and/or location system <NUM> may store and use fiber path maps to determine a more accurate fiber path distance between the customer site(s) <NUM> and the locations of the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM>. The rough latency estimate using the refined fiber path distance measurement/estimation may then be used in identifying the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> that are likely to meet the specified latency requirements.

In some examples, one or more of the nearest provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> may not have available resources to provide the requested service(s). For example, provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> may not have enough available or desired server(s), bandwidth, hardware, space, storage, correct operating system instance(s), security certification(s), or other resources to provide the requested service(s). In examples, the recommendation system <NUM> may determine resource availability at the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM>. For example, the recommendation system <NUM> may determine necessary resources to provide the requested service (e.g., a certain number of servers of a particular size, having a particular number of ports, etc.) and query an inventory system <NUM> to determine which of the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> have the necessary available resources. In some examples, the recommendation system <NUM> may first determine the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> that meet the specified latency requirements (at least using the rough estimate(s) of latency) and query the inventory system <NUM> only for those the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM>. In other examples, the recommendation system <NUM> may first determine the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> that have (or can be altered to have) the necessary available resources and then determine from that list the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> that meet the specified latency requirements. Other orders of operation are also possible.

In examples, the inventory system <NUM> is a computing system that is updated periodically to reflect the resources present, currently used, and currently available at the provider computing site(s) <NUM>, <NUM>, <NUM>, and <NUM>. Recommendation system <NUM> may then verify resource availability by querying inventory system <NUM>.

In examples, when a provider computing site <NUM>, <NUM>, <NUM>, and/or <NUM> does not have the necessary available resources, the recommendation system <NUM> may determine whether the missing resources could be added to that provider computing site <NUM>, <NUM>, <NUM>, and/or <NUM>. In some examples, the recommendation system <NUM> may make such a determination only if the particular provider computing site <NUM>, <NUM>, <NUM>, or <NUM> is otherwise of interest. For example, recommendation engine <NUM> may be configured to, if the closest provider computing site (or one of a predetermined number of the closest sites) does not have the necessary resources available, query a procurement system <NUM> to determine if the missing, necessary resources can be added. In examples, procurement system <NUM> may comprise a computing system that is updated with information necessary to determine whether, and to estimate when, the missing, necessary resources can be added to a particular provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM>.

For example, recommendation system <NUM> may determine from the service request that a customer will need two servers of a particular size to provide the requested computing service. The recommendation system <NUM> may query the location system <NUM> and determine that provider site A <NUM> is the closest provider computing site to customer site <NUM>, and that it is the only one of provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> that is within the service radius necessary to meet latency requirements included in the service request. Further, recommendation system <NUM> may query inventory system <NUM> and determine that only one server of the requisite size is currently available at provider site A <NUM>. Recommendation engine <NUM> may then query procurement system <NUM> to determine whether a server of that size can be added to provider site A <NUM>, and, if so, when that server could be added to provider site A <NUM>. In examples, procurement system <NUM> may query internal or external systems to determine whether the missing, necessary resource can be added to provider site A <NUM> (e.g., whether there is available space in a rack for a server of that size, whether any power or other site thresholds would be exceeded, etc.). The procurement system <NUM> may also determine whether that required server exists in the provider's inventory, would need to be procured from a third party, and when it could be, in either case, delivered and installed.

In examples, recommendation system <NUM> may also determine costs associated with providing the service from one or more of the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM>. For example, a customer may be charged different costs for providing the service from different ones of provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM>, including any costs associated with adding missing, necessary resources to such site(s) in order to provide the requested computing service.

In examples, recommendation system <NUM> can then provide one or more initial recommendations to client device <NUM> (e.g., through service portal <NUM>) regarding which provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> can provide the requested computing service. The recommendation may comprise an ordered list of best-match provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM>. The recommendation may also include additional information about the site(s), including location, quantities of available resources, the rough estimate of latency, costs, etc. The order of the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> on the recommendation list may be based on (and/or sortable on) the rough estimate of latency for each site, costs, the date that all necessary resources are estimated to be available, or any other metric. In examples, only sites where the rough latency estimate meets the latency requirement of the service request and that have the necessary resources (or where the necessary resources can be added within a particular time period) are included in the recommendation. In other examples, a certain number of best-matching provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> are included in the recommendation, regardless of whether one or more of the request parameters are not met. For example, if a rough estimate of latency for a provider computing site is only slightly higher than the latency requirement in the service request, that site may still be included in the list (e.g., with the rough estimate of latency noted).

In some examples, a customer may be given the option to obtain a fine estimate of latency by performing an actual latency test on a test server installed at a particular one or more of provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM>. For example, recommendation system <NUM> may return a list of recommended provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> along with the rough estimate of latency for each. Service portal <NUM> may provide a selectable option to cause a traceroute test to be performed between a client device <NUM> at customer site <NUM> and one or more of the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> in the initial recommendation list from recommendation system <NUM>. In other examples, the traceroute test may be initiated without an initial recommendation from recommendation system <NUM> or a selection from client device <NUM>.

In examples, upon receiving selection of the option to cause a fine estimate of latency to be performed, service portal <NUM> may redirect client device <NUM> to a test portal <NUM>. In some examples, test portal <NUM> and service portal <NUM> may be combined. Test portal <NUM> may query the client device <NUM> to determine whether client device <NUM> is located at the customer site <NUM>. For example, an operator of client device <NUM> may be prompted for that information or that information may be determined or inferred based on the IP address of the client device <NUM> and/or the routing of any messages from client device <NUM>. If client device <NUM> is not at customer site <NUM>, the test portal <NUM> may prompt an operator of client device <NUM> to enter (and send to test portal <NUM> and/or service portal <NUM>) an IP address of a client device that is at customer site <NUM> (such as client device <NUM>). Test portal <NUM> and/or service portal <NUM> may then cause a software agent to be sent to and installed upon client device <NUM>.

Such software agent may be configured to run a latency test between client device <NUM> and the one or more provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> that are of interest. For example, if provider site C <NUM> is a provider computing site of interest (e.g., is in the initial recommendation list), then the software agent on client device <NUM> may be configured to send a traceroute request to test server C operating at provider site C <NUM>, e.g., via a network such as network <NUM>. Network <NUM> may be any type of public network (e.g., Internet), private network, hybrid network, etc. The test servers (such as test server C) may be instantiated when needed or may be continually operating at each provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM>. Test server C operating at provider site C <NUM> may then respond to the latency test, and the software client on client device <NUM> may report the results to test portal <NUM> and/or service portal <NUM>. In other examples, the test portal <NUM>, service portal <NUM>, and/or recommendation system <NUM> may cause the latency test to be initiated from the test server C operating at provider site C <NUM> to the software agent operating on client device <NUM> and report the results to the test portal <NUM> and/or service portal <NUM>. This procedure can be repeated for multiple of provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> that are of interest. In this manner, more accurate latency estimations can be made before a customer determines which provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> should be selected. In examples, the list of recommended provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> may be reordered based on the fine latency estimate and presented again, e.g., in service portal <NUM>.

In examples, a selection of particular provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> on which a customer desires to initiate the requested computing service may then be received (e.g., at service portal <NUM>). For example, a customer may enter a final selection and order the requested service through service portal <NUM>. Procurement system <NUM> may then be used to automatically procure any missing, necessary resources that were identified for the selected site(s). For example, this may include automatically ordering new equipment, causing installation of new servers and/or communications lines, etc..

The requested computing service can then be instantiated and provided from the selected provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> to customer site <NUM>. For example, if the requested computing service comprises the use of two servers at provider computing site <NUM>, then the servers may be assigned to the customer, installed, allocated IP address(es), configured with any necessary software/operating system, etc., and made available to the customer site(s) <NUM>.

<FIG> illustrates an example method <NUM> for recommending and implementing edge computing for a customer. In examples, some or all of the operations of method <NUM> may be implemented by a recommendation system, such as recommendation system <NUM> in <FIG>; however, certain operations may be performed by one or more other elements of system <NUM> depicted in <FIG>.

At operation <NUM>, customer information is received in a service request. For example, recommendation system <NUM> and/or service portal <NUM> may receive a service request. The request may include customer information comprising, e.g., a desired computing service and customer location data for a customer site to which the requested computing service is to be provided. For example, the customer information may include a request for the use of two servers of a particular size and an address of a customer site (such as customer site <NUM>) at <NUM> Maple Avenue, Nowhere, CO <NUM>.

At operation <NUM>, a latency requirement is received. For example, the customer information included in the service request may specify a maximum latency that a customer desires for the requested computing service. In examples, operation <NUM> and <NUM> can be combined. In other examples, the latency requirement may be received separately. In some examples, the latency requirement may be obtained from other systems. For example, the recommendation system <NUM> may query existing computing systems within the provider system <NUM> to determine the average latency that the customer is currently experiencing and use that as a latency requirement.

At operation <NUM>, a service radius is determined based on the latency requirement. For example, recommendation system <NUM> may determine a maximum distance that a provider computing site (e.g., provider computing site(s) <NUM>, <NUM>, <NUM>, <NUM>) may be from the customer site <NUM> in order to deliver the requested computing service and meet the latency requirement. In examples, the service radius may be based on the speed of light multiplied by the latency requirement (in the form of a maximum latency limit). In other examples, the service radius may be determined differently based on the nature of the network.

At operation <NUM>, provider location data for a plurality of provider computing sites is determined. For example, recommendation system <NUM> may determine (or cooperate with location system <NUM> to determine) locations of provider computing site(s) <NUM>, <NUM>, <NUM>, <NUM>. In examples, the provider location data may be in the form of GPS coordinates for provider computing site(s) <NUM>, <NUM>, <NUM>, <NUM>.

At operation <NUM>, a rough estimate of latency for each of the plurality of provider computing sites is determined based on the customer location data and the provider location data. For example, recommendation system may determine (or cooperate with location system <NUM> to determine) a distance between the customer site <NUM> and each of the plurality of provider computing site(s) <NUM>, <NUM>, <NUM>, <NUM>. As discussed, this may include converting the customer location data to GPS coordinates and determining a straight-line distance between the provider computing site(s) <NUM>, <NUM>, <NUM>, <NUM> and the customer site <NUM>. In other examples, a map that fiber or other network transport actually follows between the customer site <NUM> and each of the provider computing site(s) <NUM>, <NUM>, <NUM>, <NUM> may be used to determine the distance. Determining the rough estimate of latency, in some examples, may include converting the distance to a latency estimate expressed in terms of time (e.g., based on the speed of light). In other examples, determining the rough estimate of latency may comprise determining that the distance is less than the service radius (thus suggesting that the provider computing site(s) <NUM>, <NUM>, <NUM>, <NUM> in question will be able to meet the latency requirement).

At operation <NUM>, it is determined whether at least a first provider computing site includes available resources necessary to provide the computing service. For example, recommendation system <NUM> may determine (or cooperate with inventory system <NUM> to determine) whether one or more of the provider computing site(s) <NUM>, <NUM>, <NUM>, <NUM> currently has resources available to provide the computing service that was requested by the customer. In examples, operation <NUM> may be performed for all provider computing site(s) <NUM>, <NUM>, <NUM>, <NUM> that meet the latency requirement (e.g., that are within the service radius). In other examples, resource availability for more or fewer provider computing site(s) <NUM>, <NUM>, <NUM>, <NUM> may be determined.

When the first provider computing site does include available resources necessary to provide the computing service, flow branches to operation <NUM>, where the first provider computing site is included on a list of recommended provider computing site(s). For example, if provider computing site A <NUM> is determined to be within the service radius and has the available resources necessary to provide the computing service, then it may be included on the recommended provider computing site list generated by recommendation system <NUM>.

When the first provider computing site does not include available resources necessary to provide the computing service, flow branches to operation <NUM>, where it is determined whether additional resources can be added to the first provider computing site to provide the computing service. For example, if provider computing site A <NUM> is determined to be within the service radius, but does not have the available resources necessary to provide the computing service, recommendation system <NUM> may determine (or cooperate with procurement system <NUM> to determine) whether the missing, necessary resources may be added to provider computing site A <NUM> to provide the requested computing service. In examples, such determination may also include determining when such additional resources could be added.

When the additional resources can be added to the first provider computing site to provide the computing service, flow branches to operation <NUM>, where the first provider computing site may be included on the list of recommended computing site(s), along with an indication of when the additional resources can be added. When the additional resources cannot be added to the first provider computing site, flow branches to operation <NUM>, where the first provider computing site may be excluded from the list of recommended provider computing site(s).

Flow proceeds to operation <NUM>, where a list of provider computing site(s) is provided. For example, the recommendation system <NUM> may provide a list of recommended provider computing site(s) <NUM>, <NUM>, <NUM>, <NUM> to service portal <NUM> and/or client device <NUM> based on, e.g., the rough estimate of latency for the provider computing site(s) <NUM>, <NUM>, <NUM>, <NUM>, resource availability (current or potential), or other metrics. In some examples, the list of recommended provider computing site(s) is limited only to site(s) that are within the service radius and have (or could be modified to have) the necessary resources to provide the requested computing service.

Flow proceeds to optional operation <NUM>, where a fine estimate of latency may be determined and used to refine the list of provider computing site(s). An example of operation <NUM> is described with relation to <FIG>.

Flow proceeds to operation <NUM>, where a selection of at least one of the list of provider computing site(s) is received. For example, client device <NUM> may receive a user selection of one of the recommended provider computing site(s) <NUM>, <NUM>, <NUM>, <NUM> through a user interface and communicate the selection to the service portal <NUM> and/or recommendation system <NUM>.

Flow proceeds to operation <NUM>, where the requested computing service is provided to the customer site from the selected provider computing site(s). For example, procurement system <NUM> may then be used to automatically (e.g., in response to receiving the selection of the provider computing site(s)) procure any missing, necessary resources that were identified for the selected provider computing site(s). The requested computing service can then be instantiated and provided from the selected provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> to customer site <NUM>. For example, if the requested computing service is the use of two servers at provider computing site A <NUM>, then the servers may be automatically assigned to the customer, installed, allocated IP address(es), configured with any necessary software/operating system, etc., and made available to the customer site.

<FIG> depicts an example method <NUM> for determining and using a fine estimate of latency to refine the list of provider computing site(s). In examples, method <NUM> may comprise optional operation <NUM> in <FIG>. At operation <NUM>, a selectable option may be provided to initiate a fine estimate of latency. For example, recommendation system <NUM> may return an initial list of recommended provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> along with the rough estimate of latency for each. Service portal <NUM> may provide a selectable option to client <NUM> to cause a latency test to be performed between a client device <NUM> at customer site <NUM> and one or more of the provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> in the initial recommendation list.

Flow proceeds to operation <NUM>, where an indication of selection of the selectable option to initiate a fine estimate of latency is received. For example, service portal <NUM> and/or recommendation system <NUM> may receive an indication of the selection from client device <NUM>. The indication of selection may, in examples, be for particular ones of the provider computing site(s), for all of the provider computing site(s) appearing on the initial recommendation list, for a specified number of top-recommended provider computing site(s) on the initial recommendation list, or otherwise.

Flow proceeds to operation <NUM>, where it is determined whether the client device that provided the indication is at the customer site. For example, test portal <NUM> and/or service portal <NUM> may query the client device <NUM> to determine whether client device <NUM> is located at the customer site <NUM>. In examples, an operator of client device <NUM> may be prompted for that information or it may be automatically determined or inferred.

If the client device is not at the customer site, then flow proceeds to operation <NUM>, where an address for a client device at the customer site is determined. For example, if client device <NUM> is not at customer site <NUM>, the test portal <NUM> and/or service portal <NUM> may prompt an operator of client device <NUM> to enter (and send to test portal <NUM> and/or service portal <NUM>) an IP address of a client device that is at customer site <NUM> (such as client device <NUM>).

Flow proceeds to operation <NUM>, where a software agent is caused to be installed at a client device at the customer site. For example, test portal <NUM> and/or service portal <NUM> may cause a software agent to be sent to and installed upon client device <NUM>. In examples, operation <NUM> may include sending a software agent to the client device <NUM> and prompting a user to install the software agent.

Flow proceeds to operation <NUM>, where a latency test is caused to be run between the client device and provider computing site(s) that are of interest. In examples, the software agent may be configured to initiate a latency test between client device <NUM> and the one or more provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> that appeared in the initial recommendation list based on the rough latency estimates. For example, if provider site C <NUM> is the provider computing site of interest, then the software agent on client device <NUM> may be configured to send a traceroute request to test server C operating at provider site C <NUM>, e.g., via a network such as network <NUM>. Test server C operating at provider site C <NUM> responds to the latency test. In other examples, the test portal <NUM>, service portal <NUM>, and/or recommendation system <NUM> may cause the latency test to be initiated from the test server C operating at provider site C <NUM> to the software agent operating on client device <NUM>.

At operation <NUM>, the results of the latency test are received. For example, the software client on client device <NUM> and/or the test server operating on the one or more provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> may report the results to test portal <NUM>, recommendation system <NUM>, and/or service portal <NUM>.

At operation <NUM>, it is determined whether the latency test should be run on additional provider computing site(s). For example, system <NUM> may automatically repeat operations <NUM> and <NUM> for all provider computing site(s) appearing on the initial recommendation list from recommendation system <NUM> that was based on the rough estimate of latency. In other examples, operations <NUM> and <NUM> are repeated for only a certain number of the top-recommended provider computing site(s) on the initial recommendation list. In other examples, operations <NUM> and <NUM> are repeated for all provider computing site(s) that were indicated as selected at operation <NUM>.

When no further latency tests are to be run on additional provider computing site(s), flow proceeds to operation <NUM>, where the list of recommended provider computing site(s) is redetermined based on the fine estimate(s) of latency. For example, recommendation system <NUM> may replace the rough estimate of latency with a fine estimate of latency for each provider computing site for which operations <NUM> and <NUM> were performed. Recommendation system <NUM> can then use the fine estimate of latency in generating a revised list of recommended provider computing site(s). As discussed, the order of the provider computing site(s) on the recommendation list may be based on (and/or sortable on) the estimate of latency for each site, costs, the date that all necessary resources are estimated to be available, or any other metric. In some examples, the list of recommended provider computing site(s) <NUM>, <NUM>, <NUM>, and/or <NUM> may be reordered based on the fine latency estimate. In other examples, the fine estimate of latency will not change the order of the recommended list of provider computing site(s).

Flow proceeds to operation <NUM>, where the redetermined (and possibly revised) list of recommended provider computing site(s) is provided. For example, the recommendation system <NUM> may cause the redetermined list of recommended provider computing site(s) to be presented again in or through service portal <NUM> to client device <NUM>.

<FIG> is a system diagram of a computing device <NUM> according to an example. The computing device <NUM>, or various components and systems of the computing device <NUM>, may comprise, or be integrated or associated with, elements of system <NUM>, including at least client device <NUM>, client device <NUM>, customer site <NUM>, service portal <NUM>, recommendation system <NUM>, provider computing sites <NUM>, <NUM>, <NUM>, <NUM>, location system <NUM>, inventory system <NUM>, procurement system <NUM>, and/or test portal <NUM>. As shown in <FIG>, the physical components (e.g., hardware) of the computing device <NUM> are illustrated and these physical components may be used to practice the various aspects of the present disclosure.

The computing device <NUM> may include at least one processing unit <NUM> and a system memory <NUM>. The system memory <NUM> may include, but is not limited to, volatile storage (e.g., random access memory), non-volatile storage (e.g., read-only memory), flash memory, or any combination of such memories. The system memory <NUM> may also include an operating system <NUM> that controls the operation of the computing device <NUM> and one or more program modules <NUM>. The program modules <NUM> may be responsible for gathering or determining enterprise information <NUM> such as domain information, telephone numbers, attestation level requests and so on. A number of different program modules and data files may be stored in the system memory <NUM>. While executing on the processing unit <NUM>, the program modules <NUM> may perform the various processes described above.

The computing device <NUM> may also have additional features or functionality. For example, the computing device <NUM> may include additional data storage devices (e.g., removable and/or non-removable storage devices) such as, for example, magnetic disks, optical disks, or tape. These additional storage devices are labeled as a removable storage <NUM> and a non-removable storage <NUM>.

Examples of the disclosure may also be practiced in an electrical circuit comprising discrete electronic elements, packaged or integrated electronic chips containing logic gates, a circuit utilizing a microprocessor, or on a single chip containing electronic elements or microprocessors. For example, examples of the disclosure may be practiced via a system-on-a-chip (SOC) where each or many of the components illustrated in <FIG> may be integrated onto a single integrated circuit. Such a SOC device may include one or more processing units, graphics units, communications units, system virtualization units and various application functionality all of which are integrated (or "burned") onto the chip substrate as a single integrated circuit.

When operating via a SOC, the functionality, described herein, may be operated via application-specific logic integrated with other components of the computing device <NUM> on the single integrated circuit (chip). The disclosure may also be practiced using other technologies capable of performing logical operations such as, for example, AND, OR, and NOT, including but not limited to mechanical, optical, fluidic, and quantum technologies.

The computing device <NUM> may include one or more communication systems <NUM> that enable the computing device <NUM> to communicate with other computing devices <NUM> such as, for example, routing engines, gateways, signings systems and the like. Examples of communication systems <NUM> include, but are not limited to, wireless communications, wired communications, cellular communications, radio frequency (RF) transmitter, receiver, and/or transceiver circuitry, a Controller Area Network (CAN) bus, a universal serial bus (USB), parallel, serial ports, etc..

The computing device <NUM> may also have one or more input devices and/or one or more output devices shown as input/output devices <NUM>. These input/output devices <NUM> may include a keyboard, a sound or voice input device, haptic devices, a touch, force and/or swipe input device, a display, speakers, etc. The aforementioned devices are examples and others may be used.

The term computer-readable media as used herein may include computer storage media.

The system memory <NUM>, the removable storage <NUM>, and the non-removable storage <NUM> are all computer storage media examples (e.g., memory storage). Computer storage media is non-transitory and does not include a carrier wave or other propagated or modulated data signal.

Claim 1:
A method (<NUM>), comprising:
receiving (<NUM>) customer information in a service request, wherein the customer information includes at least a desired computing service and customer location data for a customer site (<NUM>);
determining (<NUM>) provider location data for a plurality of provider computing sites (<NUM>, <NUM>, <NUM>, <NUM>);
determining (<NUM>) a rough estimate of latency for each of the plurality of provider computing sites (<NUM>, <NUM>, <NUM>, <NUM>) based on the customer location data and the provider location data;
providing (<NUM>) a list of the provider computing sites (<NUM>, <NUM>, <NUM>, <NUM>) based on the rough estimate of latency for each of the provider computing sites (<NUM>, <NUM>, <NUM>, <NUM>);
determining (<NUM>) whether a first provider computing site of the plurality of computing sites (<NUM>, <NUM>, <NUM>, <NUM>) includes available resources necessary to provide the computing service;
when the first provider computing site does include available resources necessary to provide the computing service, including the first provider computing site on the list;
when the first provider computing site does not include available resources necessary to provide the computing service:
determining (<NUM>) whether additional resources can be added to the first provider computing site to provide the computing service;
when the additional resources can be added to the first provider computing site to provide the computing service, including the first provider computing site on the list along with an indication of when the additional resources can be added; and
when the additional resources cannot be added to the first provider computing site, excluding the first provider computing site from the list;
receiving (<NUM>) a selection of one of the provider computing sites; and
providing (<NUM>) the computing service to the customer site from the selected provider computing site.