Patent Description:
At least partly to ensure the integrity of application downloads and updates, as well as for other reasons (e.g., to save money that might otherwise be incurred using an Internet service implemented over WiFi®, cellular, or other type of network that requires a user fee), some remote systems may refrain from sending an application update until a target computing device can communicate with the remote system via a free Wi-Fi® or other relatively inexpensive, reliable, high-bandwidth connections. However, some computing devices communicate almost exclusively via cellular or other less reliable or lower-bandwidth connections that may not always satisfy the connectivity requirements imposed by such remote systems. As a result, a computing device that infrequently maintains a network connection that satisfies a remote system's connectivity requirements may not always receive application updates in a timely manner, if at all. <CIT> discloses balancing resources between computers in a peer to peer network. The balancing involves determining an amount of transferable resource residing at a local peer computer and an amount of transferable resource which resides on a neighbouring peer computer and assessing the difference between the two amounts. Based upon this assessment a transfer of resource between said local peer computer entity and said neighbouring peer computer entity can be initiated. The assessment is based upon a mathematical difference between the amount of transferable resource resident on the computers compared with a pre-determined threshold value. <CIT> provides an approach for dynamically acquiring computing resources in a networked computing environment (e.g., a cloud computing environment) based on infrastructure/computing resource needs.

The matter for protection is defined by the appended claims. In general techniques of this disclosure are directed to enabling intra-device transfers of application resources that are required by devices to perform local updates of applications executing at the devices as well as to perform other operations that require additional data not already stored on-device. As used herein, the term "application resources" represents one or more libraries, expansion packs (e.g., map packs, translation or language packs, additional game challenges, game levels, etc.), source files, executable packages, media content (e.g., audio or video files), other application information (e.g., news-related content, promotions, advertising information) or other software components that are generally user independent (i.e., not user specific) and used during local installation, execution, or update of one or more executable applications or computing services. Rather than maintain a connection to a remote system to obtain application resources that are required to perform an application update, an example computing device executes a download manager that negotiates transfers of application resources from other nearby devices that are required to perform the update. For example, applications executing at the example computing device may, over time, register with the download manager resource needs (e.g., libraries, source files, executable packages, or other software component that is required to perform an application update) for their respective update cycles.

On behalf of the registered applications, the download manager may seek out other nearby computing devices that already have the software components that can satisfy at least some of the registered resource needs. In response to identifying a nearby device that can satisfy at least one registered need, the example computing device may establish a direct communication link with the nearby device to transfer to the example computing device the software component(s) that satisfy the at least one registered need. In response, the download manager executing at the computing device may notify a waiting application of a new available resource, thereby enabling the waiting application to complete its application update without necessarily having to communicate directly with a remote computing system that supports an application market, application store, or other such application repository.

Throughout the disclosure, examples are described where a computing device and/or computing system may analyze information (e.g., application resource needs and the like) associated with the computing device only if the computing device and/or the computing system receives explicit permission from a user of the computing device to analyze the information. For example, in situations discussed below in which the computing device and/or computing system may collect information about available resources or resource needs of applications executing at the computing device, the user may be provided with an opportunity to provide input to control whether programs or features of the computing device (e.g., a download manager) can collect and make use of the information and may further be provided with an opportunity to control what the programs or features can or cannot do with the information. In addition, certain information may be pre-treated in one or more ways before it is transferred, stored, or otherwise used by a computing device and/or computing system, so that personally-identifiable information is removed. For example, before an example computing device transfers an available resource to a computing device in-need, the example computing device may pre-treat the available resource to ensure that any user identifying information embedded in the available resource is removed. Thus, the user may have control over whether information is collected about the user and how such information, if collected, may be used by the computing device and/or computing system.

A method is provided in accordance with claim <NUM>.

A computing device is provided in accordance with claim <NUM>.

In one example, the computing device includes a communication unit; a memory configured to store instructions associated with a download manager; and at least one processor configured to execute the instructions associated with the download manager.

A computer-readable storage medium is provided in accordance with claim <NUM>.

<FIG> is a conceptual diagram illustrating an example computing system configured to enable inter-device exchanges of applications resources required to execute application update cycles, in accordance with one or more aspects of the present disclosure. System <NUM> includes computing devices 110A through 110N (collectively referred to as "computing devices <NUM>") and remote computing system <NUM>. Each of computing devices <NUM> and remote computing system <NUM> may communicate over network 130A. Computing devices 110A and 110B may further communicate over network 130B and computing devices 110A and 110N may further communicate over network 130N.

Remote computing system <NUM> represents any suitable computing systems (e.g., desktop computers, laptop computers, mainframes, servers, blades, cloud computing systems, or other type of remote computing systems) capable of exchanging information via a network (such as network 130A), specifically, as part of an application market and application update service. Although shown as being a single computing system, remote computing system <NUM> may be a single, remote computing system or may include multiple remote computing systems.

Remote computing system <NUM> is configured to support, and provide computing devices <NUM> with access to, an application market or repository. That is, remote computing system <NUM> may enable access, via network 130A, to an application repository from which computing devices 110A through 110N can download applications or application updates. For example, remote computing system <NUM> may enable computing device 110A to download an application installation package from remote computing system <NUM> that computing device 110A then executes locally at computing device 110A to install a local copy of the application.

In some examples, remote computing system <NUM> is configured to initiate application update cycles at devices that access the application market or repository supported by remote computing system <NUM>. For example, remote computing system <NUM> may communicate with each of computing devices <NUM> to schedule a respective application update cycle at each of computing devices <NUM>.

Network 130A represents a reliable, inexpensive, high-bandwidth, network that satisfies connection requirements established by remote computing systems <NUM> for accessing the application repository of remote computing system <NUM>. For example, network 130A may be a public or private Wi-Fi® network that facilitates data transmissions between remote computing system <NUM> and computing devices <NUM>. Network 130A may include one or more network hubs, network switches, network routers, or any other network equipment, that are configured to establish wired or wireless communication links (e.g., Ethernet) between two of computing system <NUM> and computing devices <NUM> so as to enable the exchange of information between computing system <NUM> and computing devices <NUM>. Computing system <NUM> and computing devices <NUM> may exchange, i.e., transmit and receive, data across network 130A using any suitable communication techniques.

