WO2014096937A1 - Systems and methods for building a centralized app store - Google Patents

Abstract

The invention relates to an application market place server node for pushing an application to a plurality of running environments associated to one or more electronic devices and registered to a user, each running environment being further associated to an operating system (OS), the application being available in a plurality of versions, each version corresponding to at least a different OS, the application market place server comprising a processor operable to receive selection of an application from a user, retrieve the running environments registered to the user, and their associated OS, for each registered running environment, retrieve the application version corresponding to the OS, and push the retrieved application version to the each registered running environment.

Description

SYSTEMS AN D METHODS FOR BU I LDING A CENTRALIZED APP STORE

FIELD OF TH E PRESENT INVENTION:

The present invention generally relates to applications running on an electronic device and more specifically to the recommendation of such applications.

BACKGROU N D OF TH E PRESENT I NVENTION:

With the success of an application market place like the Apple AppStore™, it is anticipated that Operators and Handset manufacturer will come up with application market places of their own. Application market places - app store or app platform in short - provide an opportunity to reach users more directly than the more traditional approach consisting in populating an electronic device with a ready to use set of applications.

There are today different appstores in the market such as Apple Appstore,

Google Android Play Store (previously Android Market), Amazon Marketplace, RIM BlackBerry App World, Microsoft Windows Phone marketplace, Nokia Symbian Store, etc. Now there are new players such as Tizen, Mozilla Boo†-†o-Gecko and others. All those appstores have their own application platform and landscape that usually are tied to their own device.

There are also different types of applications - app in short - including mobile native apps, web apps (including mobile web) , browser extensions, desktop native apps, TV native apps, and more. All these applications will run on their own application platform. Each application may vary in different versions in terms of execution environment, associated OS, hardware and allocated resources, etc.

With the current worldwide explosion of mobile and web app versions currently underway, a need has emerged for developing cross-platform environments. HMTL5 now appears as the foundation for such development. The vision is simple: one single, straightforward web programming language that allows the creation of anything from a basic service app to a complex game that works across any platform - be it a PC, phone, or tablet - without the need for native development. Furthermore, many app developers also use technology like PhoneGap, Sencha or custom wrapper that allow building applications in HTML5 and use native code where necessary to deploy across different proprietary appstores.

The need for cross platform environment is further increased with the emergence of visualizations and multiple devices associated to a user. It is common now for a same user to owe one or more smartphones, a tablet and a personal computer. His different electronic devices may not even run the same operating systems (OS) . Furthermore, in order to solve part of the multiple devices, a same device now can run different running environments through visualization. Indeed, an electronic device may run a plurality of virtual machines, each corresponding to an instance or running environment. In such implementation, an instance manager like a hypervisor is provided for accessing or switching back and forth between these available instances.

As software development working across OS is yet to be reached, there is still a need today to simplify the user's experience when it comes to getting a new application. Indeed, provided a user has for instance an Android™ tablet, and an Iphone™, he will still have to look for the application in the Google Play Store, and in the Apple AppStore™, provided it is available in both market place.

There is still a need today to address the app needs of a user with multiple devices. There is a further need for a solution that enables a user to easily install a same application for his multiple execution environments.

SUMMARY OF TH E PRESENT METHOD AN D SYSTEM:

It is an objective of the present method and system to overcome disadvantages and/or make improvements in the prior art.

To that extend, the present method relates to a method for pushing an application to a plurality of running environments associated to one or more electronic devices and registered to a user, each running environment being further associated to an operating system (OS), the application being available in a plurality of versions, each version corresponding to at least a different OS, the method comprising:

- receiving selection of an application from a user,

- retrieving the running environments registered to the user, and their associated OS, - for each registered running environment, retrieving the application version corresponding to the OS, and,

- pushing the retrieved application version to the each registered running environment.

Thanks to the present method, applications are presented as version or OS free to the user. The different versions of a same application may be seen as a collection of app versions, the collection being transparent to the user. When selecting an application, which can be seen as a subscription to an app, the different versions will be automatically pushed to the registered running environments of the user, which no further user intervention. The user no longer needs to get one by one the app version matching every single one of his running environments.

The present system also related to an application market place server node for pushing an application to a plurality of running environments associated to one or more electronic devices and registered to a user, each running environment being further associated to an operating system (OS), the application being available in a plurality of versions, each version corresponding to at least a different OS, the application market place server comprising a processor operable to:

- receive selection of an application from a user,

- retrieve the running environments registered to the user, and their associated OS,

- for each registered running environment, retrieve the application version corresponding to the OS, and;

- push the retrieved application version to the each registered running environment.

The present system also relates to a telecommunication system comprising:

- an application market place server node for pushing an application to a plurality of running environments associated to one or more electronic devices and registered to a user, each running environment being further associated to an operating system (OS), the application being available in a plurality of versions, each version corresponding to at least a different OS, - a first electronic device comprising at least a first running environment associated to a first OS, both first running environment and OS being registered with the application market place server,

the application market place server comprising a processor operable to: - receive selection of an application from a user,

- retrieve the at least first running environments registered to the user, and its associated first OS,

- retrieve the application version corresponding to the first OS, and;

- push the retrieved application version to the first running environment. The present system also relates to a non transitory computer readable carrier including computer program instructions that cause a computer to implement a method for pushing an application to a plurality of running environments associated to one or more electronic devices and registered to a user, each running environment being further associated to an operating system (OS) , the application being available in a plurality of versions, each version corresponding to at least a different OS, the computer readable carrier comprising instructions for:

- receiving selection of an application from a user,

- retrieving the running environments registered to the user, and their associated OS,

- for each registered running environment, retrieving the application version corresponding to the OS, and,

- pushing the retrieved application version to the each registered running environment.

B RIEF D ESCRIPTIO N OF TH E DRAWINGS:

The present system and method are explained in further detail, and by way of example, with reference to the accom panying drawings wherein:

F IG. 1 A shows an exem plary em bodiment of the present system,

F IG. 1 B shows an exemplary embodiment of an appstore manager in the present system,

F IGs. 2A and 2B show exemplary embodiments of electronic devices in the present system, FIG. 3 shows an exemplary flowchart for indexing application across different app stores according to an embodiment of the present method, and;

FIG. 4 shows an exemplary flowchart according to an embodiment of the present method.

DETAI LED DESCRI PTION OF TH E PREFERRED EMBODIMENTS:

The following are descriptions of exemplary embodiments that when taken in conjunction with the drawings will demonstrate the above noted features and advantages, and introduce further ones.

In the following description, for purposes of explanation rather than limitation, specific details are set forth such as architecture, interfaces, techniques, etc., for illustration. However, it will be apparent to those of ordinary skill in the art that other embodiments that depart from these details would still be understood to be within the scope of the appended claims.

Moreover, for the purpose of clarity, detailed descriptions of well-known devices, systems, and methods are omitted so as not to obscure the description of the present system. Furthermore, routers, servers, nodes, base stations, gateways or other entities in a telecommunication network are not detailed as their implementation is beyond the scope of the present system and method.

For purposes of simplifying a description of the present system, the terms

"operatively coupled", "coupled", and formatives thereof as utilized herein refer to a connection between devices and/or portions thereof that enables operation in accordance with the present system. For example, an operative coupling may include one or more of a wired connection and/or a wireless connection between two or more devices that enables a one and/or two-way communication path between the devices and/or portions thereof. In another example, an operative coupling may include a wired and/or wireless coupling to enable communication between an application market server, the convergent appstore server (CAS) of the present system and one or more user devices.

U nless specified otherwise, the exemplary embodiment here after will be described in its application to a mobile device operable to select and download via a telecommunication network applications from one or more application market places, also referred to here after as an app store or platform. The mobile device will also be referred to as a user or electronic device. An application market client hosted by said mobile device may be used to facilitate the selection and download of applications.

The present exemplary embodiment is in no way a limitation of the scope of the present method and system as the present teachings could be implemented for other electronic or telecommunication devices, such as computers, laptops, PDAs (Personal Digital Assitants) , pads (like the iPad™ from Apple) , set top box and the likes. More generally any electronic device having connection means for accessing distant application market servers over a telecommunication network and downloading applications therefrom may benefit form the present teachings.

The expressions application or application program (AP) in the present description may be taken in a very general sense, and may be seen as any tool that functions and is operated by means of a computer, with the purpose of performing one or more functions or tasks for a user or another application program. To interact with and control an AP, a graphical user interface (GUI) of the AP may be displayed on the mobile device display.

In addition, it should be expressly understood that the drawings are included for illustrative purposes and do not represent the scope of the present system.

FIG. 1 shows an illustration of an exemplary embodiment of the present system. A convergent appstore server CAS 100, convergent appstore in short, is illustrated along with a plurality of known appstores 121 , 122 and 123 and a plurality of electronic devices 101 , 102 and 103 registered to the same user. Each one of the electronic devices 101 to 103 may be running a single running or execution environment or a plurality of them through e.g. virtualization.

