Patent Description:
A large number of applications and supplemental software programs used by users of computing devices are offered and available for deployment from multiple deployment sources. For example, many supplemental software programs (e.g., add-ins) are offered by multiple application stores. In an example, some supplemental software programs are available on both consumer application stores and enterprise application stores.

Although the applications offered by the different sources may be the same, because of the difference in source, the applications are often considered different by current computing systems. As a result, the same application may be deployed from multiple sources in one device, leading to both user confusion and unnecessary use of computing resources (e.g., storage, processing, and bandwidth resources).

Furthermore, some enterprises require their users to utilize specific deployment sources. For example, certain enterprises may require the use of a centralized deployment source. For such enterprises, when a consumer tries to use their personal device in the enterprise setting or attempts to utilize their enterprise device outside of the enterprise setting, the user may be forced to deploy an application they previously used from a different source. This may require the user to reinstall the application and may lead to loss of existing settings and data.

Hence, there is a need for systems and methods of efficiently and seamlessly transitioning between different deployment sources.

Reference is made to <CIT> which discloses a method for searching for an application stored in an integrated application store with a single search. The method involves receiving a search word from a user, generating a query word based on the received search word, and providing an integrated result of searching a plurality of application stores for an application corresponding to the query word.

In one general aspect, the instant disclosure describes a device having a processor and a memory in communication with the processor wherein the memory stores executable instructions that, when executed by the processor, cause the device to perform multiple functions. The functions include determining if an application is available for deployment to the device from a plurality of deployment sources, upon determining that the application is available for deployment from the plurality of deployment sources, identifying one of the plurality of deployment sources as a preferred deployment source for deploying the application, deploying the application from the preferred deployment source to the device, determining if a copy of the application available on the device was deployed from the preferred deployment source, and upon determining that the copy of the application available on the device was not deployed from the preferred deployment source, removing or ignoring the copy available on the device, wherein deploying the application includes at least one of installing the application, loading one or more icons representing the application on a user interface screen, and activating the application.

In yet another general aspect, the instant disclosure describes a method for deploying an application from a deployment source to a device. The method includes determining if the application is available for deployment to the device from a plurality of deployment sources, upon determining that the application is available for deployment from the plurality of deployment sources, identifying one of the plurality of deployment sources as a preferred deployment source for deploying the application, deploying the application from the preferred deployment source to the device, determining if a copy of the application available on the device was deployed from the preferred deployment source, and upon determining that the copy of the application available on the device was not deployed from the preferred deployment source, removing the copy available on the device, wherein deploying the application includes at least one of installing the application, loading one or more icons representing the application on a user interface screen, and activating the application.

In a further general aspect, the instant disclosure describes a computer program that, when executed, causes a programmable device to determine if an application is available for deployment to the device from a plurality of deployment sources, upon determining that the application is available for deployment from the plurality of deployment sources, identify one of the plurality of deployment sources as a preferred deployment source for deploying the application, deploy the application from the preferred deployment source to the device, determine if a copy of the application available on the device was deployed from the preferred deployment source, and upon determining that the copy of the application available on the device was not deployed from the preferred deployment source, remove the copy available on the device, wherein deploying the application includes at least one of installing the application, loading one or more icons representing the application on a user interface screen, and activating the application.

In the following detailed description, numerous specific details are set forth by way of examples in order to provide a thorough understanding of the relevant teachings. It will be apparent to persons of ordinary skill, upon reading this description, that various aspects can be practiced without such details. In other instances, well known methods, procedures, components, and/or circuitry have been described at a relatively high-level, without detail, in order to avoid unnecessarily obscuring aspects of the present teachings.

Applications and supplemental software programs offered by different deployment sources are often considered distinct from each other, even if they are the exact same application and/or supplemental software program. This is because applications are often identified by an application ID plus a deployment source ID. As a result, an application offered by multiple application stores may be loaded to a computing device from two different application stores and the two copies of the application may be treated as distinct applications. This may lead to having duplicate applications on one device and as such user confusion.