Each of computing devices <NUM> represents any suitable computing device (e.g., desktop computer, laptop computer, mobile device - including mobile phones and tablet computers, wearable device, or any other type of computing device) capable of exchanging information via network 130A to access the application repository supported by remote computing system 160A. That is, computing device 110A may be a mobile phone configured to download application packages from remote computing system <NUM>.

Each of computing devices <NUM> includes one or more respective application resources 122A through 122N (collectively referred to as "application resources <NUM>"). Each of application resources <NUM> represents one or more libraries, expansion packs (e.g., map packs, translation or language packs, additional game challenges, game levels, etc.), source files, executable packages, media content (e.g., audio or video files), other application information (e.g., news-related content, promotions, advertising information) or other software components that are generally user independent (i.e., not user specific) and used during local installation, execution, or update of one or more executable applications or computing services.

Each of computing devices <NUM> further includes a respective resource transfer (RT) module 120A through 120N (collectively "RT modules <NUM>") that is configured to maintain information about respective resources required for updating applications or other respective application resource needs of locally executing applications and negotiate transfers of application resources <NUM> between computing devices <NUM> to satisfy the respective application resource needs. For example, rather than establish a network connection with remote computing system <NUM> to obtain a particular update package that is required to update a particular application executing at computing device 110A, RT module 120A may negotiate with RT modules 120B through 120N to obtain the particular update package directly from one of computing devices 110B through 110N that previously obtained the update package (e.g., from remote computing system <NUM>). RT modules <NUM> may be implemented in hardware, software, firmware, or any combination thereof.

Each of RT modules <NUM> provides a registration scheme that enables applications executing at respective computing devices <NUM> to indicate, over time, resource needs for their respective update cycles. For example, RT module 120A may maintain a resource list that indicates the particular software components required by applications, executing at computing device 110A, to complete an application update. In some examples, the registration scheme further enables applications executing at respective computing devices <NUM> to indicate any existing application resources that are available for use by other applications executing at other computing devices <NUM> to perform their respective updates. For example, RT module 120B may maintain a resource list that indicates a particular software component, used by an application executing at computing device 110B to perform an update, is available for transfer to other computing devices <NUM> to enable other applications to perform an application update. In this way, the registration scheme enables each of RT modules <NUM> to keep track of the resource needs of the applications executing at respective computing devices <NUM> (and in some cases, the resources available to other computing devices <NUM> to satisfy their respective resource needs) so that two RT modules <NUM> can negotiate a transfer of resources between respective computing devices <NUM> to ultimately complete an update cycle without having to communicate with remote computing system <NUM>.