In existing solutions, a first electronic device 101 , illustrated as mentioned before as a mobile device, may access through a telecommunication network (not shown on FIG. 1 ) a first application market place - or app store - hosted by an application market server 121 . The Apple AppStore™ is a known example of such an application market place. Such a server 121 may store a large number of applications that can be downloaded to the first mobile device 101 over the telecommunication network using a proprietary application market client, likei Tunes™. Applications may also be pushed using innovative ways of notifications such as Apple Push Notification Service (APNS) , Google Cloud Messaging (GCM) , and BlackBerry Push Service. Such notification technologies allow to send efficiently real-time information/data to a user device.

Subsequently to its download, the user may invoke and execute the application added to his device 101 . Today a large number of such applications are available and can perform tasks varying from games, location based services, call services, news, social network interfaces to music and video players and the likes.

A one on one relationship exists today between an electronic device 1 01 and its associated appstore 1 21 , linked to the OS available on the device 101 . For instance, an electronic device 102, illustrated as a mobile device, may access through another telecommunication network (same or different than the previous one, and not shown on FIG. 1 ) a second app store hosted by an application market server 122. Provided the second mobile device 102 operates with a different OS, the second appstore will be different than the first one, even if both devices are registered to the same user.

Provided the user wants the application APP 1 for his first mobile device 1 01 , he will acquire it from the first appstore 1 21 . If interested in adding the same application to his second mobile device 102, he will have to search the second appstore 122 for an application presenting the same characteristics as APP 1 .

The present CAS 1 00 will simplify the user's experience. Indeed, the goal of the convergent appstore 100 is to allow a user to browse and acquire applications regardless of their formats and associated appstore. This is achieved thanks to a single centralized appstore (one-stop store) , where similar apps are aggregated and regrouped from external appstores and sources 121 to 1 23. Once an app is selected or subscribed to by a user, the right versions of the app will be pushed to the targeted user registered devices, so as to give the user a unified experience without worrying about what execution environment, e.g. OS, is available on his different devices 101 to 103. The determination and distribution process of the applications of the present method are handled by the CAS 100 as described here after.

In order to offer an executing environment transparent experience to a user, the CAS will present different modules as follows:

- an account manager module AMM 140 for registering a user with the CAS 100 so that the user can benefit from the present centralized appstore. To that effect, the AMM 140 will allocate a user identifier, manage different users and their associated user' s profile, subscribed apps, registered devices and associated execution environments,

- a device manager module DMM 142 for managing a repository of pre-defined device characteristics such as Galaxy Nexus, Apple iPad, etc.

Today applications even within a same appstore, can come in different versions depending on the electronic device. For instance, APP1 may present different versions depending on whether the user has a smartphone or a tablet,

- an execution environment manager module EEMM 144, for managing repository of pre-defined execution environments such as virtual machines, for later mapping purpose,

- an application and appstore manager module AAMM 146 for registering the different existing appstores, for mapping the same application across the registered appstores. Further details will be provided in relation with

FIG. I B and FIG. 3,

- an application finder module AFM 148 handling the app vs execution environment vs device mapping process when a CAS app has been subscribed or selected by a user,

- a distribution and notification controller module DNCM 1 50 that will distribute the app and its different relevant versions via notification mechanisms associated with the registered electronic devices & corresponding execution environments, and;

- CAS APIs (application program interface) 152 for external systems such as the electronic devices 101 to 103 and a local CAS client to communicate with the CAS 100 to either select an application or receive notification of the application selected by the CAS.

The user' s experience when subscribing to an application, i.e. selecting an application through the CAS 100, will be described later on in relation to FIG. 4. The applications presented to the user thanks to the CAS 100 may be seen OS free apps. An OS free app can be described as a pointer to a collection of all different versions of a same (or similar) app available across execution environments, i.e. appstores. In order to consolidate and aggregate different appstores so as to group all similar apps in a collection behind that app pointer presented to the user, the AAMM 146 comprises itself different modules illustrated in FIG. 1 B and described as follows:

- appstore registration module 1460, to register an appstore with the CAS, allowing the CAS access to the different appstores own APIs,

- application crawlers 1462 for discovering and collecting for all applications from the registered appstore servers 121 , 122 and 124 application metadata describing them. The application crawlers may use the app stores APIs to gather such metadata,

