FR2919738A1 - Service e.g. Goojet service, creating, organizing, delivering, exploiting and accessing method for e.g. mobile telephone, involves launching computing application corresponding to selected leaf when node is selected - Google Patents

Abstract

The method involves mapping a service with an arborescent structure having nine branches for each node, where each branch leads to other node of the structure or leaves. A navigation request of part of a communicating mobile terminal e.g. mobile telephone, is received by a server connected to a service database. Identifiers of the nodes or descending leaves of same node are provided by the server, and one of the nodes or leaves are selected. The selected node or leaf is communicated to the server. A computing application corresponding to the selected leaf is launched when the node is selected. An independent claim is also included for a device for creating, organizing, delivering, exploiting and accessing a service.

Description

METHOD AND DEVICE FOR CREATION, ORGANIZATION, DELIVERY,

  OPERATING AND / OR ACCESSING SERVICES

  The present invention relates to a method and a device for creating, organizing, delivering, operating and / or accessing services. Many systems are known to enable the creation, organization, delivery, operation and access to services. However, these systems are not suitable for communicating mobile terminals and are, therefore, very little used. The present invention aims to remedy these disadvantages. For this purpose, according to a first aspect, the present invention aims at a method of creation, organization, delivery, operation and / or access to services, characterized in that it comprises: step of mapping services with a tree having, for each node, not more than nine branches leading, each, to another node of the tree or to a sheet, each sheet corresponding to a computer application, - a step of reception, by a server connected to a service database, of a navigation request from a communicating mobile terminal and, iteratively: a step of providing, by the server to the mobile, identifiers nodes or sheet 20 descendants of the same node, - a step of selection, by the mobile of one of said nodes or one of said sheets, - a step of communication to the server of the selected node or sheet and - if a node has been selected, u iteration of the supply, selection and communication steps and if a sheet has been selected, a launching step of the computer application corresponding to the selected sheet. Thus, by having, at each level of the tree, at most a number of nodes or sheets corresponding to a number of keypad keys of a mobile phone, have allowed the user to navigate with a simple pressure on a key associated with a node 30 or sheet and reach the computer application that interests him. According to particular characteristics, during the provisioning step, icons and / or texts associated with the descendant nodes corresponding to the provided identifier are displayed, on a screen of the communicating mobile terminal, in the form of a 3x3 matrix corresponding to the nine digits 1 9 to a keyboard of the communicating mobile terminal, the selection step can be performed by the user by pressing the key bearing said corresponding digit.

  According to particular characteristics, during the selection step, if the user presses on a first predetermined keyboard key different from the keys 1 to 9, the display on the screen of the communicating mobile terminal goes back and displays what which was displayed an iterative cycle earlier.

  According to particular characteristics, during the selection step, if the user presses on a second predetermined keyboard key different from the keys 1 to 9, the display on the screen of the communicating mobile terminal returns to the first iteration. According to particular characteristics, during the selection step, if the user presses on a third predetermined keyboard key different from the keys 1 to 9, the display on the screen of the communicating mobile terminal includes explicit titles of the nodes. and leaves displayed. According to particular characteristics, during the selection step, if the user makes a long press on a keyboard key among the keys 1 to 9, it opens contextual help related to the node or the sheet corresponding to said key on which a long press is made. Thanks to each of these four last provisions, browsing the tree is very easy. According to particular characteristics, at least a portion of the computer applications corresponding to the sheets of the tree structure are among the following: downloading and / or displaying text, downloading and / or displaying a photo, downloading and / or playing (streaming) a file of music, download and / or play (streaming) a video file, - trigger a phone call (with 1 or more people), trigger the sending of SMS (acronym for short message system for short message system) or MMS ( acronym for multimedia message system for multimedia message system), trigger the sending of electronic messages (mails), choose from one or more lists and transmit the choice back end, fill a form or form (in English template) then the pass on the back end and invoke a predefined web service.

  Thus, the main actions requested on the web can be launched by the navigation described above.

  According to particular features, the method as briefly described above comprises a step of personalization, by the user of the tree implemented in response to navigation requests from the communicating mobile terminal. Thus, the user can define, for example by an access to the server over the Internet, possibly from a personal computer, the tree in which it will navigate from its communicating mobile terminal. According to particular features, the method as briefly described above comprises a step of defining an explicit user profile, by said user, the behavior of at least one computer application associated with a leaf of the variant tree. depending on the explicit profile of the user. According to a second aspect, the present invention relates to a device for creating, organizing, delivering, operating and / or accessing services, characterized in that it comprises: a means for mapping the services with a tree structure comprising, for each node, not more than nine branches leading, each, to another node of the tree or to a sheet, each sheet corresponding to a computer application, -a means of reception, by a server connected to a database of services, a navigation request from a communicating mobile terminal - a means of supply, by the server to the mobile, identifiers of nodes or leaf descendants of the same node, - a means of selection, by the mobile of one of said nodes or one of said sheets, - means of communication to the server of the selected node or sheet and the means of supply, selection and communication being adapted, if a node has summer s selected, to perform an additional iteration and - a means of launching the computer application corresponding to the selected sheet, if a sheet has been selected. According to a third aspect, the present invention is directed to a computer program, characterized in that it comprises instructions executable by a computer for implementing the method that is the subject of the present invention, as briefly described above. According to a fourth aspect, the present invention is directed to a computer-readable information medium comprising computer-executable instructions for implementing the method of the present invention as briefly described above. The advantages, aims and particular characteristics of this device, of this computer program and of this information medium being similar to those of the method which is the subject of the present invention, as briefly described above, are not recalled here. . Other advantages, goals and features will become apparent from the following description.

  The hardware structure supporting the services implemented by the present invention is based on a distributed architecture comprising a backend part (in French of support), residing on a set of servers, accessible via the Internet, and mobile parts, residing on mobiles, accessible via conventional data links offered by mobile operators.

  A new communication protocol / language, defined for the implementation of the present invention, named GML and implementing tags, manages the interactions between the backend parts and the moving parts. In addition to their distributed structure, these services are also original in their behavior which differs from the state of the art of existing mobile services by the following 15 characteristics: - they are centered on the user (in English user-centric), that is, the behavior and presentation of these services can adapt to each user, as opposed to generic behavior, - they have a ubiquity, that is to say that these services are designed, from their 20 birth, to be accessed both via a mobile (access said mobile) or by an internet browser (access said web), community: these services allow several users to share, both in reading and writing, common data, regardless of their means of access (mobile or web), and 25 - they implement a navigable space: these services are organized between them by a referencing mechanism that allows users to navigate through all these services in successive stages from a mobile. The innovations offered by the implementation of the present invention cover several fields: the structure of the distributed objects and the communication protocol which together

  allow the implementation of services, each such service being called a Goojet, - the structure that allows to organize, manage and exploit all Goojets

  (this set being called the Goojet space) and - some services created as Goojet. The infrastructure is based on a remote man-machine interface, a matrix browser, a web menu and a recursive structure.

  In the following, we call mobile, a communicating mobile terminal, for example a mobile phone or a personal digital assistant (in English PDA, acronym for personal digital assistant). One of the foundations of architecture is the intelligent distribution of work (treatments, data, presentations) between the mobile and the backend: each service is divided into a presentation part, whose appearance and behavior are modeled in the GML language, and a heavy part comprising data, data processing and interfaces with other components (external web services, other users, etc.). The presentation part is sent at the request of the mobile backend part of the user, according to his needs and is interpreted on the fly by this mobile, in which there is an interpretation environment (referenced under the code of runtime mobile) of the GML. The heavy part resides on the servers and is accessible via the internet. Thanks to this model, the mobile is relieved of heavy treatments. In addition, each access to a given service is adapted to the user. This distribution of loads and this synchronization on demand between the web (in English Web) and the mobile via the GML protocol is a kind of extrapolation of the thin client model with a web browser, but adapted to the mobile. The mobile runtime may thus be considered as a new type of browser, specifically adapted to the structure of Goojets and the organization of their space.

  The Goojets are displayed by the mobile runtime as a 3x3 matrix corresponding to the nine digits 1 to 9 of the mobile keyboard. At each moment is displayed, on the mobile screen of the user, a 3x3 matrix with nine data, in the form of nine icons. The invocation of the action represented by each of these data is done, if necessary, by pressing the key on the numeric keypad corresponding to the selected icon. Selecting an icon leads to one of the following actions: - opening another 3x3 dot matrix page; in this case, the icon that was chosen was a navigation node in the tree of Goojets and the fact of having selected it to navigate the user in an additional level of depth, where, recursively, he finds so nine icons. -invocation of a terminal action: the selected icon corresponds to a sheet of the Goojets tree; the user is at the end of his navigation with regard to the path followed and invokes the service. Two types of terminal actions exist: - Goojet atomic action: the Goojet infrastructure has a certain number of possible atomic terminal actions, which, together, make it possible to build a Goojet service, by successive aggregation and by hierarchical organization and recursive. These atomic terminal actions include (non-limitative list): Download and / or display a text, Download and / or display a photo, Download and / or play (streaming) a music file, Download and / or play (streaming) a file video, Trigger a phone call (with 1 or more people), Trigger sending SMS (acronym for short message system for short message system) or MMS (acronym for multimedia message system for multimedia message system), Trigger l Sending electronic messages (mails), Select in one or more lists and transmit the choice to the back end, Fill a form or a form (in English template) then transmit it to the back end and Invoke a predefined web service. -application: an application is a set of processes and actions that execute, possibly interactively with the user, at the end of navigation, but which require a higher level of sophistication than predefined atomic actions. An application can thus consist of several successive choices, several information fills, and several transactions with the backend, but still remaining in the tree, that is to say, remaining in a unitary context without additional navigation in the Goojet tree. An application is therefore distinguished by its contextual unity (in the sense of navigation) and by its complexity, as opposed to atomic action. Note that an application can be created by aggregating several atomic actions in the same navigation context; such an application is therefore fully modeled by GML; but an application, still in a navigation sheet, can also invoke a clean mobile executable; such applications do not render their service by interpretation of GML, but use GML and the Goojet recursive tree to be made accessible: as such, the Goojet structure is both a set of services interpreted by GML, but is also an organizational structure, which may include heterogeneous services (pure GML, or including a mobile executable part). Hereinafter, details of local ergonomics to the mobile are described. The invocation of an action or an application or the navigation via a node is done by pressing one of the numeric keys 1 to 9 which correspond, geometrically, to the icons of the presentation matrix 3x3, as indicated above. . In addition to this basic navigation, which is characteristic of Goojet navigation, there are additional possibilities: - shortcut: if a service is in the 3rd position of the Qth position of the Staple position of the current page, the basic navigation asks to press P, then Q when the corresponding page is displayed, then R, etc. The system offers a shortcut mechanism that allows to press PQR quickly, action following which the system will directly seek the required end position, saving the intermediate steps, - furthermore, navigation by joystick and I or touch screen when supported by the mobiles, are also by the system and - the system also offers other pre-defined function keys allowing easy navigation and adapted to the mobile when pressing a key on the mobile keyboard: - # key to return one backwards, - Key 0 returns to home page, - Key * displays explicit titles superimposed on the icons of the current page, - Long press on a key from 1 to 9 displays a contextual help relative to the Goojet of the current page positioned in the selected box 1 to 9 Regarding recursion, in the Goojet structure, recursion is important. te: the model is open. Each object (atomic action, navigation node or application) is attached an identifier and an icon. An atomic terminal action is a Goojet. A sophisticated application is also a Goojet. A Goojet node opens a door to (potentially) nine other Goojets, each of which can in turn be of any of the three types, etc. A Goojet can therefore, by extension of the model, be a subspace, a complete branch, in which are then organized several other levels of Goojets, several other branches, etc. By analogy to the semantics of the web, a complex Goojet that aggregates several other Goojets or even several branches of Goojets, etc., can also be called a portal. With regard to a Goojet space of a user and the customization of space, the Goojet space is a Goojets database, each of which is potentially constituted by tree aggregation, with a maximum of nine branches at each node, other Goojets. Each user then defines his own Goojet space, which is the mobilization of a Goojet subspace defined for this user: the Goojet space of a user is therefore a tree of Goojets, organized according to the same structuring rules as the space global (thus based on 3x3 matrices, recursion, node, atomic actions and applications). The user defines this tree through a web interface that provides several tools for intuitive construction of his space. Once created on the website, this tree is called mobile, that is to say, accessible by mobile, thanks to the GML protocol. The user can then, when he wishes, return to this web interface to edit his Goojet space.

  The base (root) of this tree will be the homepage of the Goojet service on the mobile of this user. From this page, the user can then navigate in his Goojet space. This space is constituted by the user: the user has chosen Goojets services that he wants to access by his mobile and organized them according to his tastes. Its Goojet space is not the entire Goojet space, but a subset, organized according to the tastes and needs of each user. The interest of this user centric view (thus filtered) of the global world is very different from the global view of the Internet as given by conventional web browsers based on the WAP protocol. The importance of this filtered and user-centric view comes from the fundamental difference in usage behavior between a web situation (where the user has a certain comfort and in general a certain time, and where he waits so completeness and richness during navigation) and a mobility situation (where the user has a more limited terminal and probably a more pressing environment, and where it requires speed, ease and relevance); this filtered view of a user-dependent global navigable world is one of the preferred features of the implementation of the present invention and rests, on the one hand, on the matrix organization recursively modeled by the GML and, on the other hand, on profiling and profiling services (in English profiling) that make it possible to extract custom views. With reference to the section on recursion, above, it is understood that the personal space of a user consisting of a tree Goojets is itself a Goojet. With regard to intelligent cache management, from an execution point of view, this tree, which represents the Goojet space specific to a given user, is maintained in Goojet's backend system; its representation is sent to the mobile on demand, depending on the navigation of the user: when the user invokes Goojet on his mobile, the system sends him (always via GML) the representation of his home page, from from which he can navigate and invoke services. As this navigation and its invocations progress, the backend, via GML, sends to the mobile the necessary representations (following pages of Goojet in the tree structure, representation of the required terminal actions, etc.). This representation information GML is dynamic and relies on intelligent cache management: the system optimizes the exchanges between mobile and backend in favor of the user experience, that is to say to reduce the time of latency during navigation. Typically, this implements prefetching algorithms (prediction of future choices) that rely on the user's profile of use as well as on the structure of his Goojet space: when sending a page of nine Goojets, if, in general, during its passage on this node, the user goes then in more than 80% of the cases on the cell 4 of the next node then invokes the terminal action 7, this path will be pre- fetched during the first invocation (prefetch in depth). If, on the other hand, the system does not know where the user will probably navigate, the system prefects in width the whole (or the maximum, depending on the capacity of the mobile) Goojets of the next level.

  In terms of customization of services, explicit profiles and inferred profiles, beyond the aspect of creating a personal view for each user of the global tree, the Goojet system also makes it possible to adapt the final behavior, that is, the terminal action or application that is invoked at the end of the navigation. Thus, the terminal actions generally comprise parameters that can be chosen for the user, either explicitly by the user during his definition and optimization of his own space, or automatically by the system, then based on preferences data indicated by the user when defining his profile, or on inferences by the system based on the dynamic behavior of the user during his presence in Goojet. Typically, if a user often browses branches or often uses terminal actions referring to Paris, he will be offered a setting using Paris if he is navigating a terminal car rental action. With regard to private branches, public branches, the dynamic evolution of a Goojet space and successive affinity navigation, when a user defines Goojets (or Goojets branches, or Goojets portals, which are also Goojets), it can indicate the audience of these Goojets: public: everyone has access and therefore all Goojet users can increase their own Goojet space by referring, in one of the node or leaf of their tree, to this Goojet ; - private: this Goojet can be navigated and used only by the user or - Community: this Goojet can be referenced (and thus navigated and used) by a set or users designated by the creator of the Goojet. In addition to the virtue of sharing, this possibility provides an important dynamic characteristic to the Goojet space and its navigation: a user can refer, in his own space, to a public part of the space of another user, which can to be enriched, the other user adding branches or Goojets which, by transitivity, are also added to the navigable space of the first user. A user can, in turn, refer to a public or community part of a third, etc. From one to the next, spaces can intersect or inter-pollenize, allowing successive affinity navigation in a living, dynamic and open space, though still controlled and always user-centric.

  With regard to the promotion of Goojet, as we have seen, the space of a user is a tree, with its public or private branches, chosen and / or defined by the user via a web interface. This tree becomes navigable via his mobile and leads, in his sheets, to a collection of services. The fact that some of these branches are references to other public branches creates a first level of dynamism in the user's space structure, because the public branches that it refers to can evolve. A second level of dynamism is offered by the mechanism called InGoojet: in any space of any user, a branch is reserved by the Goojet system to dynamically add Goojets to this user: it is an extension of the concept of mailbox, but structured for referencing to Goojets. This reserved branch is structured in a linear way: on the first page it contains only two Goojets: an empty Goojet, which is a place reserved for the first Goojet that will be sent to this user (Goojet says place holder) and a second Goojet node that leads simply, on the second page, a page structured in the same way as the first one (this Goojet node is a Goojet next or next), and so on, recursively, as needed. This allows the user to simply navigate linearly in this branch, whose size dynamically varies according to the Goojets he receives. Goojets can be sent to users by promotional actions: on the website or via their mobile, a user can decide to share a Goojet with another user or with a user community and promote this Goojet, whose reference will be added dynamically by the backend on the tree representations of each recipient, at the end of the InGoojet branch list. Each user has immediate access to a new service. He may, if he wishes, remove it from his InGoojet branch; he can also, via the web interface, reorganize his space and put this Goojet, if he wishes to keep it, to another place in his own space. In addition to its use in the context of Goojets promotion or exchange, this InGoojet dynamic branch is also used directly by the user if he wishes to add access to a service in his Goojet space without, however, having access to a web interface (which is, as described above, the nominal way of creating and managing a Goojet space). This need can be opportunistic and urgent: the system thus makes available to the user, via its mobile interface and in addition to the web interface, a special Goojet called Goojet Picker which allows the user to select a Goojet in the Goojets database by entering its unique identifier. The selected Goojet reference will be added to the user's InGoojet, as for a Goojet received by a third party promotion.

  In a similar way to InGoojet, the system offers the user a third level of dynamism: the bookmark or bookmark. The bookmark is a linear structure in every respect similar to InGoojet, in which are dynamically added references to Goojets that the user wants to make immediately available. The bookmark is particularly useful when the user navigates an unknown branch of space (typically a public branch to which he has had access by successive public browsing) and finds an interesting Goojet. The fact of the bookmarker, during its passage, sends the reference in the InGoojet, for immediate access and for possible subsequent reorganization when the user passes in front of a web interface. For the creation of services, the system allows the user to create his own mobile space by selecting and aggregating atomic actions, Goojets, Goojet branches or public spaces between them, in a tree organization that suits. Using these same mechanisms of selection, parameterization and aggregation, the user can also create Goojets (or Goojet space) not necessarily to reference them in his own space, but to make them available to other users. Thus, the Goojet system offers the new ability to a user, by aggregating and setting up pre-existing elements, to create new services, which will be available to other mobile users, without having to develop computer code nor have had to distribute, through any channel, mobile applications. Goojet's global space is therefore open to navigation but is also open to contribution and frees users from the complex and unrelated steps, without Goojet, to the creation, distribution and operation of mobile applications. With regard to explicit communities and inferred communities, just as user profiles can be explicit or inferred, communities (for declaration of right of access to branches, for Goojets promotions, etc.) can be: - explicit, that is to say defined by explicit lists of identifiers of users or mobile numbers, - inferred, that is to say, calculated, in real time, by the system based on statistics of use and behavior. Typically, such an inference uses a semantic distance calculation between users: based on the type of navigation and the type of services used, the system dynamically identifies communities of use (sportsmen living in Paris, adolescents who love rock & roll, etc. ). These inferred communities are used for Goojets' relevant promotion, for various community services (eg, tennis partner search, carpool service, etc.) and, to enable Goojet business partners, in commercial operations, to to appropriately reach the optimal audience for their messages and promotions. The Goojet backend therefore makes constant data acquisition on all users and Goojets to feed profiling algorithms, the results of which are then used for the personalization of Goojet services and spaces and for sending relevant information or services. This capability is one of the pillars of the commercial operation of the system. With regard to ubiquitous mobile web, the services defined on the Goojet infrastructure are intended to be referenced in accessible mobile trees to offer services in a mobile situation. But the structure of these services also makes them accessible via the internet (via a web browser). This allows users to share information, data and services regardless of their means of access. In addition, the Goojet system recognizes the means of access to a service and offers a different level of wealth depending on the means of access used. For example, the backend part of a voting Goojet simply displays the current vote result for mobile access, while it offers a wide variety of statistical and historical analysis during web access. For Goojet services, Goojet's infrastructure enables the development, promotion, and operation of innovative services, examples of which are listed below: 1 / synchronous on-demand conferencing: this service enables simultaneous their mobile, multiple remote users, without having to prepare or book a conference. This service is extremely practical in situations of mobility and dispersion. This service allows the user to select either by explicit entry of mobile identifiers or automatic entry of identifiers by the system (interpreting the list of contacts present in the Goojet page where the service is invoked) the list of candidates for a conference call. The simple evocation of the conference call terminal action, chosen from the user's Goojet space, will lead the backend to send conference invitation notifications to the recipients. These notifications can be multimodal and include, among other things, an SMS and a notification via Goojet interface (GML response to a polling). Upon receipt of the notification, the recipients may, by simple acceptance, be put directly in touch with the Goojet backend that organizes the conference. The mobile part of this Goojet service consists of selecting candidates and managing the notification (user-side triggering that prompted, guest-side acceptance). The backend part then consists, essentially, in the sending of notifications and the linking on the same fixed number when they are accepted. Beyond this function, the backend part of this Goojet conference also offers value-added conference management functions, such as records and / or statistics, whose operation is accessible via the web interface. 2 / Autonomous web-mobile transactional services: The backend part of a Goojet can handle transactional services between customers and suppliers, and can therefore, in some cases, substitute for heavy IT or Internet services, opening the door to a totally new family of services. This is made possible by the intelligent division of the treatments between mobile presentation and backend. For example, the Goojet reservation is defined as follows: - the provider, for example a restaurant, create his Goojet - this Goojet is a branch of various Goojets aggregates, including information about the restaurant, links to other Goojets deemed relevant or related by the restaurant. One of the sheets is the Goojet application reservation, set by the restaurant for his need, when creating his Goojet. Once created, this complex Goojet containing the Goojet reservation application set up for this restaurant is available to the Goojet user community. He could even be promoted. In any case, it can be found in the spaces of other Goojets users, potential customers of this restaurant and wishing to benefit from information and booking service during their mobility. The Goojet application reservation consists of several input pages of choice (each choice of input page is a configurable atom), which together form the elements of a query. For example, the user chooses a time and a number of people (the same concept of course applying to any type of request, the number of successive choices and the candidates for each of these choices being parameters entered by the creator of the Goojet at its creation). Then he sends his request, which the backend receives and processes. The processing of the backend is to send the request to the restaurant, in the format chosen by the restaurant when creating its Goojet reservation. The restaurant can choose a multimodal notification: SMS, phone call, invocation of a web service with its management computer system if necessary, sending an email, etc., whose content is manufactured by the backend according to the parameters sent by the mobile part of the client during his request. Among the many possible modes, one is also Goojet: the restaurant can have the mobile part provider of the same Goojet. This Goojet is structured in fact into a mobile client part, used by each customer of the restaurant to send their request, a backend party to process the requests, and a mobile provider that completes the transaction. With this Goojet, the restaurant can receive the request directly in the Goojet application space and process the request in near real time, from its mobile: on acceptance or rejection, it completes the transaction via the backend to the issuer of the request. It can also use its mobile provider part for management operations (for example display complete for future users). He can also, by using a web access to the backend, to have access to more wealth on this Goojet, including various statistics on the use of the service, information on the applicants, etc. Thanks to its distributed structure and thanks to its bimodal web-mobile access, this Goojet service of a new type replaces both a voice reservation service and a conventional information and management system. The transactional booking service, based on a complementary pair of mobile client-provider parties and a mediation and management backend is new. 3 / Interaction between the real world and the virtual world: the goal is to enter a virtual world with real-world communication tools (telephone connection, access to instant messaging, such as IM, trademark or e-mail , or mail). The novelty is based on the fact that we can connect two avatars between them by hiding their identity of their real life. The taking into account of the profile of the avatar is totally integrated with use of filters of voice (example a man who chooses a female avatar). 4 / Advertising panel on mobile: it is to offer an infrastructure that allows advertisers to publish information on a dedicated page. The concept is based on the idea of a billboard that appears in user space from time to time with profiled information. Dedicated to advertisers, this space is filled according to complex algorithms including the target that the advertiser wants to reach and the number of publications he wants to have. This space can also be used to transmit targeted messages, for example, ad info that the user to accept on various media. 5 / Digital DNA: it is a modeling of an individual through a string of bits. The idea is based on the definition of a sequence of binary properties that can represent any individual. At once what he is but also what he likes. This universal and public description of the digital genome can be used to make efficient pattern matching between individuals. 6 / Push to Get: The aim is to offer a mobile-type prompter communication infrastructure that can be interactive. The mobile is subscribed to a stream of immediate messages that scroll according to the news produced by an authenticated source (eg AFP, aufeminin.com, Auto / motorcycle, trademarks).

  The user can pick up more information by pressing a certain key on the mobile when the message appears. Capturing the information means that the system will take into account the item of interest and build a folder that will be sent to the user on the media he has chosen (mail, voice, Goojet). 7 / The synchronous conference: to allow two or more people to enter a conference synchronously, we choose, in a directory, the people concerned and we mean that we want to enter a conference. Each person receives a call number and a graphical interface indicating the correspondents who are being dialed (action to call the number and ring on the active number). The system reserves the number for the conference because knowing the number of the potential callers can filter out unwanted people who would call the number at the same time. The person in charge (in English leader) of the conference can decide, with a simple click, to switch everybody in conference (start of the billing for each caller). 8 / conference call platform. when a user is invited to a conference call, he has a trigger. The selection, or click, on this trigger causes the appearance of a page with the avatars of the persons invited to the conference call (for an unidentified person on goojet, one makes appear his name or his telephone number). A status is shown next to or on each icon of the avatar and indicates whether the corresponding user has entered the conference call. Optionally, the status identifies who is speaking. Preferably, the server does not take the communication of a participant, as long as there is not at least one other participant who calls him. This saves a user from being connected for nothing. 9 / An infrastructure of Tamagoshi that allows a goojet of life that we have on us. Backend objects / classes manage behaviors of the virtual animal. It is up to the user to derive these classes and to create other animals or virtual worlds. We note that all the mechanics of exchange between the backend and mobile is done by the backend. 10 / Matches that connect two teams, rules to pass a ball from one user to another and conditions of interception and shooting on goal. 11 / MailToGoojet: This service is based on the fact that each user has an email address of the type monld@goojet.com (mondd may be by default his mobile phone number but also a pseudonym). We put in front, a parser that processes e-mail and exploits features: - Central alarm: just put in the header of the email <ALARM) for the server to treat the email as a signal alarm and transmits the photos in a goojet with also a .wav file of the sound recorded during the seconds after the trigger, and text ... For example, an IP camera is able to send an email on motion detection with a set of data but made web server. This camera and data are accessed by the goojet server to, for example, drive shooting on demand.

  More generally it can be a simple way to communicate between users, or not. As for a wiki or blog, we can define tags (in English tags) that are interpreted by the parser and encapsulated in goojet to render any type of service. We can have predefined tags that bloggers could introduce in their blogs and which are regularly parsed by the goojet engine to dynamically generate "Goojet Blog" The user can also send an email of type: Subject, textual content and attachments which are processed according to their type to be encapsulated on "atoms" goojet type photo, sound, video (depending on the type of phone of the user e-mail recipient, we treat the parts compatible with the phone). This has the effect of creating a container, or container goojet with items stored in it and put in the Ingoojet of the recipient user. 12 / Collaborative environment: Goojet's infrastructure enables the development of collaborative services, defined as services that require opportunities for interaction and sharing among multiple users. Recall that conventional services for reading shared information, to which several users can access from their mobile, read-only, are not considered collaborative. The service offered by the present invention, in collaborative terms, consists of implementing the following elements together: a distributed application having: a centralizing part residing on the Internet; it is the server part, - several parts distributed on mobile terminals - the mobile client parts, accessing the server part via the GML protocol, - accesses via web browsers, on thin client parts, on PC, interactions between the server part and other applications residing on other web servers, using APIs or web services on the internet, - the possibility given to mobile parts to provide information (data, requests) to the server part, but also to other mobile parts via the server part and - the possibility given to the client parties to simultaneously access and modify shared data managed by the server part.

  The innovation comes from the presence, in the moving parts, of a dedicated application that allows sharing and transactions, according to an existing schema in the web world but not yet in the mobile world, still closed. On this principle, several collaborative services are offered by Goojet, including: - Glog: an extension of the blog concept for mobile: Glog is a shared database residing on and managed by the server part of the Goojet system. This database allows orderly access to data submitted to it. The data submitted to glog are any object that can be transmitted and transmitted by a mobile (text, photo, sound, video, voice message, data structured by GML such social signal, identification of a Goojet and choice of action in this Goojet, etc.) . The data, stored by glog, are ordered according to several criteria: - thread (thread), - theme, - date / time and - origin. A thread is a linear ordering based on the notion of answer: a thread at a starting point then a simple navigation by following / preceding (in reading), and a response to a thread simply adds an element at the end of the thread, thus enlarging the size. A chosen Glog thread can be read by a mobile via Goojet: the last elements, up to a maximum of nine, are accessible via a dedicated Goojet page and then displayed on demand according to their format (text, sound, image, etc.) . Accessing a thread can add an element (response). The wires are heterogeneous and can contain elements of any type. The theme is a metadata selected by the creator of a thread. The theme allows thread readers to do targeted searches. Like glog is, like any Goojet service, designed for the ubiquity of web-mobile access, the theme can be freely chosen at creation if the creation (initialization of a thread) is made from the website. If the creation is made from a mobile, the creator can either freely choose a theme by entering a text, or choose a theme among nine via a dedicated page Goojet. The nine themes proposed are either the nine themes that the user has chosen on his profile, via the web (Goojet general philosophy of preparation via the web of his own mobile space, which, once mobile, is no longer as exhaustive as the web, but is targeted for its own use, relevant and fast), the nine themes most used on glog, as calculated by the system and proposed to the user. In access of an existing son, the reader can also select a theme via the same theme window, or select via the window that indicates the nine most active children, or via his subscription window to his nine favorite sons, as he can define it on his glogor profile, via the web.

  The Date and time field allows, on the one hand, a chronological organization but also, via a web access, searches in time (whereas the mobile access will give by default the last nine entries in each thread). The origin field is the identity of the user who initialized the thread as well as the identity, for each entry in the thread, of the contributor. The glog server part also uses this field to calculate, and offer via web access, activity statistics by glog or user.

  It is noted that the glog can be used in conjunction with the Goojet gVote service, which allows, generically, each user to allocate a status (from a maximum of nine predefined statuses for each instance of the gVote service) to a candidate (from a maximum of nine predefined candidates for each instance of the gVote service). A typical instance of gVote may be to allocate a rating to an object (service, photo, thread, event, etc.). In conjunction with glog, gVote allows users to rate threads, themes, contributions, and contributors. The mobile part of gVote allows to give a note and display the current result, while the server part, accessed via the web, allows to display a great wealth of historical and statistical results, thus enriching glog. Another collaborative service is the shared alarm service. It is an element of a set of services around the organization of time within a group of people this set includes, among others, a shared agenda, offered by a third-party web application, and to which the server part of Goojet mediates, allowing mobile users to access, both read and write, a shared agenda. The alarm service falls into this category. It includes two structural differences with the agenda: on the one hand, it is fully managed by the Goojet system and does not require mediation to a third party service and, on the other hand, it requires event processing in the parties mobile.

  The group alarm service operates as follows: - A user uses his Goojet mobile or web interface to select the date and time of an alarm and the hearing of that alarm. It can also select the media used by the system to inform the audience of the alarm when it is triggered. Except for such specific selection (mail, call by automatic voice server, etc.), the system will work in two steps: - the alarm service server, upon receipt of a group alarm request, add a corresponding item in the box Goojet event of each member of the recipient group who is a Goojet user. - When these users update their Goojet events through Goojet's generic event management and notification mechanism, GML sends their respective mobile parties a message to arm their local Goojet alarm. These users are then notified of the triggering of the alarm locally by their mobile. The advantage of this remote arming (as opposed to remote alarm notification) is that the recipients are alarmed even if they are not receiving the Goojet service at the time of the alarm. - for non-Goojet recipients, or for recipients who have not synchronized their Goojet event handler before the alarm time, the server portion of the alarm service sends a message through a non-Goojet channel selected by the user who organized this alarm; typically, an SMS. A group alarm thus organized includes a time and date, an audience, but also a theme, which can be a free text or a theme among nine selectable via a dedicated selection window. As with any other Goojet service, these nine themes are either the user's favorite themes defined in their profile for this service, via the web, or, by default, the nine most likely themes calculated and offered by the system based on the usage profiles of this service. It is noted that Goojet's event management service requires that a number of Goojet service usage cases need to notify a user that an event is relevant to it. Since the Goojet system server does not have the ability to spontaneously send a request to a mobile client user, it can not itself notify the user of the event that concerns it. The generic mechanism used is as follows: - on the one hand, for each user, there exists in the Goojet server a space where the events relating to this user are stored, according to their arrival time and their priorities ( these events may have varied and heterogeneous sources such as a Goojet standalone service requiring a user to send information or notification, or a collaborative service by which another user wishes to interact with that user, or a request from a third party service for which the Goojet system mediates to mobile users). This event space is replicated on the mobile during a synchronization operation: the mobile part of Goojet automatically informs itself of the state of the event space. The event space itself is organized according to the Goojet structure (tree structure with up to nine branches at each node). then the mobile part - or the user himself for notifications not leading to automatic operations - can handle these events as necessary. The mobile part will inquire about the eventual need for synchronization of the event list each time access to the web server is required; thus, synchronization is frequent. Furthermore, an additional user-configurable polling (time draw) ensures a periodic synchronization which, itself, ensures that the events do not become too obsolete even in the case of a prolonged period without access to the server. by the moving part. And, finally, for high priority events, an SMS (or other media chosen by the user, such as a synthesized voice call or an e-mail) is sent to the user, in which case the priority event is imminent and where the last sync is old.

  In the remainder of this description, additional descriptive elements will be given, on the architecture, and on the services. ARCHITECURE: To warn the user of an event in Goojet, ping or signals will be made using telephone lines. One or more clearly defined numbers will briefly call the user (who will not pick up) to notify him of something new on Goojet (new message, new update etc ...). After receiving this short call, the user will only have to connect to Goojet. 1 0 Import another user's space into his ------------------------------------ ----------------- Not easy to characterize, but one of the originalities of Goojet: we can import the space of another user in his, This is not fundamentally different in pure theory of a hypertext link, but in this case the environment is homogeneous and we slip gently from its environment to that of another user. This makes the concept of shared services and information transparent. Moreover, it brings me questions about the practice of privacy (in English privacy policy) and other data security: it is necessary that we can put a level of visibility on each Goojet, a little as we can do on Flickr with 20 images (public / friends / family), and we can not do an action (ex reservation) under a person because we imported his space in his. Moreover, the addition in the buddy-list should be subject to authorization (as in most systems). Partitioning of data driven by social proximity ------------------------------------------ --------------- 25 An innovative approach to partitioning data: social proximity partitioning. In systems with very large volume, a database (even redundant or clustered) is no longer sufficient to store all data, and must be partitioned, ie have databases containing only one part of the users. Traditional approaches are simply based on a modulo of a unique identifier (like id-user% nb-machines) or a balancing of the data volume. In our case, the efficiency of the system can be improved by keeping highly connected users on the same server. Partitioning is then controlled by the connectivity of the graphs. It can make a big gain in performance when analyzing the neighborhood for recommendations, broadcasting information to the list of buddies, and so on.

  This does not preclude the geographic distribution of the data, since the connected graph of users can be stored in a datacenter located at the average location of this graph. Reverse Messaging: This part discusses a new way of handling email messaging based on the fact that we have only one instance of the message stored on the server of the sender and that the recipients of the message come to read the message on the server of the transmitter. This mode of treatment is particularly adapted to messages between correspondents identified within the same organization or community group. When a message is sent by a transmitter E to recipients Dn, the recipients are notified that E has sent them a message. Each recipient Dn can then connect to the server E with its identifier (secure) and thus read all the message that E sent to Dn. If E has sent several messages to Dn then Dn will see the list of messages that E has sent to him (new and old). If E wishes to send a message to a recipient with whom he has not established a relationship of trust, the server sends an email following the conventional method to ask if the recipient agrees to establish a relationship of trust with E. S ' he then accepts he will be connected to E and vice versa.

  This new approach to messaging allows: • To reduce the consumption of disks on mail servers, • To effectively delete SPAMs because to send a message to a recipient, he must have established the relationship of trust. In the establishment of the relationship of trust, there is no possibility to pass any message or attachment, • To know if the message was read by one or by all the recipients, • To manage a new concept of a message sent to the first X who read it: o E can send a message to N recipients by mentioning that as soon as at least X recipients have read the message the others are no longer notified they have a message to read • Manage validity dates on a message, • Better detect an internal or external messaging problem because if the message is not read by one or more of the recipients is that there is a potential problem. • To limit the visibility of certain parts of the same message according to the category of the recipients (management of the list of restricted diffusion), • To limit the diffusion / proliferation of a message by not allowing to repatriate it locally on the recipient's post. If E does not want the message to be broadcast or retrieved by the recipient (s), it uses an encryption option that will only allow the screen copy to duplicate the content.

  The reverse messaging approach is appropriate for the notion of multichannel broadcast. The issuer server can support several classes of readers: • Specific applications (reader on computer or mobile phone), • Use of a classic IO email client • Web application (can be used from a PC or phone browser). Unified Communication Infrastructure (UCI) Description: The infrastructure described in this section deals with the 4 standard message flow types (IM, SMS, mail and voice), as well as that provided by a proprietary community platform. The infrastructure makes it possible to bridge between these types of flows (incoming / outgoing). The appearance of the notion of Tag on the incoming flows makes it possible to enrich the behavior of the platform during the creation of the outgoing flows. The infrastructure makes it possible to broadcast on all types of available media using formatting capabilities appropriate to the media. The targeted media are: • A computer via: o A web browser on a dedicated URL o A mail client on a dedicated account o An IM client o A dedicated application on a proprietary format 25 • A phone via: o SMS client o A dedicated application o A WAP browser o A voice mailbox 30 The ICU is configured by each user to define the gateways he wants to set. The table below gives an exhaustive presentation of the different flows. The user when configuring the ICU must enter: • IM 1M accounts used • SMS: Phone number 35 • Mail: email address • Voice: Phone number • Platform: Id of his account Conversion of flows: EmissionlReceive IM SMS Voice Mail IM x 1 2 3 4 SMS 5 x 6 7 8 Mail 9 10 x 11 12 Voice 13 14 15 x 16 Platform 17 18 19 20 x This table shows the different types of broadcast messages and in reception. This means that the numbers appearing in the different boxes will be included to explain the treatments carried out by the infrastructure in each case. The x means that there is in principle no treatment necessary. A user of the unified communication infrastructure Issuing an SMS: When an SMS is received by the ICU, each text completed by @ is analyzed as a recipient. Example: DI @ D2 @ hello how are you? : will be treated as the message hello how are you? issued to the ICU for recipients D1 and D2. The ICU will carry out the following processes: Case 1: (the recipient has configured one or more 1M channels on which he wishes to be informed) The entire SMS (excluding recipient fields) is transmitted on 11M with the identity of the issuer Case 10: (the recipient has configured an email address on which he wishes to be informed) The entire SMS (excluding recipient fields), as well as the identity of the issuer are incorporated in the body of the email. The subject contains the platform informs you of the receipt of an SMS Case 14: (The recipient has set up a mailbox) The entire SMS (excluding recipient fields) is converted by a TextTOSpeach process as well as the identity of the transmitter. For each message recipient the ICU makes a voice call. Case 18: (The recipient subscribes to a community platform) The entire SMS is sent to the platform for analysis. The processing of the recipient fields must be carried out on the platform (Recipient IDs may be different than those known to the ICU) 23 24

  Emails delivery: consigne@plate-forme.com When an email is sent to the recipient's address through the Unified Messaging infrastructure it is analyzed according to the following cases: Case 2: (the recipient has configured one or several IM channels on which he wishes to be informed) The subject of the mail is transmitted on the IM first with the identity of the issuer The text content is extracted from the body of the mail and formatted to be transmitted on the IM Case 6: (the recipient has configured the SMS channel) The subject of the email is transmitted in the body of the SMS, as well as the identity of the transmitter Case 15: (The recipient has configured a mailbox) The subject of the mail is converted by a TextTOSpeach process as well as the identity of the issuer Case 19: (The recipient is subscribed to a community platform) The whole email is analyzed: • Subject: o The subject can contain a tag thus giving a business character to the message (example: [ALARM] i Intrusion at destination will solicit the platform with the tag ALARM to generate a behavior dedicated to the processing of an alarm). If the platform can not interpret the Tag, it uses the default behavior. • Attachments: o Each attached part is analyzed to define the type of document and allows the platform to perform a transformation on the source to fit the capabilities of the platform • Body of the message: o The body of the message may contain tags that guide the platform on the treatment of the body of the message complement generally with the Tag contained in the subject.

  Making a voice call: When a voice call is received by the ICU, the message is saved and the ICU asks to enter the recipients of the message. The identifiers may be preregistered identifiers on the ICU and associated with the caller's number. Example: A user with the phone number 0607080910 predefined the recipients D1 and D2 by giving them your identifiers 1 and 2. When calling the ICU from their mobile, the ICU identifies the calling number and at the end If the user enters # 1 # 2 #, the ICU will send the message to recipients dl and D2. 25

  The ICU will perform the following: Case 3: (the recipient has configured one or more IM channels on which he wishes to be notified) The following message is posted on the IM: The person at number xxxx you to leave a voicemail. Case 7: (the recipient has configured the SMS channel) The following message is sent via SMS: The person at the number xxxx you to leave a voice message. Case 11: (the recipient has configured an email address on which he wishes to be informed) The voice message is attached as an attachment to the email. The subject contains the platform informs you of the receipt of a voice message left by xxxxx Case 20: (The recipient is subscribed to a community platform) The voice message is transmitted to the platform as well as the entered Id at the end of the message. Issue by the platform When the platform sends a message to the ICU, it pre-processes the message for the different categories of existing flows. The ICU receives directly transmittable formatted data: Case 4: (the recipient has configured one or more IM channels on which he wishes to be informed) Text for the IM Case 8: (the recipient has configured the SMS channel) Text intended for when sending SMS Case 12: (The recipient has set up a mailbox) Voice message to be left on a voice mailbox Case 16: (the recipient has configured an email address on which he wishes to be informed) The whole mail is prepared: • Subject: • Attachments: • Body of the message: SERVICES: Overall, Goojet invents the concept of complementary widgets. That is to say that many services offered by Goojet include the notion of Ying and Yang application: two complementary goojets to offer a complete service (this is the case of the social signal for example, or for the restaurant reservation) .

  Social Signal: Principle: Social Picker and Social Reader are two complementary Goojets that aim to offer the functionality of "social presence". The Social Picker allows users to tell where they are, what they are doing, who they are with, how they are going, etc ... via the goojet portal. The social reader is an aggregator of all these flows. Each user will define who will be a member of their community and how they will follow status updates. Configuration: The social picker is a goojet that can be modulated by the user: he will choose on the portal what types of information, the category he wants to update and communicate when he is in a mobility situation. He can therefore choose between one and several categories (what, how, or etc ...). An appendix category will also allow him to enter a personalized text directly. After having selected the categories he wants for the social picker, the user will be able to configure this category by adding 1 to x actions, represented by an image (to choose from the bank of proposed actions or by uploading a personalized image). The configuration of the social reader is relatively simple: it is just a question of selecting the friends whose status will be visible and updated automatically. Use: to update its status, the user will simply pick or select in the social picker new elements that characterize it. He may therefore choose one or more categories to update. To update, he will just have to select the action icon. When he has finished updating the category or categories, he can validate and the information is sent. This information is updated and can be viewed in two different ways: - by going to the social picker of a user - by opening the social reader which then displays the last x updates of the profiles friends. In addition, this application can be interfaced with other types of web services since status information can be formatted (sentence form for example) and sent to third-party services (twitter). By the principle of picking information is therefore a very innovative way to update external microblogging tools available. Notes and Images are goojets that are part of the range of goojets "office" that can display content on the mobile.

  Their principle is basic but thanks to the Goojet architecture, ubiquity is at a maximum between the web and the mobile. The content can be modified at leisure on the web, it will be updated automatically on the mobile phone. Thanks to these Goojet instantaneous technical elements, there will be many uses (updates of shopping lists in real time by the person staying at home, collaborative work between a mobile person and another in front of a computer connected to the web etc. ...) To-do-list: To-do List is also part of the "office" range. This is to give the possibility to manage a list of tasks. Each task is represented by a box of the matrix and has several parameters: deadline, category, detail, title, person etc ... and finally a button to mark the task as performed or not. Agenda Goojet's calendar is also part of this desktop "mobile" category. It will be able to follow events and will be interfaced with other Goojets that will be able to insert information etc ... Thanks to the Goojet architecture, these goojets can be accessible directly via the agenda. The Goojet Agenda will be able to import and export information from ical-type usage standards etc ... Vote The Vote goojet allows the user to create a vote and promote it to his friends, to get their opinion on a subject. On the portal, it will be enough for him to select the question, as well as the answers (and the associated image-icons) and the goojet vote will be automatically created. The user will then be in charge of defining the voting audience, where it is public, to simply promote it by sending it to friends. Users who post the voting goojet on the mobile will be able to vote by simply selecting the answer. On the portal, additional possibilities will be offered concerning the results and the statistics of the vote: one will be able to follow the evolution of the scores in the time, to know the number of voters etc ... In a very easy way, the users will be able to so realize polls and get valuable information on friends, customers etc ... QCM The Goojet QCM is an extension of the vote goojet because it is to put in a row, any number of questions. Unlike the vote, however, the results will not be displayed on the mobile, but will only be available on the web (and only for the creator of the MCQ). But in the same way as for the vote, advanced tools on the web portal will allow the administration of the MCQ as well as the harvest and the interpretation of the results.

  Thanks to the Goojet architecture, users will be able, in a few moments, to create polls for mobiles which gives them a very interesting and instantaneous information gathering vector. Party Planner The Party Planner is a goojet that aims to facilitate the organization of events within a community. This is a folder that allows to create or visualize events For each event this includes: - the choice of the name - the choice of an audience (people able to see and act on the event) 15 - votes on the date, place, time. These are initial proposals by the initiator of the event but he can decide to accept or not the new proposals. - a list of tasks (things to do, things to take etc ...). The audience can add items or mark them as done - an information page 20 - the integration of a config tool! - a page of comments, to follow the evolutions This goojet is the first one which allows mobile users to organize themselves without having to go back and forth over the phone. This is the first time that a management tool, project management is proposed to 25 mobile users. On the portal, more advanced tools of administration and statistics will be proposed. Shared To-Do List The shared to-do list is the first service in the range of collaborative goojets 30 for project management uses, for office automation etc ... The shared to-do list is a to-do list which is modifiable by a group of people. This makes it possible to organize remotely during a set of tasks to be done etc ... Via this goojet, people will know who should do what and especially who did 35 what. Ask the community Principle: Tool of mutual help by questions / answers between users. When the user is traveling, in a situation of mobility, he may suddenly need information but he does not have access to the internet to search and find it. Via Goojet, he did not anticipate this need so he could not place the proper goojet in his space, and he does not remember a friend's goojet that would meet his need (and maybe not is there still no goojet associated with this need). Thanks to the goojet Ask the community, he will be able to send a question to the community and it will take care of finding the answer, since either the person will have the answer directly or it will have a web access that will allow him to search on the net. To put it simply, this goojet answers the question: I am in a situation of mobility, I need information but I had not planned so it is not (yet) in my Goojet. Thanks to Ask the community, people can search the info for me. To encourage people to respond, community tools will be put in place to promote the best profiles etc ... but the bottom line is that it is the micro-communities that respond. Configuration: on the mobile, the use of the goojet is relatively simple: it is to open a new question, which will be typed via the phone keypad and will be sent to the system. Several questions can be opened at the same time. On the other side, the community (or a micro-community) can activate to answer the question. The people (who chose who they wanted to receive requests and questions) have several to receive and answer questions from the goojet ask the community: via the web portal, via a desktop widget, via email, via instant messaging but also via a goojet response. Each time, the technical solution makes it possible to read the question, and to answer it. When the user has received a correct answer, he / she will be able to close the question and archive it, which will also be visible to the community, so that latecomers can not reply. Goojet becomes the first tool that connects an isolated person with a connected community. More in V2: the Goojet environment will keep track of these requests and will be able to make proposals for goojet creations based on the real requests of users. Goojets created by the person, the community or directly by Goojet developers will have a very good chance to meet a real need, and to please many users. The Goojet system will also be able to search to see if the question has not been asked already and if therefore the answer does not exist.

  Sudoku Sudoku is a relatively simple game. Goojet sends the 9 * 9 matrix and the user can then fill it at his own pace, in several times etc ... without any web access. Only when the user chooses to send the information is sent for verification etc. Poker Thanks to the collaborative possibilities offered by Goojet, it is possible to play asynchronous poker games. That is, the game will only continue when all participants have completed their action. A log will follow these actions.

  Inbox Inbox is a folder that includes two types of elements: - On the one hand the Goojets that have been sent and proposed by the community (community of friends, subscriptions to services, directly by Goojet etc ...) - d all other event logs from goojets. This inbox will allow you to receive all Goojets transactional application elements: This range of Goojet includes a number of services quite similar: Horoscope, TV Program, Cinema Program, weather forecast, RSS feeds etc ...

  Thanks to the Goojet architecture that allows to segment and profile the users of the service, it is possible to offer the content that will please the user, who will match it. By a filter system, it is therefore possible to offer only the content that the user really needs. The program cine or telly can be configured on the web portal by the user but they will then be proposed dynamically by Goojet according to the criteria defined, but also according to similarities detected by Goojet.

