Amazon Technologies, Inc.

Hok Peng Leung

Geoffrey Scott Pare

Christopher Paul Dury

Ethan Zane Evans

Michael Martin George

Michael Anthony Frazzini

Collin Charles Davis

Patrick Gilmore

Francis Xavier Surjo-Subagio

David Hendrik Verfaillie

Michael Anthony Willette

Richard Bantegui

Christopher David Byskal

Alexis Levasseur

Antonio Vargas Garcia

Bruce Erwin Brown

Robert Battle

Aleksey A Polesskiy

Richard Franklin Porter

Bradley Heath

Prasad Vyawahare

Zane Grey Reynolds

An update deployment service performs automatic testing and deployment of a software update (e.g., security patches) for a software component on a fleet of IoT devices, without the need for the client to test the update and manually deploy the update to the IoT devices. A client configures the service by providing an upper usage limit for certain IoT hardware components (e.g., memory, hard disk) and/or code components (e.g., threads) that may be caused by any future updates. When a new update is available for deployment, the update deployment service obtains usage test data that indicates the amount of usage (or increase in usage) of the IoT hardware and/or code for the new update. If the usage (or increase in usage) is within the client-provided usage limits, then the service automatically deploys the update to the fleet of edge devices.

Automatic deployment of updates for edge device software components based on edge usage limits

Technology is described for receiving a request for data packets at a server from a device. The server may determine a predicted number of data packets that are expected to be lost during fulfillment of the request based in part on a device profile. The server may send, in response to the request, the requested data packets and parity packets to the device. The number of parity packets may be based on the predicted number of data packets. The parity packets may enable the device to rebuild requested data packets that are lost during fulfillment of the request.

Dynamic determination of parity packets for data transmissions

A game spectating system that leverages game metadata to allow spectators to join or 'step into' games being broadcast. Broadcast content may include user interface elements via which spectators can order, purchase, or otherwise obtain demo or full versions of games. Game client software and game data may be obtained and downloaded to the spectator's devices via the spectating system interfaces and broadcast streams. Spectators can order, purchase, or otherwise obtain characters, avatars, and gear for participation in particular games. Using the spectating UI to obtain the game client software, game data, characters, and gear via the broadcast streams, the spectators may join live game sessions of online games, start new game sessions, and/or replay previously recorded game sessions.

Joining games from a spectating system

Live migration can be performed for a process executing on an allocated resource for an application session. During a session it might be determined that it is necessary, or would at least be advantageous, to migrate the process to different resource capacity. New capacity such as a new computing instance can be identified, and synchronized with a current instance to reflect current state information. This can include obtaining state data from a serialized file or transaction log, among other such options. The client devices on the session can be caused to connect or direct state data to the new instance, and when ready the new instance can be responsible for the process, such as by taking over as the application server for the session. Once the client devices are utilizing the new instance, the process can be terminated on the old instance and the instance destroyed or reallocated.

Live migration for hosted sessions

Resources for hosting game sessions can be dynamically selected based upon factors in addition to availability and capacity. A requested session may have various criteria enabling it to be hosted on different types of resources, such as different types of resource instances operating on physical servers. While a fixed amount of capacity can be purchased over an extended period of time, options can also exist that enable purchasing resource capacity for a limited period of time, or purchasing excess capacity without a fixed time limit but that is subject to potential interruption. Benefits relating to cost and performance may offset these potential limitations, and the selection of a type of resource to host a game can be based upon an analysis of these factors. If a game session is to be interrupted or will time out, advance notice can be provided such that the game can take a corresponding action.

Resource selection for hosted game sessions

Techniques for concurrent execution of multiple content item processes, such as video game processes, on a single virtual machine instance are described herein. In some examples, developers may provide an indication of a desired content item process quantity count, which is a quantity of content item processes for concurrent execution of content item sessions on each of one or more virtual machine instances. Also, in some examples, the content item process quantity count may be adjustable such that it may be changed, for example in response to various conditions or events. Also, in some cases, collected performance metric information may be used to make intelligent decisions regarding scaling of content item processes. In some examples, when a content item session stops executing on a healthy content item process, the content item process may remain active and may be reused by executing one or more subsequent content item sessions.

Virtual machine with multiple content processes