- a cross platform classification module CPCM 1464 that uses the application metadata collected by the application crawlers 1462 to index, i.e. link, the applications across app stores. Thanks to the CPCM 1464, one or more applications from the first app store 121 can be linked to one or more applications from the second app store, e.g. using a similarity criterion. Similarly, one or more applications from the second app store 122 can be linked to one or more applications from the third app store 123 using the same or another similarity criterion. As mentioned before, each application performs one or more functions. The similarity criterion may measure the similarities between functions thanks to the metadata collected by the application crawlers. The metadata may consist for instance of the application description, including its name, as available in most app stores. The similarity criterion, using a semantic tool to interpret application descriptions, may comprise the comparison of the application descriptions between apps from the registered app stores. Thus the New York Times app available on the Apple App Store™ may be found similar to the application of the same name available on the Android Store™ and Microsoft™ Store, even if some of their respective functions are not fully identical. Other technologies, based on NPL (natural processing language) may be used to interpret the application metadata across application stores and find similarities among application functions from each store. The indexing, i.e. the grouping of similar apps into a collection, may be stored in a CAS database 125 operatively linked to the AAMM 146. A collection of apps can be seen as all the applications linked through the previous indexing across registered appstores. It is associated to an application that will be referred to here after as an "OS free app" . The collection/pointer may be further associated to metadata for instance common across appstores, like an app name (e.g. New York Times) and metadata corresponding to a synthesis of the different metadata across registered appstores. Such "consolidated metadata" for the OS free app - without any information that is appstore specific - may be presented to the user through a CAS portal accessible from any of the user' s registered devices and executing environments, or even a different electronic device, using a CAS portal.

One may note that illustrating the CAS 100 as a seven module server or the AAMM 146 as a three module server is a mere illustration highlighting the different functionalities of these servers. This is in no way limiting as the different modules may be one of the same software or hosted on different elements of the CAS 100. For instance the crawlers 1462 may be hosted on different nodes of the present telecommunication network and may vary depending on the application market place being discovered.

FIGs. 2A and 2B are illustrations of exemplary embodiments of the user - or electronic - devices used in the present system. The electronic devices of FIGs. 2 correspond to the mobile devices 101 to 103 in FIG. 1 A. A first embodiment of an electronic device in the present system is illustrated as a mobile device 201 in FIG. 2A. The illustration is functional and the hardware elements of the mobile device 201 are not shown. The mobile device 201 may comprise a display for presenting a Graphical User Interface (GUI) of an application program to a user of this device. A processor (or Computational Processing Unit) is also provided for controlling and rendering the GUI presented to the display. The display may be a touch panel. The touch panel can be seen as an input device allowing interactions with a finger of a user or other devices such as a stylus. Such an input device can, for example, be used to make selections of portions of the GUI. The input received from a user's touch is sent to the processor that interprets the touches in accordance with the application program (AP) corresponding to the GUI. For example, the processor can initiate a task, i.e. a control of the AP, in accordance with a particular touch. More generally, the processor of the mobile device 201 is provided for running the Native Operating System (OS) 220 of the mobile device 201 .

A touch panel or keyboard, or keypad may also be provided to control one or more APs running on the processor of the mobile device 201 . A convergent application store client or CAS client 210 may be provided for interaction with the CAS 100 of FIG. 1 A. Such a client, as with existing appstore client (like the iTunes™ client available today on an iPhone™) , will allow the user to search and browse the different applications available for download. This CAS client 21 0 may also deal with payments for applications that necessitate such a payment prior to download. Contrary to existing appstore clients, the CAS client 210 will be able to discover the (OS free) applications using the CAS APIs 152 of FIG. I B through the pointers and collections. Indeed, thanks to the present CAS 1 00 and CAS client 210, an application may be only presented through its name and feature descriptions (the consolidated metadata mentioned before) , the collection remaining hidden for instance to the user.

A second embodiment of an electronic device in the present system is illustrated as a mobile device 202 in FIG. 2B. As with the FIG. 2A, the illustration is also functional and the hardware elements of the mobile device 202 are not shown either. Mobile device 202 may comprise the same hardware elements as with the mobile device 201 . Furthermore, the electronic device 202 will comprise a plurality of running or executing environments 221 , 222 and 223. In this embodiment with multiple execution environments, a platform control manager 215 (such as a hypervisor) is present to bridge the communications between a CAS client 21 1 and these execution environments 221 to 223.

The CAS clients 210 and 21 1 may exist for all available platforms and be provided to a running environment after its registration with the account manager module 140 of the CAS 100. More generally, the CAS client is a software component (such as an app or software program) which has the following functions:

- handle device registration and notification relay,

- communicates with the CAS 100 via CAS APIs 1 52,

- understands device notification mechanism (such as Google Cloud Messaging, Apple APNS, etc) to receive pushed notification in the electronic device from the distribution and notification controller module

DNCM 1 50. Alternatively, it could be a tiny web client (e.g. local web server) that allows the DNCM notifications to reach the device and execution environment, and perform the notification dispatching process, - has access directly to the native execution environment (e.g. FIG. 2A) , or has access to different execution environments (the virtual machines in FIG. 2B) via the platform control manager 21 5.