Furthermore, when certain restrictions are imposed on use of deployment sources, the users may have to transition from one deployment source to another. Because the same application offered by a different deployment source may be considered a different application, the user may have to reinstall some of their applications, reenter existing settings and/or save existing data. This often occurs in enterprise settings when the enterprise requires the users to transition from use of consumer application stores (e.g., Microsoft® Store) to enterprise application stores (e.g., Centralized deployment). It may also occur when the user attempts to use their personal device in the enterprise setting or vice versa. Furthermore, problems may surface when sharing documents that include supplemental software programs (e.g., Microsoft® add-ins) installed from a deployment source that is not available to the user with whom the document is shared. In such situations, currently installed applications and/or supplemental software programs (e.g., Microsoft® add-ins) may need to be reinstalled to function properly. This is not only time-consuming, but also leads to inefficient use of computing resources such as memory, processing, and bandwidth. As such, there exists a technical problem of providing efficient and seamless access to applications offered from multiple deployment sources.

To address these technical problems and more, in an example, this description provides a technical solution for deploying an application and/or supplemental software programs offered from multiple deployment sources from a preferred deployment source. To do so, techniques are used to determine at runtime if an application is available from multiple available deployment sources, and upon determining that the application is offered by multiple deployment sources, identify a preferred deployment source for deploying the application from based on one or more predetermined rules and/or parameters. Furthermore, techniques may be employed to transition between different deployment sources of an application, when needed, in a manner that makes the deployment source seamless to the end user. As a result, even if the deployment source changes from an application, the user will not notice a difference. Furthermore, this eliminates the potential for multiple deployments of the same application, and as such reduces duplicated programs on the user's device. This significantly enhances the process of transitioning from one deployment source to another.

As will be understood by persons of skill in the art upon reading this disclosure, benefits and advantages provided by such implementations can include, but are not limited to, a technical solution to the technical problem of inefficient, confusing and resource intensive deployment of applications offered from multiple deployment sources. The technical solutions may enable seamless transition between different deployment sources without the need to reinstall and/or reenter settings and/or data into an application offered by multiple deployment sources. Furthermore, the technical solutions provide a mechanism for decreasing the possibility of having duplicated applications on a device, thus reducing use of memory and processing resources and as such improving the operation of computing devices. This reduces user confusion and inefficiency thus resulting in improved customer satisfaction. The benefits provided by these technology-based solutions yield more user-friendly mechanisms for providing access to applications offered by multiple deployment sources and for enabling enterprises to provide an efficient and smooth transition to use of enterprise deployment sources.

As used herein, the term "application" may refer to any software program that is available for retrieval from a deployment source and/or installation on a computing device. As such, the term "application" may include stand-alone software programs as well as supplemental software programs that work with and/or expand the capabilities of other software programs (e.g., Microsoft® add-ins). Furthermore, as used herein, "deployment source" may refer to any source from which an application may be deployed and may include reference to application stores.

<FIG> illustrates an example system <NUM>, upon which aspects of this disclosure may be implemented. The system <NUM> may include a plurality of deployment servers such as deployment servers <NUM> and <NUM>. Each of the deployment servers may include a distinct deployment source such as the deployment source <NUM> of deployment server <NUM> and the deployment source <NUM> of deployment server <NUM>. Each of the servers <NUM> and <NUM> may operate as a shared resource server accessible by various computer client devices such as client device <NUM>. The servers may also operate as a cloud-based server for deployment services. Although shown as one server, each of the servers <NUM> and <NUM> may represent multiple servers for performing various different operations.

The deployment sources <NUM> and <NUM> may operate as distinct deployment sources for deployment of various applications. In an example, the deployment sources <NUM> and <NUM> may operate as application stores (e.g., third party application stores, consumer application stores or centralized deployment application stores) to which a user <NUM> has access via the client device <NUM>. As such, each deployment source <NUM> and <NUM> include mechanisms for enabling a user to browse through or search for different applications, selecting a desired application and deploying the selected application to their devices. In some implementations, each deployment source <NUM> and <NUM> may provide access to a store catalog containing a list of applications available for installation from each deployment source. Deployment may include retrieval of executable code for installation of the selected application or loading of a selected supplemental software program to the client device <NUM> for use with an existing application. The deployment process also includes loading one or more icons representing the application or add-in on user interface screens (e.g., on a ribbon, as a shortcut, and the like), and activating the application or add-in.