Claims (9)

  1 - A method for creating, organizing, delivering, operating and / or accessing services, characterized in that it comprises: a step of mapping services with a tree structure comprising, for each node, not more than nine branches leading, each, to another node of the tree or to a sheet, each sheet corresponding to a computer application, - a step of reception, by a server connected to a database of services, d a navigation request from a communicating mobile terminal and, iteratively: a step of providing, by the server to the mobile, identifiers of nodes or falling leaves of the same node, a selection step, by the mobile of one of said nodes or one of said sheets, - a step of communicating to the server of the selected node or sheet and - if a node has been selected, an iteration of the steps of supply, selection and communication and - s i a sheet has been selected, a launching step of the computer application corresponding to the selected sheet. 2 - Process according to claim 1, characterized in that, during the provisioning step, icons and / or texts associated with the descendant nodes corresponding to the provided identifier are displayed, on a screen of the communicating mobile terminal, in the form of 3x3 matrix corresponding to the nine digits 1 to 9 of a keyboard of the communicating mobile terminal, the selection step can be performed by the user by pressing the key bearing said corresponding number. 3 - Process according to claim 2, characterized in that, during the selection step, if the user presses on a first predetermined keyboard key different from the keys 1 to 9, the display on the screen of the terminal Communicating Mobile goes back and displays what was displayed an iterative cycle earlier. 4 - Process according to any one of claims 2 or 3, characterized in that, during the selection step, if the user presses on a second predetermined keyboard key different from the keys 1 to 9, the display on the screen of the communicating mobile terminal returns to the first iteration. 5. Process according to any one of claims 2 to 4, characterized in that, during the selection step, if the user presses on a third predetermined keyboard key different from the keys 1 to 9, the display on the screen of the communicating mobile terminal has explicit titles of the displayed nodes and sheets. 6. Process according to any one of claims 2 to 5, characterized in that, during the selection step, if the user makes a long press on a keyboard key among the keys 1 to 9, it opens context-sensitive help related to the node or sheet corresponding to said key on which is made a long press. 7 - Process according to any one of claims 1 to 6, characterized in that at least a portion of the computer applications corresponding to the leaves of the tree are among the following: download and / or display text, download and / or display a photo, download and / or play (streaming) a music file, download and / or play (streaming) a video file, trigger a phone call (with 1 or more people), trigger the sending of SMS (acronym for short message system for short message system) or MMS (acronym for multimedia message system for multimedia message system), trigger the sending of electronic messages, choose from one or more lists and transmit the choice to the support server, fill a form or form and then transmit it to the support server and invoke a predefined web service. 8 - Process according to any one of claims 1 to 7, characterized in that it comprises a step of personalization, by the user of the tree implemented in response 25 to navigation requests from his communicating mobile terminal . 9 - Process according to any one of claims 1 to 8, characterized in that it comprises a step of defining an explicit user profile, by said user, the behavior of at least one computer application associated with a leaf of the tree varying according to the explicit profile of the user. 10 - Device for creating, organizing, delivering, operating and / or accessing services, characterized in that it comprises: a service mapping means with a tree structure comprising: each node, at most nine branches leading, each, to another node of the tree or to a sheet, each sheet corresponding to a computer application, - means of reception, by a server connected to a database of services , a navigation request from a communicating mobile terminal 15 - a means for supplying, by the server to the mobile, identifiers of nodes or leaf descendants of the same node, - a selection means, by the mobile one of said nodes or one of said sheets, - means of communication to the server of the selected node or sheet and the supply, selection and communication means being adapted, if a node has been selected, to be carried out an iteration and - a means of launching the computer application corresponding to the selected sheet, if a sheet has been selected.