FIG. 3 is an illustration of an exemplary embodiment of the application indexing across app store in the present system. This indexing is carried out by the AAMM 146 and more specifically the application crawlers 1462 and the cross platform classification manager 1464. In a preliminary act 300, different application market servers, like application market servers 121 , 122 and 123 from FIG. I B, are registered with the CAS 100 using the appstore registration module 1 460.

In a further act 305, the AAMM 146 may proceed with indexing the applications across app stores by pairs. First and second app stores 121 and 122 respectively will be discovered first through the application crawlers 1462 in a subsequent act 310 to collect application metadata. The metadata is used to compare applications across the app stores and find similarities. It may consist of application name, characteristics of the applications, description of the different application functions, user comments, and information about application developers. More metadata may also be taken into account.

In a further act 31 5, a preset similarity criterion will be applied to the collected metadata to link applications across the two app stores. This may be carried out through determining - for each application of a first store - applications in the second stores that are found similar based on the preset similarity criterion. For instance, for a given first application AP I from the first app store 121 , the cross platform classification manager 1464 will browse all applications AP2 from the second app store to find applications whose functions are similar. The indexing may be performed both ways so that each application from the first app store is linked with one or more applications from the second store, and reversely.

In an additional embodiment of the present system, the applied similarity criterion may allow to link applications whose functions are syntactically similar, a function being syntactically similar to another function when their respective metadata present syntactic similarities. In another embodiment of the present system, the preset similarity criterion may be based on an N PL engine that is applied to the collected metadata to find similarities among application characteristics and descriptions. A very basic similarity criterion could be based on the application and/or developers' name.

A similarly criterion is needed as similar applications may be described in different ways from an app store to the other. Indeed, an application developed by the same application provider/developer may be described using different wording when made available on other app stores. Furthermore, two " linkable" applications AP I and AP2 may even present core functions that are similar while having additional functions only available per app store. The similarity criterion may be chosen loose enough to allow the linking of applications with a small number of common core functions. Reversely, the similarity criterion may be chosen narrow or strict enough to allow the linking of applications proposing the exact same functions. One will understand that with a loose similarity criterion, the list of applications from the second app store linked to an application AP I from a first appstore may be significantly larger than with a cross platform classification manager 1464 running with a strict similarity criterion.

In a further act 320, the found links will be stored in the CAS database 125 of FIG. 1 B. As mentioned before, some or all of the application metadata may be also stored for each linked application. Overall the information stored for each linked application should be enough to uniquely identify said application in its app store of origin. Linked (i.e. similar) applications will be regrouped through the collection/pointer mentioned before in the CAS database 125.

Once all applications from the first and second app stores are linked, act 305 will be carried out again to seek for another pair of applications market places to index. For instance, the acts 310 to 320 will be carried out again to index the first app store 121 with the third app store 123, and again to index the second app store 122 with the third app store 123. Once an indexing of a pair of appstores is done, the linked apps can be regrouped in collections, or added to already existing collections (see exemplary table 1 here after) .

Using this exemplary embodiment with three registered appstores, a pointer to an app in the CAS database 125 may be associated to a collection of three linked applications AP I from the first appstore, AP2 from the second appstore, and AP3 from the third appstore. For popular applications like the New York Times or CN N, only one application per appstore may be retrieved through the indexing performed by the AAMM 146. With a looser similarity criterion, several apps per appstore may be linked under the game app "Angry Birds™" , like three under the Apple Appstore™ and four under the Google Playstore™.

Several versions of a same application from an appstore may also be indexed in the CAS database when corresponding to different versions of an OS. For instance, under the New York Times collection in the CAS database 125, five versions may be available from the Google Playstore™ for Android version 2.2, 2.3 and 2.4, 3.1 , 3.2 ... to accommodate the needs of the different executing environments of a same user. Indeed some of his devices may not support more recent versions of an OS. Similarly The New York Times pointer will also refer to the different versions of the New York Times apps in the Apple Appstore™ to accommodate for the different versions of iPhones™ a user may own.

Thanks to the indexing across appstores, the CAS 100 imports and aggregates apps from different sources including other appstores, app provider, etc. Each app may have different format (iOS, Android, etc) and different versions for the same format in terms of targeted running environment, screen size, associated OS or virtual machines, allocated hardware resources, etc. The CAS database 125 can be seen a repository comprising apps varying in different versions regrouped/lined in collections under different pointers or entries in the CAS database 125, based on their similarities across the registered appstores.