To enable retrieval of the selected application, the deployment sources <NUM> and <NUM> may be in communication with (e.g., via a network <NUM>) or may include a storage server <NUM> containing a data store <NUM>. The data store <NUM> may function as a repository in which one or more data sets containing application data (e.g., application information and/or code) for applications available via the deployment sources <NUM> and/or <NUM> are stored. In one implementation, application data for some of the applications may be stored and/or provided via other sources (e.g., storage servers associated with providers of the applications). It should be noted that although only one storage server is shown, a plurality of storage servers may be utilized. For example, each of the store deployment sources <NUM> and <NUM> may be associated with and use distinct storage servers.

The client device <NUM> may be connected to the deployment servers <NUM> and <NUM> via the network <NUM>. The network <NUM> may be a wired or wireless network(s) or a combination of wired and wireless networks that connect one or more elements of the system <NUM>. The client device <NUM> may be a personal or handheld computing device having or being connected to input/output elements that enable the user <NUM> to interact with content such as different applications and/or deployment sources. Examples of suitable client devices <NUM> include, but are not limited to, personal computers, desktop computers, laptop computers, mobile telephones; smart phones; tablets; phablets; smart watches; wearable computers; gaming devices/computers; televisions; head-mounted display devices and the like. The internal hardware structure of a client device is discussed in greater detail in regard to <FIG> and <FIG>.

The client device <NUM> may include an operating system <NUM> and a deployment engine <NUM>. The operating system <NUM> may include one or more computer programs executed on the client device <NUM> that process, manage, and enable operation of one or more applications such as the application <NUM>. In an example, the operating system <NUM> may be a Microsoft Windows® operating system. Among other features, the graphical operating system <NUM> may configure the client device <NUM> to be responsive to user input. User input may include input received via an input element such as a keyboard or a pointing device (e.g., a mouse) that enables the user <NUM> to interactively access different applications, select different deployment sources, and/or choose application(s) provided by a deployment source for deployment. For example, the user may utilize a pointing device to move a pointer over an icon on the screen to invoke display of an application store. The client device <NUM> may then communicate with the deployment source (e.g., deployment server <NUM> or <NUM>) associated with the application store to enable display of and provide access to applications offered for deployment via the selected application store.

Once an application such as application <NUM> has been selected and deployed to the client device <NUM>, the application may be used and operated on the client device <NUM> until a transition to a different deployment source may become necessary. For example, if the application <NUM> was deployed from the deployment source <NUM> and new restrictions placed on the device <NUM> require the device <NUM> to primarily utilize the deployment source <NUM>, a transition to the new deployment source may be needed. In an example, this may occur, when an enterprise begins using an enterprise preferred deployment source and requires its users to switch to the preferred deployment source. The transition may also be needed when a user tries to user their personal device on which one or more applications have been deployed to an enterprise setting requiring the exclusive use of a preferred deployment source.

In such situations, the operating system <NUM> may operate alongside a deployment engine <NUM> to enable a seamless transition between the two distinct deployment sources. To achieve this, the deployment engine determines if an application being loaded or accessed is available via multiple deployment sources and if so whether there is a preferred deployment source associated with the client device <NUM>. When it is determined that multiple deployment sources exist for the application and the existing application (e.g., application <NUM>) was deployed from the preferred deployment source, the deployment engine <NUM> operates with the operating system <NUM> to communicate with the preferred deployment source to retrieve the application from the preferred source and remove or ignore the old version of the application. The deployment engine may perform this process such that existing settings and/or data used with the current application remain the same after deployment from the preferred deployment source. For example, when a document containing a supplemental software program (e.g., add-in) which was acquired from a consumer deployment source is opened, and restrictions on the client device give preference to the enterprise deployment source, the document will automatically transition to utilizing the same supplemental software program but one deployed from the enterprise deployment source, while persevering all existing consent and other settings. In another example, when a user who utilizes supplemental software programs installed via the consumer deployment source is notified that their enterprise is disabling access to the consumer deployment source and moving to a centralized deployment source, the user can continue using their current applications without any interruptions or noticeable changes. In this manner, the user <NUM> may not be required to perform any additional actions for using a desired application, thus making the transition seamless and unnoticeable to the user <NUM>.

When application <NUM> is offered by both deployment sources <NUM> and <NUM>, it may be possible for the user <NUM> to install two distinct copies of the application on the client device <NUM>. To prevent user confusion and conserve computing resources, the deployment engine <NUM> determines when multiple copies of the same application are available on the client device <NUM>, as described below with regards to <FIG>, and remove and/or ignore all but one of the copies. This may be performed in a manner such that all existing settings and data are preserved such that the user <NUM> is not required to perform additional tasks for utilizing the application.