A game spectating system that provides interfaces and methods for providing game content to viewers. The spectating system obtains game metadata from game systems for games being broadcast by the spectating system according to the API, and generates broadcast content based at least in part on the game metadata. The broadcast content includes user interface (UI) elements for obtaining virtual or physical objects corresponding to the game content. The broadcast content is provided to spectator devices with the broadcasts. The spectating system receives indications of spectators' interactions with the broadcast content from the spectator devices including interactions requesting the virtual or physical objects, and facilitates provisioning or delivery of the objects to respective spectator devices or spectators.

Game content interface in a spectating system

Shared electronic resources can be allocated for a gaming application on a dynamic basis. A package of game content and configuration can be used to allocate an appropriate amount of resource capacity. Task-based instances can be launched as needed and terminated once a gaming session has completed. In order to account for relatively long load times, a number of pre-warmed task-based instances can be allocated that can load the game server functionality up to a determined state. The number of pre-warmed instances can be based on a number of different factors, such as an amount of unused capacity across a shared resource environment. When a request for a session is received, a pre-warmed instance is selected to be upgraded to a game server instance to serve the game session for the request. Pre-warmed instances can be reclaimed if capacity is needed for other purposes.

Dynamic resource allocation for gaming applications

Techniques for content item instance access control are described herein. A computing service provider may host execution of a plurality of instances of an interactive content item, such as a video game. Each content item instance may be accessible to a respective set of one or more authorized clients that are associated with the respective content item instance and that are authorized to access the respective content item instance. Additionally, in one embodiment, each content item instance may be inaccessible to one or more unauthorized clients, such as clients that are not associated with the respective content item instance and that are not included in the set of authorized clients. By limiting access to a content item instance to authorized clients, the content item instance may be protected from malicious users, such as hackers, DoS and DDos attackers, and other malicious users.

Content item instance access control

A spectating system that leverages game metadata and/or broadcast metadata to provide rewards to or otherwise acknowledge participants in broadcasts. The system may analyze the metadata to detect events or other information about broadcasts, and may recognize and/or reward participants based at least in part on the analysis. Spectators may be rewarded for participating in broadcasts, or in particular events in broadcasts. Broadcasters may be rewarded for in-game achievements or for achieving levels of audience participation or support. Participants may select or vote on other participants to receive rewards. Rewards may, for example, include acknowledgement of participants via the user interface, virtual items such as in-game virtual gear, physical items such as game-related merchandise, and granting of benefits or privileges by the spectating system and/or game system such as special content for a broadcaster's channel.

Participant rewards in a spectating system

A spectating system that generates game inputs based on spectator inputs and interactions, and provides the game inputs to game systems according to an application programming interface (API). The spectating system may allow spectators to interact with and affect a game being broadcast via inputs to and interactions with user interface (UI) elements presented on the spectating UI. Spectators may affect or influence the game, objects within the game universe, events within the game, or the players in the game via the UI elements on the spectating UI. The spectators may become involved in the games being broadcast by influencing game play via the spectating inputs. Game play for the players may be enhanced by providing interesting variations in game play based on the spectating inputs.

Spectator interactions with games in a specatating system

Techniques for wait time based scaling of content item instances are described herein. In some examples, a customer of a computing service provider may select a wait time threshold for joining one or more of the customer's content items that are hosted by the computing service provider. When a joining user logs-in and requests to join a content item, a calculation may be made regarding an estimated wait time for the user to join one or more existing content item instances. The estimated wait time may then be compared to the wait time threshold. A determination may then be made regarding whether or not to launch a new content item instance in response to the user's join request. In some examples, this determination may be based, at least in part, on the comparison of the estimated wait time to the wait time threshold.

Content item instance scaling based on wait time

Techniques for debugging of hosted computer programs are described herein. Execution of a set of instances of a computer program may be hosted by a service on behalf of a developer. The developer may indicate one or more error conditions and an amount of program instances to be monitored for the error conditions. The error conditions may include breakpoints, processing conditions, memory conditions, network packet conditions, and others. A subset of the program instances may be monitored for an error conditions. An error condition may then be detected at a first program instance. A notification of the occurrence of the error condition may be provided to the developer along with information for connecting to the first program instance. The developer may connect to and debug the first program instance, and may also access information such as a memory dump, performance logs, network packet information, and more.

Growing community of inventors

Redmond, WA, United States of America

Hok Peng Leung