Table 1 below shows a matrix of app-platform example stored in the app repository 125. The table could also incorporate version numbers for each of these variables. For example, table 1 might contain entries for Android 2.1 , Android 2.2, and Android 3.0. The solitaire application might be compatible with versions 2.2 and 3.0 of Android, but not version 2.1 . The execution environment (platform) is not limited to only OS or virtual machine, but also includes web platforms such as browser, Java run-time, etc. Google

App- Platform Andro BlackBerry

iOS Windows Tizen Chrome Matrix id OS

Browser/OS

App# l X X X X X X

App#2 X X X X

App#3 X X X

Table 1 Entries/pointers in the CAS database

FIG. 4 is an illustration of an exemplary embodiment of the present method. In a preliminary act 400, a user sign-ups with the CAS 100. The registration allocates a user ID to the user. After login with the CAS 100 using the user ID, the user will register his different electronic devices either manually or automatically via a local CAS client that transfers the device information to CAS. The registration of a device may comprise identification of the electronic device characteristics.

The local CAS client 210 or 21 1 illustrated here before may be downloaded to a user's electronic device he logs in with the CAS. Once downloaded, installed and executed, the CAS client will collect the electronic device information including associated running environments with associated OS or virtual machines (VM), screen size, storage, memory, allocated hardware resources, network information, communication protocol, status data, etc. This registration process will create a repository of user devices profiles, managed by the account manager module 140.

The device & VM registration process may comprise the following characteristics:

- determine whether the user electronic device has one or multiple execution environments in presence,

- when multiple execution environments are identifier, the virtualization technology is identified, it could be e.g. a hypervisor - either type 1 or type 2 hypervisor, workspace virtualization, or Linux container technology, etc., - generate a unique " Device ID" , and also generate different Execution Environment IDs linked to the execution environment identified by the CAS client (see table 2 here after)

- store under the user I D, the different Device IDs and Environment IDs, along with the collected characteristics.

Table 2 below shows a list of user registered devices, along with one or more available execution environments as stored by the account management module 140. In order to keep track of different environments associated with a device, an environment ID (VM ID) is assigned, e.g. for tracing down a specific environment running on a device.

Table 2: Example of a user registered devices and running environments In the present system, a plurality of running environments, associated to one or more electronic devices, are registered to the user. These registered running environments will receive the retrieved application version as described here after.

In an additional embodiment of the present system, the plurality of running environments may be registered or linked to the user through a social graph in a social network. The running environments then correspond to electronic devices of friends of the user on a social network. A social network may be seen as a graph structure defining relationships between a plurality of nodes, each node corresponding to an identifier of a user. A user can define a social graph which corresponds to a portion of the graph structure. This portion defines a plurality of nodes/identifiers linked†o the user, nodes that are given special access rights for instance to information about a user. Using the running environments registered to the user through his social graph, the present system will allow to push the different versions of an application to the running environments of his friends on the social network.

In a further act 41 0, the user can browse the catalog of available apps from one of his registered devices, using e.g. the CAS client, or through a different electronic device, provided he logged in a portal provided by the CAS 1 00. Thanks to the indexing across appstores illustrated in FIG. 3, the CAS can present to the user an interface where apps are displayed as representing a collection of versions. The GUI representation of collection or entry for an (OS free) app in the CAS database 125 may comprise the consolidated metadata, e.g. enough information for the user to identify an application he is searching for.

In a further act 420, a user will "subscribe to" (i.e. select) an app from the CAS user interface. The applications offered through the CAS correspond to the collections of similar applications (and their different versions) aggregated across the different registered appstores. Nevertheless, to the user, the experience is the experience of selection an OS free application.

In a further act 430, the CAS will retrieve the running environments registered to the user. This may be done with retrieving through the user ID the corresponding Environment IDs as managed by the account manager module 1 40. The associated OS are also retrieved.

In a subsequent loop from act 440 to act 470, implemented for each retrieved running environment (registered to the user) , the CAS 100 will search in the app collection for the selected/subscribed application the version corresponding to the OS of the running environment under review. More specifically, one of the registered running environments is selected for review in act 440. Then in a further act 450, the CAS 100, more specifically the DNCM 1 60, will determine the right available version of the selected app for the running environment under review. In a further act 460, the version of the app determined in act 450 will be pushed or notified by the AFM 148 to the running environment under review.

In an additional act 470, the CAS will check if more running environments are available for the user. Provided more running environments are to review (answer Yes†o act 470) , the CAS will resume the loop 440-470 in act 440. Provided all running environments have been reviewed, the process will end in act 480.

In an additional act of the present method, the determination of the app version in act 450 may take into account further device characteristics such as screen size, hardware ... as stored by the DMM 142. In another embodiment of the present method, the CAS may also use running environment specificities as stored by the EEMM 144.