<FIG> is a flow diagram depicting an exemplary method <NUM> for deployment of applications offered by multiple deployment sources. In an example, one or more steps of method <NUM> may be performed by an operating system (e.g., operating system <NUM> of <FIG>), a deployment engine (e.g., deployment engine <NUM> of <FIG>) and/or a deployment server (e.g., deployment server <NUM> or <NUM> of <FIG>).

At <NUM>, method <NUM> may begin by receiving an indication for loading an application on a client device. The indication may be received when a user invokes a user interface element for initiating an application or when a document associated with an application is opened. In an example, this occurs when a document which includes features enabled by a supplemental software program is opened. In some implementations, one or more steps of method <NUM> may be performed upon initialization and/or refreshing of an applications list (e.g., refreshing of add-in list). In such implementations and/or after a new application is downloaded and a list of entitlements is created or updated, method <NUM> may examine each of the entitlements for the provider and check to see if duplicates exist. In an implementation where preference is given to a deployment source (e.g., enterprise deployment source) and the preferred deployment source is refreshed after initialization of the non-preferred deployment source, the non-preferred deployment source may need to be refreshed as well so that its internal list of applications can be updated based on what the preferred deployment source has. In some implementations, these steps are performed by calling a RefreshExtensionList function.

When it is determined that an application (or supplemental software program) is being loaded on a client device, method <NUM> proceeds to determine if more than one copy of the same application is available on the client device, at <NUM>. This may be performed by searching for the application ID to determine if another application having the same application ID as the invoked application exists on the client device. In some implementations, applications are identified by a combination of their application ID and a designation identifying the deployment source from which they were deployed. The combination of application ID and the designation identifying the deployment source may be referred to as an asset ID. In these implementations, to determine if multiple copies of the same application exist on the device, only the application ID may be examined.

When it is determined that multiple copies of the application are available on the client device (or a copy that is different from the copy invoked is available on the client device), method <NUM> proceeds to determine if the client device is associated with a preferred deployment source, at <NUM>. For example, method <NUM> may determine if the device is associated with an enterprise indicating a preference for a specific deployment source (e.g., enterprise deployment source). This may be achieved by examining a setting associated with the client device.

Alternatively, this may be determined by examining a number of parameters to determine if the client device should be associated with a preferred deployment source. For example, a determination may made as to whether the client device is associated with a consumer or an enterprise client device and based on this information, determine which deployment source is the preferred deployment source for the client device. In another example, it may be determined if a user account associated with one of the deployment sources exist and if so, select that deployment source as the preferred deployment source. Other mechanisms for identifying the preferred deployment source may also be utilized.

When it is determined that the client device is associated with a preferred source (yes at <NUM>), method <NUM> proceeds to remove and/or ignore the copy of the application that was deployed from the non-preferred deployment source, at <NUM>. If it is determined, however, that the client device is not associated with a preferred deployment source and/or a preferred deployment source can be assigned to the client device (no at <NUM>), method <NUM> may proceed to remove one of the application copies from the client device, at <NUM>. Removing a copy of the application may involve removing data associated with the extra copy from the client device. The data may include executable code, user interface elements associated with the additional copies, and any other information or data relating to the additional copy. While removing the additional copy, care may be taken to ensure documents associated with the removed application have access to the remaining copy of the application such that all existing documents and applications continue to function in the same manner as before. Ignoring a copy of the application may involve designating that copy as a non-preferred copy and removing user interface elements associated with the copy from user interface screens.

In implementations where the enterprise deployment source is the preferred deployment source, ensuring that multiple copies of an application do not exist on the same device may be achieved by invoking the consumer deployment source to determine if there is an equivalent application in the enterprise deployment source and if so, not adding the application to its list of entitlements for the user. In some implementations, when preference is given to one type of deployment source, but access is still available to other deployment sources, the user may be able to install applications from the non-preferred deployment sources and those applications may be kept on the user's device but not be projected (e.g., icons representing them are not displayed). This implementation may be advantageous when the user has different user profiles and each profile has a different preferred deployment source (e.g., personal user profile vs. work user profile). For example, when the user logs into the different user profile, access to the non-preferred sourced application may be granted.