In operation, each of computing devices <NUM> initiates an update cycle of applications executing at computing devices <NUM>. For example, computing devices <NUM> may check for application updates at approximately, a same predetermined time. The predetermined time may be established: by remote computing device <NUM>, by a factory device during initial programming, following an operating system update, or communicated to computing devices <NUM> in some other way. In some examples, computing devices <NUM> may receive respective instructions from a remote system, such as remote computing system <NUM>, that causes computing devices <NUM> to initiate respective update cycles. Another way that computing devices <NUM> may determine the time to initiate an update cycle may be to have a "random", yet deterministic time each day. For example, if one of computing devices <NUM> is configured to initiate an update cycle a certain number of times each day (e.g., twice a day, twelve times a day, once an hour, or any other suitable interval), computing device may divide each day into one or more update intervals (i.e., the time between each update cycle). One of computing devices <NUM> may initiate an update cycle by randomly determining, using a seed derived from a start time of the update interval, a particular time in an update interval at which to initiate the update cycle. In some examples, one of computing devices <NUM> may impose blackout periods where no update cycles are permitted to occur during each update interface (e.g., at two minutes around each half hour to enable one of computing devices <NUM> to prevent the update cycles from interfering with any other operation that is scheduled to occur during the blackout periods. In any event, once an update cycle is initiated, RT modules <NUM> take-over the negotiation and exchange of application resources among computing devices <NUM> so as to complete their respective update cycles.

Computing device 110A may broadcast an indication that computing device 110A is initiating an update cycle of one or more applications executing at computing device 110A. For example, RT module 120A may implement a device discovery process to identify any computing devices <NUM> that are in-range for performing a device-to-device transfer of application resources required to complete an application update. The device discovery process may include establishment of a person area network (PAN), such as those configured in accordance with a Bluetooth® protocol or some other communication standard (e.g., Wi-Fi Direct®, ZigBee®, infrared, near field communication, and ultraband) for performing device discovery techniques. In other words, RT module 120A may cause computing device 110A to output information indicating that computing device 110A is ready to negotiate with any other computing devices <NUM> that are within range of computing device 110A and that are also performing an update cycle. RT module 120A may cause computing device 110A to establish, sequentially or in parallel, communication sessions with each one of computing devices 110B through 110N that responds to the broadcast.

With one of computing devices 110B through 110N that received the indication that computing device 110A is initiating the update cycle (where the "one of computing devices 110B-110N may be referred to as "the other device <NUM>"), computing device 110A may communicate information about at least one of: available resources of computing device 110A or resource needs of computing device 110A. For example, responsive to receiving an acknowledgement from RT module 120B that computing device 110B received the broadcast generated by RT module 120A, RT module 120A and RT module 120B may establish a first communication session, shown in <FIG> as network 130B, to share information about available resources and resource needs. Likewise, responsive to receiving an acknowledgement from RT module 120N that computing device 110N received the broadcast generated by RT module 120A, RT module 120A and RT module 120N may establish a second communication session, shown in <FIG> as network 130N, to share information about available resources and resource needs. At least part of networks 130B and 130N may be implemented as PANs, such as Bluetooth® connections or as some other type of network connection that enables device-to-device communication (e.g., Wi-Fi Direct®, ZigBee®, infrared, near field communication, wireless area networks - WANs, and ultraband).

Computing device 110A may negotiate a transfer of information with the other one of computing devices <NUM> so that at least one of the two devices <NUM>, i.e., computing device 110A and/or the other device <NUM>, may complete their respective update cycles. Such information may include at least some of the available resources of computing device 110A that are required to satisfy the respective resource needs of the other device <NUM>. In addition, or alternatively, the information may include at least some available resources of the other one of computing devices <NUM> to satisfy at least some of the resource needs of computing device 110A. For example, RT module 120A and RT module 120B may share their respective resource needs to determine whether any may be satisfied by a software component exchange. RT module 120A may provide RT module 120B with information about resources 122A and RT module 120A may receive from RT module 120B, information about resources 122B. RT modules 120A and 120B may compare their respective resource needs with the available resources of the other to determine whether to establish a resource transfer. Either following the negotiation, or while negotiating, with RT module 120B, RT module 120A and RT module 120N may likewise share their respective resource needs to determine whether any may be satisfied by a software component exchange.

Computing device 110A may establish a communication channel with the other one computing devices <NUM> for implementing the transfer. For example, by utilizing network 130B or by establishing a separate, dedicated communication channel with computing device 110B, RT module 120A and RT module 120B may implement an exchange of application resources so that either may complete its update cycle.

In some examples, the dedicated communication channel is implemented using a Wi-Fi® hotspot or other local area network protocol. In some cases, the dedicated communication channel is implemented over Bluetooth®, Wi-Fi Direct®, ZigBee®, infrared, near field communication, ultraband or some other type of network connection. For instance, computing device 110A and computing device 110N may exchange resources using the same network 130B that was used during the negotiation or using a different Bluetooth® connection. In other examples, the dedicated communication channel may be implemented as a local Wi-Fi® connection shared between two devices. For instance, computing device 110A may create a hotspot that computing device 110N can connect with to implement the transfer.

As one example, RT module 120B may create a channel by generating a Wi-Fi® hotspot as part of network 130B and provide RT module 120A with access to the channel. RT module 120B may then cause computing device 110B to send, via the dedicated channel, a copy of resource 122B which matches one of the resource needs registered to RT module 120A.

In any case, responsive to implementing the transfer over the dedicated communication channel, computing device 110A may complete execution of the update cycle of the one or more applications executing at computing device 110A. For example, after obtaining resource 122B from computing device 110B, RT module 120A may notify any application that registered the need for resource 122B that resource 122B is now available locally (e.g., on-device) for use to complete an update.

In this way, applications executing at a computing device are able to obtain application resources that are required to complete an update cycle, without necessarily ever having to communicate directly with a remote computing system that initially provides the required resources. Such a benefit is particularly advantageous for mobile phones that maintain cellular data connections (e.g., <NUM>, <NUM>, <NUM>, LTE, or other type of cellular data connection) but rarely or never connect to Wi-Fi®. Computing devices that perform the described inter-device resource transfers may ensure that applications executing on-device can and do remain up-to-date.

Accordingly, the techniques of this disclosure may improve the underlying operation of devices that perform application updates by enabling the devices to automatically pre-fetch resources required to perform an update, from a trusted device that is located nearby, instead of having to communicate with a remote server. By utilizing a channel with a nearby device, an example computing device may obtain required resources with less latency than if the device were to communicate (e.g., over the Internet) with a remote server. In addition, an example computing device may obtain required resources with more regularity as the device need not ever have to satisfy network requirements imposed by a remote server for downloading application updates. Instead, the resource transfers occur despite any network limitation of a recipient device itself. Furthermore, as monetary costs associated with cellular network usage may be a concern for users, the described techniques may offer significant monetary cost savings by enabling devices to obtain required application resources via local peer-to-peer networks established by nearby devices. In addition, besides monetary costs savings, the described techniques may provide electrical energy consumption savings over performing updates using a cellular connection or in other ways; for example, as cellular radios typically consume more power than Bluetooth®, Wi-FI® and some other types of radios, enabling devices to update application in ways that may avoid using a cellular connection may save battery and other energy consumption. By enabling devices to remain up-to-date with more regularity, the described techniques may ensure that locally executing applications are the most recently released versions, which may improve device security and functionality.

It should be understood that although the techniques are described throughout this disclosure as being applicable to completing "application update cycles" via inter-device transfers of application resources that are needed to complete the application update cycles, other use cases for performing inter-device transfers of application resources may exist. For example, a map application executing at an example computing device, such as computing device 110A, may determine that a location of the computing device is outside a geographical area supported by existing map packs of the map application. In response, the map application may register a requirement with an example resource transfer module, such as RT module 120A, for one or more map packs associated with the device location. When the computing device initiates an update cycle, the resource transfer module may negotiate with other computing devices to determine whether any are executing a corresponding map application that already has the required map packs. In accordance with the described techniques, the computing device may negotiate and implement a transfer with the other nearby devices to obtain copies of the required map packs.

Similar techniques to the above map application example may be performed by a computing device that executes a translation application in need of new language packs for a different location. For instance, an example computing device may negotiate and implement a transfer with other nearby devices to obtain copies of required language packs.

As yet another example, a media application executing at an example computing device, such as computing device 110A, may determine that certain media content (e.g., music, video, or other media content) is likely to be requested by a user of the computing device at some time in the near future. For instance, the media application may maintain information about a user's music preferences and in response to determining that a new album from a favorite artist indicated in the music preferences is available from a music service, and has not yet been downloaded to the device's locally-stored song library. In response, the media application may register a requirement with the resource transfer module for copies of the songs of the new album. When the computing device initiates an update cycle, the computing device may negotiate with other computing devices to determine whether any nearby devices have already obtained local copies of the songs. In accordance with the described techniques, the computing device may negotiate and implement a transfer with the other nearby devices to obtain copies of the requested songs.

Similar techniques to the above media application example may be performed by a computing device that executes other types of applications that are in need of new or updated resources. For instance, an example computing device may negotiate and implement a transfer with other nearby devices to obtain copies of news-related content that has been requested by a news application executing at the device. An example computing device may negotiate and implement a transfer with other nearby devices to obtain copies of promotional or advertising content that has been requested by an application executing at the device.

Throughout the disclosure, examples are described where a computing device and/or computing system may analyze information (e.g., application resource needs and the like) associated with the computing device only if the computing device and/or the computing system receives explicit permission from a user of the computing device to analyze the information. For example, in situations discussed below in which the computing device and/or computing system may collect information about available resources or resource needs of applications executing at the computing device, the user may be provided with an opportunity to provide input to control whether programs or features of the computing device (e.g., a download manager) can collect and make use of the information and may further be provided with an opportunity to control what the programs or features can or cannot do with the information. In addition, certain information may be pre-treated in one or more ways before it is transferred, stored, or otherwise used by a computing device and/or computing system, so that personally-identifiable information is removed. For example, before an example computing device transfers an available resource to a computing device in-need, the example computing device may pre-treat the available resource to ensure that any user identifying information embedded in the available resource is removed. Thus, the user may have control over whether information is collected about the user and how such information, if collected, may be used by the computing device and/or computing system. These are just a few example use cases for the described techniques; other use cases for performing inter-device transfers of application resources may exist.

<FIG> is a block diagram illustrating an example computing system configured to execute inter-device exchanges of applications resources required to execute application update cycles, in accordance with one or more aspects of the present disclosure. Computing device <NUM> of <FIG> is described below as an example of any one of computing devices 110A through 110N of <FIG>. <FIG> illustrates only one particular example of computing device <NUM>, and many other examples of computing device <NUM> may be used in other instances and may include a subset of the components included in computing device <NUM> or may include additional components not shown in <FIG>.

As shown in the example of <FIG>, computing device <NUM> includes: user interface component (UIC) <NUM>, one or more processors <NUM>, one or more communication units <NUM>, one or more input components <NUM>, one or more output components <NUM>, and one or more storage components <NUM>. UIC <NUM> includes display component <NUM> and presence-sensitive input component <NUM>. Storage components <NUM> of computing device <NUM> includes instructions and other data associated with: resource transfer (RT) module <NUM>, one or more application modules <NUM>, one or more communication modules <NUM>, and resources data store <NUM>.

Communication channels <NUM> may interconnect each of the components <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> for inter-component communications (physically, communicatively, and/or operatively). In some examples, communication channels <NUM> may include a system bus, a network connection, an inter-process communication data structure, or any other method for communicating data.

One or more communication units <NUM> of computing device <NUM> may communicate with external devices via one or more wired and/or wireless networks by transmitting and/or receiving network signals on the one or more networks. Examples of communication units <NUM> include a network interface chip (e.g. such as an Ethernet chip), an optical transceiver, a radio frequency transceiver, a GPS receiver, or any other type of device that can send and/or receive information. Other examples of communication units <NUM> may include short wave radios, cellular data radios (e.g., <NUM>, <NUM>, <NUM>, LTE), Bluetooth® radios, Wi-Fi® radios, other wireless network radios, as well as universal serial bus (USB), proprietary bus, or other bus type controllers.

One or more input components <NUM> of computing device <NUM> may receive input. Examples of input are tactile, audio, and video input. Input components <NUM> of computing device <NUM>, in one example, includes a presence-sensitive input device (e.g., a touch sensitive screen, a UID), mouse, keyboard, voice responsive system, video camera, microphone or any other type of device for detecting input from a human or machine. In some examples, input components <NUM> may include one or more sensor components one or more location sensors, one or more temperature sensors, one or more movement sensors (e.g., accelerometers, gyros), one or more pressure sensors (e.g., barometers), one or more ambient light sensors, and one or more other sensors (e.g., microphone, camera, infrared proximity sensor, hygrometer, and the like). Other sensors may include a heart rate sensor, magnetometer, glucose sensor, hygrometer sensor, olfactory sensor, compass sensor, step counter sensor, to name a few other non-limiting examples.

One or more output components <NUM> of computing device <NUM> may generate output. Examples of output are tactile, audio, and video output. Output components <NUM> of computing device <NUM>, in one example, includes a sound or audio processor, video or graphics processor, a speaker, a display, a vibration device, a liquid crystal display (LCD), a light emitting diode (LED) display, or any other type of device configured to generate output to a human or machine.

UIC <NUM> is configured to provide a user interface associated with computing device <NUM>. As such, UIC includes user input and user output functionality and may be implemented using various technologies. For instance, UIC <NUM> may function as an input device using presence-sensitive input screens, microphone technologies, infrared sensor technologies, or other input device technology for use in receiving user input. UIC <NUM> may function as an output device configured to present output to a user using any one or more display devices, speaker technologies, haptic feedback technologies, or other output device technology for use in outputting information to a user. As an input device, UIC <NUM> detects input (e.g., touch and non-touch input) from a user. Examples of user input include gestures performed by a user (e.g., the user touching, pointing, and/or swiping at or near one or more locations of UIC <NUM> with a finger or a stylus pen). As an output device, UIC <NUM> presents information (e.g., audible, visual, and/or haptic information) to a user in the form of audible, visual, or haptic feedback.

One or more processors <NUM> may implement functionality and/or execute instructions associated with computing device <NUM>. Examples of processors <NUM> include application processors, graphics processors, communications processors, application specific processors, display controllers, bus controllers, auxiliary processors, sensor hubs, and any other hardware configured to function as a processor, a processing unit, a processing component, or a processing device.

Software portions of modules <NUM>, <NUM>, and <NUM> may be operable by processors <NUM> to perform various actions, operations, or functions of computing device <NUM>. For example, processors <NUM> of computing device <NUM> may retrieve and execute instructions stored by storage components <NUM> that cause processors <NUM> to perform the operations attributed to modules <NUM>, <NUM>, and <NUM>. The instructions, when executed by processors <NUM>, may cause computing device <NUM> to access or store information, for example resources data store <NUM>, within storage components <NUM>.

One or more storage components <NUM> within computing device <NUM> may store information for processing during operation of computing device <NUM> (e.g., computing device <NUM> may store data accessed by or otherwise associated with modules <NUM>, <NUM>, and <NUM> during execution at computing device <NUM>). In some examples, storage component <NUM> is a temporary memory, meaning that a primary purpose of storage component <NUM> is not long-term storage. Storage components <NUM> on computing device <NUM> may be configured for short-term storage of information as volatile memory and therefore not retain stored contents if powered off. Examples of volatile memories include random access memories (RAM), dynamic random-access memories (DRAM), static random access memories (SRAM), and other forms of volatile memories known in the art.

Storage components <NUM>, in some examples, also include one or more computer-readable storage media. Storage components <NUM> in some examples include one or more non-transitory computer-readable storage mediums. Storage components <NUM> may be configured to store larger amounts of information than typically stored by volatile memory. Storage components <NUM> may further be configured for long-term storage of information as non-volatile memory space and retain information after power on/off cycles. Examples of non-volatile memories include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. Storage components <NUM> may store program instructions and/or information (e.g., data) associated modules <NUM>, <NUM>, and <NUM>. Storage components <NUM> may include a memory configured to store data or other information associated with modules <NUM>, <NUM>, and <NUM>.

Application modules <NUM> represent any application executing at computing device <NUM>. Examples of application modules <NUM> include: map or navigation software, media players, messenger clients, social media clients, calendars, email clients, games, electronic assistants, developer tools, utility software, or any other type of software executable that may run on a computing device. Computing device <NUM> may download at least some of application modules <NUM> from an application repository maintained by a remote computing system, such as remote computing system <NUM> of <FIG>. As is described in more detail below, at least some of application modules <NUM> may access resources data store <NUM>. Resources data store <NUM> may contain information that one or more of application modules <NUM> uses to perform a function, such as updating to a newer version of software.

Communication modules <NUM> work with communication units <NUM> to handle communications between computing device <NUM> and other computing devices. As one example, communication modules <NUM> may control a Bluetooth® radio of communication units <NUM>, for instance, to discover, on behalf of RT module <NUM>, whether any other nearby devices are initiating an application update cycle. As another example, communication modules <NUM> may control a Wi-Fi® radio of communication units <NUM>, for example, to establish, on behalf of RT module <NUM>, a communication channel for transferring application resources between computing device <NUM> and other nearby devices during an application update cycle.

RT module <NUM> is an example of RT modules <NUM> of <FIG>. For ease of description, RT module <NUM> is shown in <FIG> as having four primary functions: maintaining a resource list, providing a registration interface, negotiating for resources, and transferring resources. Although in other examples, RT module <NUM> may include additional or fewer primary functions.

RT module <NUM> maintains a resource list of any resources required by any of application modules <NUM>, e.g., to complete an update. While described as being "a list", the resource list maintained by RT module <NUM> may be implemented as any type of data structure that enables efficient access and modifications to a grouping of stated application resources and needs. In some examples, the resource list may indicate which one or more of application modules <NUM> requested a particular resource, as well as whether that particular resource has been obtained and stored at resources data store <NUM>. RT module <NUM> may update the resource list over time as resource availabilities and needs of computing device <NUM> change.

RT module <NUM> provides an application programming interface (API) from which one or more of application modules <NUM> can register available resources, as well as, resource needs. For example, RT module <NUM> may receive, via the registration API, information indicating that one of application modules <NUM> requires resource A, resource B, resource C, and resource D to complete an update. RT module <NUM> may update the resource list to indicate the need for resource A, resource B, resource C, and resource D. At a later time, as RT module <NUM> obtains required resources on the list, RT module <NUM> may update the resource list to indicate when resource A, resource B, resource C, and resource D becomes available. RT module <NUM> may return, via the API, an indication where each of resources A, B, C, and D is located (e.g., within resources data store <NUM>), thereby enabling the one of application modules <NUM> that registered with RT module <NUM> to complete its update.

RT module <NUM> negotiates with remote devices for the exchange of application resources to satisfy each other's application resource needs. For example, RT module <NUM> may command communication module <NUM> to initiate a Bluetooth® discovery process to identify any nearby remote devices that are initiating an update cycle concurrently with when computing device <NUM> initiates an update cycle. For example, RT module <NUM> may cause communication module <NUM> to broadcast, via a Bluetooth® radio from communication units <NUM>, a Bluetooth® wireless communication signal as part of the discovery process.

RT module <NUM> may communicate over Bluetooth® (or other short-range communication protocol) with each of the remote devices identified during the discovery process to determine whether computing device <NUM> can offer up any available resources from resources data store <NUM> in exchange for receiving at least some of the required resources that have been registered by one or more application modules <NUM>. For example, RT module <NUM> may negotiate with two or more remote devices to find a suitable combination of remote devices that can provide application resources A, B, and C, which are all indicated as being requested in the resource list of RT module <NUM>. RT module <NUM> may offer up resource D as being available for any remote device that is in need.

In some examples, RT module <NUM> predefines the protocol for transferring resources between computing device <NUM> and other remote devices. That is, RT module <NUM> may follow a specific set of requirements or instructions that have been previously established for RT module <NUM> and other remote devices, for every transfer of resources. Whereas, in some examples, part of the negotiation performed by RT module <NUM> (e.g., via the Bluetooth® connection) includes negotiating how to transfer resources between computing device <NUM> and the remote devices.

For example, RT module <NUM> may negotiate a protocol for the transfer, specifying, for example: how the resources are transferred (e.g., simultaneously - receiving each of A, B, and C while outputting D, sequentially - sending and receiving a single resource at a time, some at a time - receiving some of A, B, and C while or while not simultaneously outputting D, etc.), which party to the transfer will control the transfer (e.g., will the requesting applications exchange data directly, will RT module <NUM> be in charge of the transfer, will a remote device that is party to the transfer control the transfer), a data block size for the transfer, a transfer rate, and other characteristics of the transfer. In any case, as a result of the negotiations, RT module <NUM> determines what resources to transfer out, what resources to transfer in, as well as details about how the parties to the transfer have agreed to implement the transfer.

RT module <NUM> transfers application resources to and from remote devices to satisfy each other's application resource needs. That is, once RT module <NUM> determines which resources to transfer out to a remote device and which resources to receive from the remote device, RT module <NUM> may establish a communication channel between computing device <NUM> and the remote device that satisfies the requirements of the transfer that RT module <NUM> negotiated earlier. For example, the data stream may utilize a dedicated channel that is accessible via a Wi-Fi® hotspot generated by computing device <NUM> and offered up to the remote device(s) that will be part of a resource transfer. In some examples, the dedicated communication channel is established as a data stream that exists directly between the requesting applications so the two or more requesting applications control how (e.g., simultaneously, sequentially, one at a time, multiple at a time, etc.) the resources are transferred over the data stream. In other examples, RT module <NUM> together with or independent of a corresponding RT module that executes at the remote device, controls how the resources are transferred over the data stream.

<FIG> is a conceptual diagram illustrating an example inter-device network configured to enable inter-device exchanges of applications resources required to execute application update cycles, in accordance with one or more aspects of the present disclosure. System <NUM> of <FIG> is described below as an example of system <NUM> of <FIG>. Although <FIG> illustrates only one particular example of system <NUM>, and many other examples of system <NUM> may be used in other instances and may include a subset of the components included in system <NUM> or may include additional components not shown in <FIG>.

System <NUM> includes computing devices 310A, 310B, and 310C (collectively referred to as "computing devices <NUM>"). Each of computing devices <NUM> is an example of computing device <NUM> or any of computing devices <NUM> and as such, each includes a respective resource transfer (RT) module 320A, 320B, or 320C (collectively referred to as "RT modules <NUM>") and a respective resource data store 322A, 322B, or 322C (collectively referred to as "resources <NUM>").

Each of RT modules <NUM> maintains a respective resource list 314A, 314B, or 314C (collectively "resource lists <NUM>"). That is, one or more respective applications executing at each of computing devices <NUM> may register one or more application resource needs with a respective one of RT modules <NUM>. Each of RT modules <NUM> may update the respective one of resource lists <NUM> as respective resource needs and availability change.

In the example of <FIG>, one or more applications executing at computing device 310A have indicated to RT module 320A of a need for resources A, B, and C. RT module 320A may have previously obtained resource D. Therefore, RT module 320A may maintain resource list 314A as shown in <FIG>, to indicate a need for resources A, B, and C, and an availability of resource D. In other words, RT module 310A may determine a respective resource need one or more applications executing at computing device 310A and by pooling together all the respective resource needs of the one or more applications executing at the computing device, RT module 320A may determine the sum total resource needs of computing device 310A. That is, RT module 320A may remove redundant resource needs or redundant available resources that have been registered by applications executing at computing device 310A to determine a consolidated list of all the available and required resources of computing device 310A.

With regards to computing devices 310B and 310C, one or more respective applications executing at computing devices 310B and 310C may have previously registered their resource needs and RT modules 320B and 320C may be tracking respective available resources. Accordingly, RT module 320B may maintain resource list 314B as shown in <FIG>, to indicate a need for resource C, and an availability of resources A, B, and D. RT module 320C may maintain resource list 314C as shown in <FIG>, to indicate a need for resources A, B, and D, and an availability of resource C.

In operation, each of computing devices <NUM> may initiate an update cycle of one or more respective applications at a scheduled or an approximately same predetermined time. Each of computing devices <NUM> may broadcast a respective indication that the computing device <NUM> is initiating an update cycle of one or more applications executing at the computing device <NUM>.

In response to outputting an indication that computing device 310A is initiating an update cycle, computing device 310A may communicate with each of computing devices 310B and 310C over, respectively, communication links 332A and 332B. Likewise, computing devices 310B and 310C may communicate via link 332C in further response to either one of computing devices 310B and 310C initiating a respective update cycle. Each of communication links 332A, 332B, and 332C (collectively referred to as "links <NUM>") may comprise a Bluetooth® communication session or other short-range communication session that is suited for exchanging information between two of computing devices <NUM> to exchange information during negotiation of a resource transfer.

Via links <NUM>, computing devices <NUM> may share the respective resource needs and availability of each device <NUM>. For instance, RT module 320A may inform, over link 332A, RT module 320B about available resources or resource needs indicated in resource list 314A, and vice versa. RT module 320A may inform, over link 332B, RT module 320C about available resources or resource needs indicated in resource list 314A, and vice versa. RT module 320B may inform, over link 332C, RT module 320B about available resources or resource needs indicated in resource list 314A, and vice versa.

While communicating over link 332B with RT module 320C of computing device 310C, RT module 320A may determine whether any applications executing at computing device 310A have a respective available resource that satisfies at least one of the resource needs indicated in resource list 314C. In the example of <FIG>, RT module 320A may determine that resource D is an available resource that satisfies at least one resource need of computing device 310C. RT module 320A may further determine that RT module 320C can provide resource C to RT module 320A to satisfy a resource need of computing device 310A.

While communicating over link 332A with RT module 320B of computing device 310B, RT module 320A may determine whether any applications executing at computing device 310A have a respective available resource that satisfies at least one of the resource needs indicated in resource list 314B. In the example of <FIG>, RT module 320A may determine that computing device 310A is unable to satisfy any resource needs of computing device 310B. However, RT module 320A may determine that resources A and B are available from computing device 310B to satisfy at least one resource need of computing device 310A.

Lastly from communicating with RT module 320C over link 332C, RT module 320B may determine whether any applications executing at computing device 310B have a respective available resource that satisfies at least one of the resource needs indicated in resource list 314C. Likewise, RT module 320C may determine whether any applications executing at computing device 310C have a respective available resource that satisfies at least one of the resource needs indicated in resource list 314B. In the example of <FIG>, RT module 320B may determine that resource C is an available resource from computing device 310C which satisfies at least one resource need of computing device 310B. RT module 320C may determine that resources A and B are available resources from computing device 310B to satisfy at least one resource need of computing device 310C.

Following negotiations between RT modules <NUM>, each of computing devices <NUM> may establish a respective dedicated communication channel for implementing a respective transfer of resources. For example, in response to negotiating with RT module 320B, RT module 320A may cause computing device 310A to generate Wi-Fi® hotspot 330A and grant computing device 310B access to hotspot 330A so that computing device 310A may receive resources A and B from computing device 310B. RT module 320A may communicate with RT module 320B to cause one or more applications executing at computing device 310A to obtain required resources A and B.

Concurrent with, prior to, or after the transfer of resources from computing device 310B to computing device 310A, RT module 320A may cause computing device 310A grant computing device 310C access to hotspot 330A so that computing device 310A may receive resource C from computing device 310C. RT module 320A may communicate with RT module 320C to cause one or more applications executing at computing device 310A to obtain required resource C. As a result of obtaining required resources A, B, and C, RT module 320A may have satisfied all resource needs of applications executing at computing device 310A such that computing device 310A may complete execution of the update cycle of computing device 310A.

In a similar vein, in response to negotiating with RT module 320B, RT module 320C may cause computing device 310C to generate Wi-Fi® hotspot 330C and grant computing device 310B access to hotspot 330C so that computing device 310C may receive resources A and B from computing device 310B. RT module 320C may communicate with RT module 320B to cause one or more applications executing at computing device 310C to obtain, via hotspot 330C, required resources A and B.

Concurrent with, prior to, or after the transfer of resources from computing device 310B to computing device 310C, RT module 320C may cause computing device 310C grant computing device 310A access to hotspot 330C so that computing device 310C may receive resource D from computing device 310A. RT module 320C may communicate with RT module 320A to cause one or more applications executing at computing device 310C to obtain required resource D. As a result of obtaining required resources A, B, and D, RT module 320C may have satisfied all resource needs of applications executing at computing device 310C such that computing device 310C may complete execution of the update cycle of computing device 310C.

In response to negotiating with RT module 320C, RT module 320B may cause computing device 310B to generate Wi-Fi® hotspot 330B and grant computing device 310C access to hotspot 330B so that computing device 310C may receive resource C from computing device 310B. RT module 320B may communicate with RT module 320C to cause one or more applications executing at computing device 310B to obtain, via hotspot 330B, required resource C. As a result of obtaining required resource C, RT module 320B may have satisfied all resource needs of applications executing at computing device 310B such that computing device 310B may complete execution of the update cycle of computing device 310B.

By automatically utilizing nearby crowds of devices to distribute application resources and application content through direct, device-to-device transfers, the described techniques may reduce dependency by those computing devices on large-scale data networks or connections to application repositories. In this way, computing devices, such as computing devices <NUM>, are more likely to execute updated and secure applications, automatically, and without necessarily having to obtain explicit user input.

In some examples, the described techniques may be used to share application resources to a particular "closed group" of computing devices and/or to devices at a particular context (e.g., time, date, location, temperature, etc.) that are considered to be part of a "closed group" while at the particular location. Consider an example where a host computing device may be configured to cause application resources to be transferred to the devices in response to the other devices being in a particular location or after having previously registered with a respective RT module a need for application resources from the host device.

For instance, a host device located in an airport that is associated with an airline may wish to distribute a certain set of application resources when passengers' mobile devices are in proximity of a gate terminal or other location monitored by the host device. The host may enable the passengers' mobile devices to pre-register with their respective RT modules a future need for application resources from the host device (e.g., in response to using an airline application to purchase an airline ticket or check-in for a flight). For example, an airline application executing at a mobile device may pre-register with a respective RT module executing at the mobile device to configure the mobile device to obtain application resources required by the airline application to improve the user experience when a passenger interacts with the airline application, before or during the flight. The application resources may include airport maps, airline magazines, videos, games, pictures, other in-flight entertainment, food and beverage menus, or other information. In this way, the airline or other host device may ensure that a closed group of devices obtains the application resources required for a particular scenario. The above airline example is just one example of a "closed-group" application resource distribution example, other examples exist.

<FIG> is a flowchart illustrating operations performed by a computing device configured to execute inter-device exchanges of applications resources required to execute application update cycles, in accordance with one or more aspects of the present disclosure. Operations <NUM>-<NUM> are performed by a computing device, such as any of computing devices <NUM>, <NUM>, and <NUM>, and may be performed in an order different than that shown in <FIG>. For ease of description, <FIG> is described in the context of computing device <NUM> of <FIG>.

As shown in <FIG>, in operation, computing device <NUM> may obtain user consent for RT module <NUM> to communicate with other devices to obtain resources for completing application update cycles (<NUM>). For example, to preserve user privacy and ensure that a user maintains control of their data, RT module <NUM> may cause UIC <NUM> to present a user interface from which a user of computing device <NUM> can decide whether to provide consent for inter-device transfers of application resources. Via the user interface, the user may provide explicit inputs to either opt-in to, or opt-out of, inter-device transfers of application resources. Without explicit user consent, RT module <NUM> refrains from negotiating with other devices to obtain resources to satisfy update cycles.

After obtaining user consent (<NUM>), computing device <NUM> broadcasts an indication that an update cycle of one or more applications is being initiated (<NUM>). For example, at a random, predetermined, or scheduled time, RT module <NUM> may engage with communication module <NUM> to identify any nearby devices that have or need application resources.

Computing device <NUM> may determine one or more remote devices that received the broadcasted indication and want to negotiate a transfer of resources (<NUM>). For example, because of the broadcast during operation <NUM>, RT module <NUM> may determine a list of one or more remote devices that are available and willing to negotiate.

Computing device <NUM> communicates, with the one or more remote devices that received the indication that computing device <NUM> is initiating the update cycle, information about resource needs of computing device <NUM> (<NUM>) and optionally information about available resources of computing device <NUM>. For example, RT module <NUM> may share the list of registered resource needs and available resources with each of the remote devices identified in list of remote devices that RT module <NUM> generated during operation <NUM>. In return, RT module <NUM> may receive a list of registered resource needs and available resources from each of the remote devices. RT module <NUM> may identify any matches between available resources of computing device <NUM> and resource needs of the remote devices, as well as any matches between available resources of the remote devices and resource needs of computing device <NUM>. The communicating of resource needs and availability between computing device <NUM> and one or more remote devices may be done using a short-range communication protocol, such as Bluetooth®, which may be the same or different than the protocol used to broadcast the indication.

Computing device <NUM> negotiates a transfer of resources between a remote device to satisfy resource needs of the computing device <NUM> (<NUM>) and optionally resource needs of the remote device. For example, based on the matches, RT module <NUM> and the remote devices may negotiate and perform a transfer of resources. RT module <NUM> may perform negotiations and transfers of resources with a single remote device at a time. Alternatively, RT module <NUM> may perform negotiations and transfers of resources with multiple remote devices, simultaneously. For example, computing device <NUM> may perform operations <NUM>-<NUM> for a single remote device at a time or may perform operations <NUM>-<NUM> to negotiate and transfer resources with multiple remote devices simultaneously. The negotiations may be done using a short-range communication protocol, such as Bluetooth®, which may be the same or different than the protocol used to broadcast the indication.

To speed up a subsequent transfer of resources that are available from multiple remote devices, RT module <NUM> may negotiate a partial transfer of a particular available resource with two or more of the multiple remote devices. In other words, if RT module <NUM> requires resource A, and resource A is available from a first remote device and also from a second remote device, RT module <NUM> may negotiate a transfer of part of resource A from the first remote device and may further negotiate a transfer of any remaining parts of resource A from the second remote device. RT module <NUM> may cause the partial transfers of available resources to occur simultaneously to obtain all of the available resource quicker; or RT module <NUM> may cause the partial transfers of available resources to occur sequentially to reduce complexity.

Computing device <NUM> establishes a communication channel for implementing the transfer (<NUM>). For example, RT module <NUM> may cause computing device <NUM> to establish a local Wi-Fi® hotspot to facilitate one or more dedicated communication channels that are required to implement one or more transfers. RT module <NUM> may share a single hotspot with multiple remote devices. That is, RT module <NUM> may create a dedicated communication channel to stream resources between computing device <NUM> and a first remote device using a Wi-Fi® hotspot; and RT module <NUM> may create additional communication channels to stream resources between computing device <NUM> and other remote devices using the same Wi-Fi® hotspot. Wi-Fi® communication channels are just one example of a dedicated communication channel for implementing a transfer of resources. Other types of communication channels may be used in other instances.

Operation <NUM> is shown in <FIG> as an optional step in the transfer process of <FIG>. In some cases not the subject of the claims, two computing devices may implement a transfer of application resources over the same communication channel that was used to negotiate the transfer. In other words, RT module <NUM> of computing device <NUM> may transfer resources with remote devices using the same Bluetooth® or other such connection used during operation <NUM> to negotiate the transfer.

In some examples, a computing device that sends application resources during a transfer with another device may establish a communication channel for implementing the transfer. However in other examples, a computing device that receives application resources during a transfer with another device may likewise establish a communication channel for implementing the transfer. In other words, establishing the communication channel for a transfer of application resources may not be dependent on which device (if not both) is sending resources or receiving resources, during the transfer. Either device in a transfer may establish a communication channel for implementing the transfer.

Computing device <NUM> implements the transfer (<NUM>). For example, RT module <NUM> may cause computing device <NUM> to send, to a remote device, via the dedicated communication channel, the at least some of the available resources of computing device <NUM> to satisfy the resource needs of the remote device. In addition, RT module <NUM> may cause computing device <NUM> to receive, from the remote device via the dedicated communication channel, the at least some available resources of the remote device to computing device <NUM> to satisfy at least some of the resource needs of computing device <NUM>. For example, during the above negotiations between RT module <NUM> and a corresponding RT module executing at a remote device, RT module <NUM> may establish a transfer plan that includes computing device <NUM> sending available resource D to the remote device in exchange for required resource A. RT module <NUM> may cause computing device <NUM> to stream resource D to the remote device while also causing computing device <NUM> to stream resource A from the remote device. In some cases, the actual transfer of resources between two devices occurs between the requesting applications executing at the two devices. For instance, one or more of application modules <NUM> that registered the need for resource A may communicate directly with an application executing at the remote device that possesses resource A to implement the transfer. Similarly, one of application modules <NUM> that possesses resource D may communicate directly with an application executing at the remote device that needs resource D, in order to implement the transfer.

In any event, responsive to implementing one or more transfers of resources over the dedicated communication channel, computing device <NUM> completes execution of the update cycle of the one or more applications executing at the computing device (<NUM>). For example, following a transfer, RT module <NUM> may provide any of application modules <NUM> that registered for a resource, with access to resource once made available following the transfer.

With access to a newly available resource, a particular application from application modules <NUM> may perform an update of itself, using the newly available resource. That is, the particular application may update, using a resource received from a remote device, from a first version of the particular application to a second version of the particular application.

Accordingly, the particular application may obtain required resources to perform its update without relying on computing device <NUM> to ever have to satisfy network requirements imposed by a remote server for downloading application updates. By enabling applications to remain up-to-date with more regularity, the described techniques may ensure that locally executing applications are the most recently released versions, which may improve device security and functionality.

By way of example, and not limitation, such computer-readable storage media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other storage medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. It should be understood, however, that computer-readable storage mediums and media and data storage media do not include connections, carrier waves, signals, or other transient media, but are instead directed to non-transient, tangible storage media. Combinations of the above should also be included within the scope of computer-readable medium.

In addition, in some examples, the functionality described herein may be provided within dedicated hardware and/or software modules.

Claim 1:
A method comprising:
broadcasting (<NUM>), by a computing device (110A, 310A) and via a personal area network protocol, an indication that the computing device is initiating an update cycle of one or more applications executing at the computing device, wherein an update cycle of an application requires one or more application resources;
communicating (<NUM>), by the computing device and via the personal area network protocol, with one or more remote devices (110B ... 110N, 310B, 310C) identified as being within range of the computing device and that received the indication that the computing device is initiating the update cycle, information about application resources required by the computing device;
negotiating (<NUM>), by the computing device and via the personal area network protocol, with each of the one or more remote devices, a transfer of:
at least some available application resources (<NUM>) of each of the one or more remote devices to the computing device to satisfy at least some of the application resources required by the computing device;
establishing (<NUM>), by the computing device, with each of the one or more remote devices, one or more respective communication channels for implementing the transfer; and
responsive to implementing (<NUM>) the transfer over the one or more respective communication channels, completing (<NUM>), by the computing device, execution of the update cycle of the one or more applications executing at the computing device.