In the present system, a user account is scalable as he may register new electronic devices and/or new running environments. To do so, each application selected by a user (in act 420 of FIG. 4) may be saved with the account manager module 140 for subsequent use. When a user registers a new running environment (generation of a new VM as reported by the CAS client, addition of a new electronic device ...) under his user I D, the CAS will check the saved applications for the user. It will then, for each saved application, retrieve an application version in the selected application collection that corresponds to the OS of the new registered running environment. The retrieved application will then be pushed to the new registered running environment.

Notification to a target running environment can be done by any capable device communication protocol or method, and if necessary, the local CAS client is capable to relay the notification and data, then pass it into the targeted execution environment (e.g. a virtual machine) . The notification will contain information on how to retrieve the app binary code.

For example:

- push android version of the app to Android mobile phone via Google Cloud Messaging,

- push iPad version of the app to user' s iPad via Apple Push Notification Service,

- push Tizen version of the app to user's Tizen virtual machine (execution environment) running in user' s Windows PC (user's device) ,

- push web version (HTM L5) of app to user's Google Chrome browser/OS

(execution environment) in the running Windows virtual machine (associated OS) in user' s TV Set-top box (user' s device) via a web service API call. While pushing the app version to a targeted environment on a user device, whether this environment is native or a virtual machine, the combination of Device ID + Execution Environment ID (VM ID) can be used to trace down to the designated execution environment on the user device.

Using the example of Table 2, device ID "3d9d9ad3" has two environments

(Windows 8 & Android VM) . When pushing the two versions of a user selected app, notification can combine a parameter "3d9d9ad3: 1234-1234-1234-1234", the local CAS client then receives the pushed notification at the device level (via the Device ID "3d9d9ad3") . It will subsequently relay the notification to the targeted execution environment (via VM ID " 1234-1234-1234-1234") so as to point to the Android VM running on the Windows 8 device.

In case an execution environment of an electronic device is already registered but not actively running or unable to receive the pushed app, the CAS will attempt to do the push notification again when the device and execution environment becomes available. The app subscription is also reflected on the user account, and the user also can manually request to download the app to trigger the app distribution.

Using a practical example, the Convergent appstore server (CAS) may aggregate an game app called "Angry Bird" into an "Angry Bird" collection which has an Android version, iOS version, a Windows version and a web version (for browser) . User James has a Galaxy Nexus Android phone, an Apple iPad, and a Windows 8 tablet with an Android virtual machine running in parallel and James simply runs one time a CAS client on each device (login & register device automatically) . With existing solutions, James needs to go through each appstore allocated on each electronic device to download the app in order to execute it. With the present CAS, James will simply go to the convergent appstore Ul, and search for the Angry Bird app. The search will return one app "Angry Bird" corresponding actually to the Angry Bird collection. The different versions of this app are transparent to the user. James will simply select the app once. The selection of an app in the CAS may be seen as a subscription as any new registered running environment, as explained before, will receive or be notified of the relevant app version.

Subsequent to the subscription, the CAS will scan through James' registered devices, run a mapping process between the registered running environments and the CAS app database, optionally check the registered device availability then automatically push the right version of "Angry Bird" app to the execution environment on each of James' devices. For example, Android version is pushed to Galaxy Nexus and the Android virtual machine on the Windows 8 tablet, iOS version is pushed to the Apple iPad, and Windows version is pushed to Windows 8 tablet's Windows environment, accordingly.

The system, device and method described herein address problems in prior art systems. In accordance with an embodiment of the present system, the CAS will push the right versions of a user subscribed (selected) app to the user's registered running environments.

The methods of the present system are particularly suited to be carried out by a computer software program, such program containing modules corresponding to one or more of the individual steps or acts described and/or envisioned by the present system. Such program may of course be embodied in a computer-readable medium, such as an integrated chip, a peripheral device or memory.

The computer-readable medium and/or memory may be any recordable medium (e.g., RAM, ROM, removable memory, CD-ROM, hard drives, DVD, floppy disks or memory cards) or may be a transmission medium utilizing one or more of radio frequency (RF) coupling, Bluetooth coupling, infrared coupling, etc. Any medium known or developed that can store and/or transmit information suitable for use with a computer system may be used as the computer-readable medium and/or memory.

Additional memories may also be used. These memories configure a processor of the server hosting the CAS to implement the methods, operational acts, and functions disclosed herein. The operation acts may include mapping apps across appstores, and pushing different version of a user selected app to his registered running environments in accordance with the present system.