When it is determined, at step <NUM>, that multiple copies of the invoked application do not exist on the client device (no at <NUM>), method <NUM> may proceed to determine if the invoked application is offered from multiple deployment sources accessible to the client device, at <NUM>. This may involve determining which deployment sources are available and/or accessible to the client device and/or user of the client device (e.g., by examining user accounts associated with the deployment sources) and accessing those deployment sources to determine if the invoked application is offered by more than one of the available deployment sources. In some implementations, this process simply involves examining the source of the invoked application and determining if the application is available from a different source accessible to the user. The process of determining if the application is offered from multiple sources may include examining many parameters associated with the application. This may require accessing metadata (e.g., from a manifest file) associated with the application and may involve initializing the deployment source from which the application is provided and/or loading the manifest associated with the application in memory.

In some implementations, this process involves calling a function referred to as GetManifestFromBetterProvider that provides for switching the application to one provided from a preferred source if it exists, before performing any other operations. In some implementations, the function is invoked by an extension manager (e.g., Office Extension Manager). This may involve examining an application and looking for one from a different provider. The process may provide two ways in which an answer may be returned: (<NUM>) caller provides a callback; and (<NUM>) caller passes in a reference it expects to be populated with the answer. In some implementations, for applications that are provided by the consumer deployment source, the consumer deployment source is initialized and then the enterprise deployment source is checked to see if the application is available from the enterprise deployment source.

In situations where the invoked application is determined to be offered by more than deployment source (yes at <NUM>), method <NUM> may proceed to identify the preferred deployment source for the client device and/or the invoked application, at <NUM>. In an example, this may involve determining if the invoked application was provided from a consumer deployment source, determining if the client device is associated with an enterprise and if so, selecting the enterprise deployment source as the preferred source. For a device associated with an enterprise, the process may involve determining if the application is available from an enterprise deployment source, and if not, selecting the consumer deployment source as the preferred source.

Once the preferred deployment source has been identified, method <NUM> may proceed to determine, if the invoked application was provided by the preferred deployment source, at <NUM>. This may include examining the manifest and/or an asset ID associated with the invoked application to identify its deployment source. When it is determined that the identified deployment source is the preferred deployment source (yes at <NUM>), method <NUM> may proceed to execute the application, at <NUM>. Similarly, when it is determined, at <NUM>, that the invoked application is not offered by multiple sources (no at <NUM>), method <NUM> may proceed to execute the invoked application in a normal manner, at <NUM>.

When, it is determined, however, that the source providing the invoked application is not the preferred source (no at <NUM>), method <NUM> proceeds to deploy the application from the preferred deployment source, at <NUM>, before moving to remove and/or ignore the previous copy of the application, at <NUM>. The process of removing and/or ignoring the previous copy may include removing user interface elements (e.g., icons in the ribbon) associated with the previous copy of the application. Similarly, the process of deploying the application may include creating user interface elements associated with the newly deployed application to replace the user interface elements associated with the previous copy. Similar operations may be performed to correct shortcut resources associated with the invoked application, as needed. In some implementations, removing and/or ignoring the application simply entails removing the application from the list of applications provided by the provider and does not include removing the application from the user's list of entitlements (e.g., list of applications to which they are entitled). In this manner, if a user obtained an application as a personal user, they may still be able to use it when logged into their personal profile.

In some implementations, to ensure enterprise sources are given preference, after a consumer deployment source completes downloading and creating a list of entitlements (e.g., applications), each of the entitlements is examined to determine if an equivalent application exists in the enterprise deployment source and if so, remove the application from the device and download it from the enterprise deployment source.

Furthermore, in some implementations, an application may be provided with different functionalities depending on the deployment source. For example, when the user is associated with multiple profiles (e.g., personal profile and work profile), a second copy of an application may be installed for one of the profiles (e.g., work profile) using a deployment source associated with the profile (e.g., enterprise deployment source). The second copy may be deployed such that no data from the existing application is migrated into the second copy. This may be utilized in situations where the user brings their own device for use at work, and it may be undesirable to have an enterprise administrator inadvertently take over the user's personal data. However, in a situation, where the device belongs to the enterprise and the application is an internal line-of-business application that stores local data, the transition from one deployment source to another may be made seamlessly. For example, duplicated user interface elements (e.g., icons) may be eliminated, while existing user interface elements are retained in the same folders, and existing local settings are maintained.

Mechanisms disclosed herein may be applied to provide a seamless transition between production and early versions (e.g., beta version) of an application on the same device (e.g., where the beta version is offered by a different deployment source) and/or a seamless transition between different versions of applications that are offered for different subsidiaries of an enterprise (e.g., different deployment sources in different geographical regions).

In this manner, an architecture is provided which enables deployment of applications from preferred providers and facilitates for loading of the application correctly from the preferred provider such that the deployment source is seamless to the end user. This provides an improved user experience when more than one deployment source from which an application may be deployed is available. Furthermore, the mechanisms provided herein facilitate removal of duplicated entries on the user device, leading to reduced user confusion and increased customer satisfaction. The architecture may function on client devices that have access to multiple deployment sources and thus allows an identical application to be installed from multiple deployment sources. At runtime, the architecture may select the preferred deployment source to run the application from based on a set of defined rules and/or parameters. This results in a mechanism where to the end user, it may appear as if only one copy of the application is installed.

<FIG> is a block diagram <NUM> illustrating an example software architecture <NUM>, various portions of which may be used in conjunction with various hardware architectures herein described, which may implement any of the above-described features. <FIG> is a non-limiting example of a software architecture and it will be appreciated that many other architectures may be implemented to facilitate the functionality described herein. The software architecture <NUM> may execute on hardware such as client devices, native application provider, web servers, server clusters, external services, and other servers. A representative hardware layer <NUM> includes a processing unit <NUM> and associated executable instructions <NUM>. The executable instructions <NUM> represent executable instructions of the software architecture <NUM>, including implementation of the methods, modules and so forth described herein.

The hardware layer <NUM> also includes a memory/storage <NUM>, which also includes the executable instructions <NUM> and accompanying data. The hardware layer <NUM> may also include other hardware modules <NUM>. Instructions <NUM> held by processing unit <NUM> may be portions of instructions <NUM> held by the memory/storage <NUM>.

The frameworks <NUM> (also sometimes referred to as middleware) provide a higher-level common infrastructure that may be used by the applications <NUM> and/or other software modules. For example, the frameworks <NUM> may provide various GUI functions, high-level resource management, or high-level location services. The frameworks <NUM> may provide a broad spectrum of other APIs for applications <NUM> and/or other software modules.

The applications <NUM> include built-in applications <NUM> and/or third-party applications <NUM>. Examples of built-in applications <NUM> may include, but are not limited to, a contacts application, a browser application, a location application, a media application, a messaging application, and/or a game application. Third-party applications <NUM> may include any applications developed by an entity other than the vendor of the particular system. The applications <NUM> may use functions available via OS <NUM>, libraries <NUM>, frameworks <NUM>, and presentation layer <NUM> to create user interfaces to interact with users.

Some software architectures use virtual machines, as illustrated by a virtual machine <NUM>. The virtual machine <NUM> provides an execution environment where applications/modules can execute as if they were executing on a hardware machine (such as the machine <NUM> of <FIG>, for example). The virtual machine <NUM> may be hosted by a host OS (for example, OS <NUM>) or hypervisor, and may have a virtual machine monitor <NUM> which manages operation of the virtual machine <NUM> and interoperation with the host operating system. A software architecture, which may be different from software architecture <NUM> outside of the virtual machine, executes within the virtual machine <NUM> such as an OS <NUM>, libraries <NUM>, frameworks <NUM>, applications <NUM>, and/or a presentation layer <NUM>.

<FIG> is a block diagram illustrating components of an example machine <NUM> configured to read instructions from a machine-readable medium (for example, a machine-readable storage medium) and perform any of the features described herein. The example machine <NUM> is in a form of a computer system, within which instructions <NUM> (for example, in the form of software components) for causing the machine <NUM> to perform any of the features described herein may be executed. As such, the instructions <NUM> may be used to implement methods or components described herein. The instructions <NUM> cause unprogrammed and/or unconfigured machine <NUM> to operate as a particular machine configured to carry out the described features. The machine <NUM> may be configured to operate as a standalone device or may be coupled (for example, networked) to other machines. In a networked deployment, the machine <NUM> may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a node in a peer-to-peer or distributed network environment. Machine <NUM> may be embodied as, for example, a server computer, a client computer, a personal computer (PC), a tablet computer, a laptop computer, a netbook, a set-top box (STB), a gaming and/or entertainment system, a smart phone, a mobile device, a wearable device (for example, a smart watch), and an Internet of Things (IoT) device. Further, although only a single machine <NUM> is illustrated, the term "machine" includes a collection of machines that individually or jointly execute the instructions <NUM>.