Finally, the above discussion is intended to be merely illustrative of the present system and should not be construed as limiting the appended claims to any particular embodiment or group of embodiments. Thus, while the present system has been described with reference to exemplary embodiments of user mobile devices, it should also be appreciated that numerous modifications and alternative embodiments may be devised by those having ordinary skill in the art without departing from the broader and intended spirit and scope of the present system as set forth in the claims that follow.

Indeed the present teaching may be transposable to any electronic device capable of running applications downloaded from an application market place, such as a general purpose computer, a PDA, a pad ...

Further, while exemplary user interfaces are provided to facilitate an understanding of the present system, other user interfaces may be provided and/or elements of one user interface may be combined with another of the user interfaces in accordance with further embodiments of the present system.

The section headings included herein are intended to facilitate a review but are not intended to limit the scope of the present system. Accordingly, the specifications and drawings are to be regarded in an illustrative manner and are not intended to limit the scope of the appended claims.

In interpreting the appended claims, it should be understood that:

a) the words "comprising" or "including" do not exclude the presence of other elements or acts than those listed in a given claim;

b) the word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements;

c) any reference signs in the claims do not limit their scope;

d) several "means" may be represented by the same item or hardware or software implemented structure or function;

e) any of the disclosed elements may be comprised of hardware portions (e.g., including discrete and integrated electronic circuitry) , software portions (e.g., computer programming) , and any combination thereof;

f) hardware portions may be comprised of one or both of analogue and digital portions;

g) any of the disclosed devices or portions thereof may be combined together or separated into further portions unless specifically stated otherwise; h) no specific sequence of acts or steps is intended to be required unless specifically indicated; and

i) the term "plurality of" an element includes two or more of the claimed element, and does not imply any particular range of number of elements; that is, a plurality of elements may be as few as two elements, and may include an immeasurable number of elements.

Claims

CLAIMS What is claimed is:

1 . A method for pushing an application to a plurality of running environments associated to one or more electronic devices and registered to a user, each running environment being further associated to an operating system (OS) , the application being available in a plurality of versions, each version corresponding to at least a different OS, the method comprising:

receiving selection of an application from a user,

retrieving the running environments registered to the user, and their associated OS,

for each registered running environment, retrieving the application version corresponding to the OS, and,

pushing the retrieved application version to the each registered running environment.

2. The method of claim 1 , wherein each running environment is further associated to an electronic device type, each version of an application further corresponding to an electronic device type, the retrieving of the running environments further comprising retrieving the associated electronic device type, the application being further retrieved based on the associated electronic device type.

3. The method of one of the previous claims, further comprising:

- storing the selected application,

registering a new running environment to the user,

retrieving the application version for the stored application that corresponds to the registered new running environment,

pushing the retrieved application to the new running environment.

4. The method of one of the previous claims, wherein each running environment is associated to device characteristics, retrieving the application version further comprising retrieving the application version corresponding to the device characteristics.

5. The method of one of the previous claims, wherein the plurality of running environments registered to the user are registered through a portion of a graph structure describing a social network hosted on a server, the graph structure defining relationships between a plurality of nodes, each node corresponding to an identifier of the social network.

6. An application market place server node for pushing an application to a plurality of running environments associated to one or more electronic devices and registered to a user, each running environment being further associated to an operating system (OS), the application being available in a plurality of versions, each version corresponding to at least a different OS, the application market place server comprising a processor operable to:

receive selection of an application from a user,

retrieve the running environments registered to the user, and their associated OS,

for each registered running environment, retrieve the application version corresponding to the OS, and;

push the retrieved application version to the each registered running environment.

A telecommunication system comprising

an application market place server node for pushing an application to a plurality of running environments associated to one or more electronic devices and registered to a user, each running environment being further associated to an operating system (OS) , the application being available in a plurality of versions, each version corresponding to at least a different OS, a first electronic device comprising at least a first running environment associated to a first OS, both first running environment and OS being registered with the application market place server,

the application market place server comprising a processor operable to: receive selection of an application from a user,

retrieve the at least first running environments registered to the user, and its associated first OS, retrieve the application version corresponding to the first OS, and;

push the retrieved application version to the first running environment.

8. A non transitory computer readable carrier including computer program instructions that cause a computer to implement a method for pushing an application to a plurality of running environments associated to one or more electronic devices and registered to a user, each running environment being further associated to an operating system (OS), the application being available in a plurality of versions, each version corresponding to at least a different OS, the computer readable carrier comprising instructions for:

receiving selection of an application from a user,

retrieving the running environments registered to the user, and their associated OS,

for each registered running environment, retrieving the application version corresponding to the OS, and,

pushing the retrieved application version to the each registered running environment.