The machine <NUM> may include processors <NUM>, memory <NUM>, and I/O components <NUM>, which may be communicatively coupled via, for example, a bus <NUM>. The bus <NUM> may include multiple buses coupling various elements of machine <NUM> via various bus technologies and protocols. In an example, the processors <NUM> (including, for example, a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), an ASIC, or a suitable combination thereof) may include one or more processors 412a to 412n that may execute the instructions <NUM> and process data. In some examples, one or more processors <NUM> may execute instructions provided or identified by one or more other processors <NUM>. The term "processor" includes a multi-core processor including cores that may execute instructions contemporaneously. Although <FIG> shows multiple processors, the machine <NUM> may include a single processor with a single core, a single processor with multiple cores (for example, a multi-core processor), multiple processors each with a single core, multiple processors each with multiple cores, or any combination thereof. In some examples, the machine <NUM> may include multiple processors distributed among multiple machines.

As used herein, "machine-readable medium" refers to a device able to temporarily or permanently store instructions and data that cause machine <NUM> to operate in a specific fashion. The term "machine-readable medium," as used herein, does not encompass transitory electrical or electromagnetic signals per se (such as on a carrier wave propagating through a medium); the term "machine-readable medium" may therefore be considered tangible and non-transitory. Non-limiting examples of a non-transitory, tangible machine-readable medium may include, but are not limited to, nonvolatile memory (such as flash memory or read-only memory (ROM)), volatile memory (such as a static random-access memory (RAM) or a dynamic RAM), buffer memory, cache memory, optical storage media, magnetic storage media and devices, network-accessible or cloud storage, other types of storage, and/or any suitable combination thereof. The term "machine-readable medium" applies to a single medium, or combination of multiple media, used to store instructions (for example, instructions <NUM>) for execution by a machine <NUM> such that the instructions, when executed by one or more processors <NUM> of the machine <NUM>, cause the machine <NUM> to perform and one or more of the features described herein. Accordingly, a "machine-readable medium" may refer to a single storage device, as well as "cloud-based" storage systems or storage networks that include multiple storage apparatus or devices.

The I/O components <NUM> may include a wide variety of hardware components adapted to receive input, provide output, produce output, transmit information, exchange information, capture measurements, and so on. The specific I/O components <NUM> included in a particular machine will depend on the type and/or function of the machine. For example, mobile devices such as mobile phones may include a touch input device, whereas a headless server or IoT device may not include such a touch input device. The particular examples of I/O components illustrated in <FIG> are in no way limiting, and other types of components may be included in machine <NUM>. The grouping of I/O components <NUM> are merely for simplifying this discussion, and the grouping is in no way limiting. In various examples, the I/O components <NUM> may include user output components <NUM> and user input components <NUM>. User output components <NUM> may include, for example, display components for displaying information (for example, a liquid crystal display (LCD) or a projector), acoustic components (for example, speakers), haptic components (for example, a vibratory motor or force-feedback device), and/or other signal generators. User input components <NUM> may include, for example, alphanumeric input components (for example, a keyboard or a touch screen), pointing components (for example, a mouse device, a touchpad, or another pointing instrument), and/or tactile input components (for example, a physical button or a touch screen that provides location and/or force of touches or touch gestures) configured for receiving various user inputs, such as user commands and/or selections.

In some examples, the I/O components <NUM> may include biometric components <NUM>, motion components <NUM>, environmental components <NUM> and/or position components <NUM>, among a wide array of other environmental sensor components. The biometric components <NUM> may include, for example, components to detect body expressions (for example, facial expressions, vocal expressions, hand or body gestures, or eye tracking), measure biosignals (for example, heart rate or brain waves), and identify a person (for example, via voice-, retina-, and/or facial-based identification). The position components <NUM> may include, for example, location sensors (for example, a Global Position System (GPS) receiver), altitude sensors (for example, an air pressure sensor from which altitude may be derived), and/or orientation sensors (for example, magnetometers). The motion components <NUM> may include, for example, motion sensors such as acceleration and rotation sensors. The environmental components <NUM> may include, for example, illumination sensors, acoustic sensors and/or temperature sensors.

In some examples, the communication components <NUM> may detect identifiers or include components adapted to detect identifiers. For example, the communication components <NUM> may include Radio Frequency Identification (RFID) tag readers, NFC detectors, optical sensors (for example, one- or multi-dimensional bar codes, or other optical codes), and/or acoustic detectors (for example, microphones to identify tagged audio signals). In some examples, location information may be determined based on information from the communication components <NUM>, such as, but not limited to, geo-location via Internet Protocol (IP) address, location via Wi-Fi, cellular, NFC, Bluetooth, or other wireless station identification and/or signal triangulation.

While various embodiments have been described, the description is intended to be exemplary, rather than limiting, and it is understood that many more embodiments and implementations are possible that are within the scope of the embodiments. Although many possible combinations of features are shown in the accompanying figures and discussed in this detailed description, many other combinations of the disclosed features are possible. Any feature of any embodiment may be used in combination with or substituted for any other feature or element in any other embodiment unless specifically restricted. Therefore, it will be understood that any of the features shown and/or discussed in the present disclosure may be implemented together in any suitable combination. Also, various modifications and changes may be made within the scope of the attached claims.

Generally, functions described herein (for example, the features illustrated in <FIG>) can be implemented using software, firmware, hardware (for example, fixed logic, finite state machines, and/or other circuits), or a combination of these implementations. In the case of a software implementation, program code performs specified tasks when executed on a processor (for example, a CPU or CPUs). The program code can be stored in one or more machine-readable memory devices. The features of the techniques described herein are system-independent, meaning that the techniques may be implemented on a variety of computing systems having a variety of processors. For example, implementations may include an entity (for example, software) that causes hardware to perform operations, e.g., processors functional blocks, and so on. For example, a hardware device may include a machine-readable medium that may be configured to maintain instructions that cause the hardware device, including an operating system executed thereon and associated hardware, to perform operations. Thus, the instructions may function to configure an operating system and associated hardware to perform the operations and thereby configure or otherwise adapt a hardware device to perform functions described above. The instructions may be provided by the machine-readable medium through a variety of different configurations to hardware elements that execute the instructions.

While the foregoing has described what are considered to be the best mode and/or other examples, it is understood that various modifications may be made therein and that the subject matter disclosed herein may be implemented in various forms and examples, and that the teachings may be applied in numerous applications, only some of which have been described herein. It is intended by the following claims to claim any and all applications, modifications and variations that fall within the true scope of the present teachings.

The scope of protection is limited solely by the claims that now follow. That scope is intended and should be interpreted to be as broad as is consistent with the ordinary meaning of the language that is used in the claims.

It will be understood that the terms and expressions used herein have the ordinary meaning as is accorded to such terms and expressions with respect to their corresponding respective areas of inquiry and study except where specific meanings have otherwise been set forth herein.

Relational terms such as first and second and the like may be used solely to distinguish one entity or action from another without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms "comprises," "comprising," and any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element preceded by "a" or "an" does not, without further constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises the element.

Claim 1:
A device (<NUM>) comprising:
a processor (<NUM>); and
a memory (<NUM>) in communication with the processor (<NUM>), the memory (<NUM>) comprising executable instructions (<NUM>) that, when executed by the processor (<NUM>), cause the device (<NUM>) to perform functions of:
determining if an application (<NUM>) is available for deployment to the device (<NUM>) from a plurality of deployment sources (<NUM>, <NUM>);
upon determining that the application (<NUM>) is available for deployment from the plurality of deployment sources (<NUM>, <NUM>), identifying one of the plurality of deployment sources (<NUM>, <NUM>) as a preferred deployment source (<NUM>, <NUM>) for deploying the application (<NUM>);
deploying the application (<NUM>) from the preferred deployment source (<NUM>, <NUM>) to the device (<NUM>);
determining if a copy of the application (<NUM>) available on the device (<NUM>) was deployed from the preferred deployment source (<NUM>, <NUM>); and
upon determining that the copy of the application (<NUM>) available on the device (<NUM>) was not deployed from the preferred deployment source (<NUM>, <NUM>), removing or ignoring the copy available on the device (<NUM>);
wherein deploying the application (<NUM>) includes at least one of: installing the application (<NUM>); loading one or more icons representing the application (<NUM>) on a user interface screen; and activating the application.