EP2286375A1 - Procédé et dispositif de gestion de ressources et support d'enregistrement pour ce procédé - Google Patents

Procédé et dispositif de gestion de ressources et support d'enregistrement pour ce procédé

Info

Publication number
EP2286375A1
EP2286375A1 EP09761899A EP09761899A EP2286375A1 EP 2286375 A1 EP2286375 A1 EP 2286375A1 EP 09761899 A EP09761899 A EP 09761899A EP 09761899 A EP09761899 A EP 09761899A EP 2286375 A1 EP2286375 A1 EP 2286375A1
Authority
EP
European Patent Office
Prior art keywords
card
address
resource
application
path
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP09761899A
Other languages
German (de)
English (en)
Inventor
Guillaume Dorbes
Cyril Hue
Claire Bazin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alcatel Lucent SAS
Original Assignee
Alcatel Lucent SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alcatel Lucent SAS filed Critical Alcatel Lucent SAS
Publication of EP2286375A1 publication Critical patent/EP2286375A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/60—Business processes related to postal services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/107—Computer-aided management of electronic mailing [e-mailing]

Definitions

  • the invention relates to a method and a device for managing resources and a recording medium for implementing this method.
  • the resources here are executable files stored in a memory of an electronic calculator or addresses allowing a computer application to contact a person or to access information.
  • the term "management method" denotes a method that makes it possible to classify and sort these resources according to predetermined criteria in order to enable a user to easily find one of these resources.
  • resource management methods include ordering and filtering resources based on predetermined criteria.
  • the cards in this address book are designed to contain the different possible addresses of a contact such as their phone numbers, e-mail addresses and postal addresses. This map is saved in a format specific to the application that will exploit it. For example, when a user wants to send an E-mail to a contact that he has selected in his address book, only the Outlook application can use the contents of the card to perform this task.
  • a resource management method comprising storing, in a memory of an electronic calculator, an instantiable model of a card intended to contain a description of a resource, this imposing card model, when its instantiation to create a new map, the acquisition of: • an identifier of the map to identify this map among all the maps already created, At least one path containing the address in the case where the resource is an address and a path in the case where the resource is an executable file, and
  • a reference domain for each path the reference domain specifying, in the case where the resource is an address, which is the computer application to be executed among several applications that may be specified by the reference domain for contact the person corresponding to this address or to access the information corresponding to this address.
  • the map template used here defines what application is to be executed in response to a user's selection of that map.
  • Embodiments of this method may include one or more of the following features: - the reference domain specifies, in the case where the resource is an executable file, that the resource described is an executable located in the location indicated by the access path ;
  • the method comprises creating a first and a second new map by instantiating the map model to describe, respectively, first and second addresses, the respective reference domains of said first and second addresses specifying, respectively, a first and a second computer applications, the first computer application being unable to contact the person or to access the information corresponding to the second address;
  • the instantiable model also makes it possible, during instantiation to create a new map, to freely define a name and a value of at least one label;
  • the instantiable model also makes it possible, when instantiating it to create a new card, to create a field intended to contain a link of the card created to another card to incorporate by reference the contents of this other card in the card created when the card is created. it is presented to a user; the instantiable model also allows, when instantiated to create a new map, the definition of a default reference domain when the map created contains several reference domains, the default reference domain specifying the computer application to be executed by defect in response to the selection of this card by a user; when creating a new map by instantiation of the model, the reference domain may specify a computer application to run selected from the group consisting of an application to make a phone call, an application to send an E-mail, an application for play an audio or video file, an application to display an Html page, and an application to display an RSS feed.
  • the invention also relates to an information recording medium containing instructions for executing the resource management method above when these instructions are executed by an electronic computer.
  • the subject of the invention is also a resource management device comprising an electronic memory containing an instantiable model of a card intended to contain a description of a resource, this imposing card model, during its instantiation to create a new map, the acquisition:
  • FIG. 1 is a schematic illustration of a telecommunication system incorporating a resource management device
  • FIG. 2 is a schematic illustration of an instantiable model of a card used in the resource management device of FIG. 1,
  • FIG. 3 is an illustration of several cards created by instantiation of the model of FIG. 2;
  • FIG. 4 is an illustration of another map created by instantiation of the model of FIG. 2, and
  • FIG. 5 is a flowchart of a resource management method using the device of FIG. 1.
  • FIG. 1 represents a telecommunication system 2 enabling users to contact other users or to access informations. For this purpose, these users use communication terminals.
  • the terminal 4 makes it possible to contact other persons via an information transmission network 6.
  • this network 6 comprises the Internet network.
  • the terminal 4 is able to establish a telephone call with a telephone 8 or send an e-mail to a computer station 10.
  • the terminal 4 is also able to access various information such as audio files recorded on a remote server 12 of audio files and Html pages recorded on a remote Internet server 14.
  • the terminal 4 is made using an electronic computer capable of executing instructions recorded on an information recording medium for implementing the method of FIG. 5.
  • the terminal 4 is a computer equipped with a central unit 20 connected to an electronic memory 22.
  • the central unit 20 is also connected to a man-machine interface comprising a screen 24 and a keyboard 26.
  • the central unit 20 comprises an electronic calculator 28 able to execute the instructions of computer applications recorded in the memory 22.
  • the memory 22 comprises executable files corresponding to the following computer applications: a telephone application 30 having a module for calling the telephone 8 and a module for sending an SMS message (Short Message Service) via the network 6,
  • a telephone application 30 having a module for calling the telephone 8 and a module for sending an SMS message (Short Message Service) via the network 6,
  • an application 32 capable of sending e-mails or e-mails to a recipient
  • an Internet browser capable of accessing information stored on Internet servers such as the server 14,
  • a computer application 36 having a module capable of playing music files, a module for playing video files and a module for displaying images stored in a local memory or on a remote file server such as the server 12.
  • the memory 22 also comprises instructions 38 necessary for the execution of the method of FIG. 5.
  • the combination of these instructions 38 and the computer 28 forms a resource management device implemented in the terminal 4.
  • the memory 22 also comprises the various pieces of information necessary for carrying out the method of FIG. 5.
  • the memory 22 comprises:
  • a list 46 of reference domain names a list 46 of default reference domain names, and a zone 50 for storing information relating to the terminal 4 and the users of the terminal 4.
  • Figure 2 shows an example of an instantiable card template 40.
  • This model includes: - a WCARD-ID field intended to contain a unique identifier making it possible to identify the card created among all the other cards already created,
  • an ADDRESS section intended to contain the access path to the resource as well as the reference domain associated with this resource; a WC ARD-DOM AIN field intended to indicate which is the reference domain by default when the card created comprises multiple paths, and
  • a TAG section intended to contain one or more labels.
  • the content of the WCARD-ID field is filled automatically when instantiating this template.
  • the WCARD-NAME field can either be filled manually by the user when creating a new map by instantiating this model or automatically from the contents of other fields in the model.
  • the ADDRESS section is intended to contain one or more paths.
  • the path is an address of a person to contact or information to access when the resource is an address. In the case where the resource is an executable file, the path corresponds to the path to this executable file.
  • the value of the path is saved in an ADDRESS-V ALUE field.
  • Each path is associated with a reference domain 60.
  • the reference domain 60 is defined using the fields ADDRESS-DOMAIN-NAME and ADDRESS-DOMAIN-SERVICE-LIST.
  • the ADDRESS-DOMAIN-NAME field is designed to contain the name of the reference domain. When instantiating the model 40, this name can only be chosen from the list 46. For example, here, the list 46 has the following names: - "TELECOM-PHONE" to indicate that the access path is here a phone number,
  • the ADDRESS-DOMAIN-SERVICE-LIST field contains a list of computer applications that can exploit the contents of the ADDRESS- VALUE field.
  • the contents of the ADDRESS-DOMAIN-SERVICE-LIST field depend on the contents of the ADDRESS-DOMAIN-NAME field.
  • the contents of the ADDRESS-DOMAIN-SERVICE-LIST field are defined using the following table:
  • the reference domain 60 defines what is the computer application or applications that must be executed to exploit the content of the field
  • ADDRESS-VALUE When several applications are possible, a message is displayed so that the user chooses himself between the various applications that may be executed.
  • PLAYER-PHONE and PLAYER-SMS-SEND correspond, respectively, to the modules able to make a telephone call and to send an SMS of the application 30.
  • the application “PLAYER-E-MAIL- SEND” corresponds to the application 32.
  • the application” PLAYER-WEB correlates to the application 34.
  • the application” PLAYER-RSS correlates to a particular module of the application 34 to subscribe and read RSS feeds.
  • PLAYER-MUSIC PLAYER-PICTURE
  • PLAYER-VIDEO PLAYER-VIDEO
  • This field makes it possible to discriminate between a path to an executable file and a path corresponding to an address. For example, this path includes the data "Y" when the path is a path to an executable file and the value "N" otherwise.
  • two additional ADDRESS-PLAYER-DEVICE and ADDRESS-PLAYER-SYNTAX fields must be completed.
  • the ADDRESS-PLAYER-DEVICE field indicates which operating system (s) on which the executable file can be run.
  • the ADDRESS-PLAYER-SYNTAX field describes the format of one or more parameters that must be passed to this application when it is executed. Typically, the parameter or parameters in question are contained in the ADRESS-VALUE field of a card.
  • the ADDRESS section can contain the description of one or more paths.
  • the WC ARD-DOMAIN field is used to define the path access to use by default when the map created by instantiation of the model 40 is selected by a user.
  • the content of this WCARD-DOMAIN field is for example chosen from a list 48.
  • this list 48 is identical to the list 46 except that it also includes the value "PERSON" which indicates that the card describes the address of a person.
  • the value "PERSON" indicates that the default application to use to reach this person is "PLAYER-PHONE".
  • the TAG section makes it possible to define one or more labels during an instantiation of the model 40.
  • these labels are intended to serve as search criteria for one or more created maps.
  • TAG-TYPE field indicating which type of label is defined
  • TAG-NAME field intended to contain the name of the label
  • TAG-VALUE field intended to contain the value of the label.
  • the model 40 is designed to require that the content of the TAG-TYPE field be chosen from a predetermined list.
  • this predetermined list contains the following three values "DOMAIN”, "SYSTEM”, and "USER".
  • the value of the TAG-TYPE field is "DOMAIN”
  • the value of the TAG-NAME field can only be chosen from the list 42.
  • the list 42 associates possible values for the TAG-NAME field according to the value contained in the WCARD-DOMAIN field.
  • the value of the WCARD-DOMAIN field is "PERSON”
  • the value of the TAG-NAME field should be chosen from the following list ⁇ "NAME”, “FIRST NAME”, “DATE OF BIRTH”, ... ⁇ .
  • the contents of the TAG-NAME field must be chosen from the following list ⁇ "ENCODING TYPE", “FILE TYPE”, ... ⁇ .
  • the content of the TAG-TYPE field is "SYSTEM"
  • it is a label whose name and value are automatically determined by the resource management device. For example, it may be a label to indicate which is the last revision date of the contents of the created map.
  • the contents of the TAG-TYPE field can be freely chosen by the user during the creation of a card by instantiation of the model 40.
  • the card model 40 therefore imposes the acquisition, during the creation of a card by instantiation of this model, of a certain number of fields.
  • FIG. 3 represents four examples of cards 70 to 73 created by instantiation of the model 40.
  • the card 70 describes a company whose name is "ATT".
  • the identifier of the card 70 is "WCARDl”.
  • the card 70 is devoid of an ADDRESS section. However, the WCARD-DOMAIN field has been filled with the value "PERSON”.
  • the card 70 has a label 76 used to define the mailing address of the company ATT. In the particular case shown in Figure 3, a label of the type "DOMAIN" was used to define the mailing address of this company.
  • the card 71 describes an image. This card has a WCARD2 identifier and a name "ATT logo" as well as a path to the file containing the image to display. The path is contained in the ADDRESS-V ALUE field. This path is associated with a reference domain defined by the value of the ADDRESS-DOMAIN-NAME and ADDRESS-SERVICE-LIST fields. Here, this reference domain indicates that the application to be executed to display this image is the "PLAYER-PICTURE" application.
  • the card 72 describes an audio file recorded on a remote server such as the server 12. This card here has the identifier "WCARD3" and the name "RING-MUSIC". This card also contains the path to the audio file on the server 12 as well as a reference domain.
  • the reference domain specifies that the application to be executed to listen to this audio file is the "PLA YER-MUSIC" application.
  • the user has freely defined a label whose name is “CLASS” and whose value is "C2". This label is a kind of annotation of the user to enable him to easily find the label 72.
  • the label 73 describes a person named "Tom". Some people can be contacted by phone or e-mail.
  • the card 73 therefore contains a first access path containing a telephone number and a second access path containing the e-mail address of this person.
  • Each of these paths is associated with a reference domain specifying which application to execute to contact that person either by phone or by e-mail.
  • the reference domain specifies that the applications to be run are "PLAYER-PHONE" and "PLAYER-SMS-SEND". Since two applications are likely to be executed, when the user tries to reach this person by using his phone number, a screen is displayed asking to choose between these two applications that may be executed to reach this person to using his phone number.
  • the reference domain specifies that the application to be executed is "PLAYER-E-MAIL-SEND".
  • the card 73 also has five labels. Two of these labels are used to define the last name and mailing address of this person. Note that the value of the label defining the mailing address is the identifier "WCARDl" of the card 70. Thus, in this case, the mailing address of this person is defined by reference to another card. In this case, when displaying information about this person, his address will be obtained from the contents of the card 70.
  • the other labels defined are freely defined tags by the user.
  • the user has defined a label whose name is "LOGO" and whose value includes a reference to the card 71 so that the description of the logo contained in the card 71 does not need to be included in the card 73.
  • Another label bears the name "RING" and the value of this tag includes a reference to the tag 72 so as not to have to incorporate into the card 73 the complete description of the audio file already included in the card 72.
  • the last label defined by the user has the name "CLASS” that is to say a name identical to that already used in the label 72.
  • the value of this label is also "C2" as in the label 72.
  • FIG. 4 represents an example of a map 80 created by instantiation of the model 40.
  • This map 80 describes an executable application that can be located in a memory using the path contained in the ADDRESS-VALUE field.
  • the reference domain indicates that it is an executable file.
  • the ADDRESS-DOMAIN-NAME field contains the value "FILE- APPLICATION”.
  • the value of the ADDRESS-PLAYER-STATUT field is equal to "Y".
  • the ADDRESS-PLAYER-DEVICE field indicates that the operating system on which this application is to be executed is the operating system "Windows-XP" ® and that no particular syntax of the parameter is required.
  • this card describes the application "PLA YER-PHONE" to be executed when the path of a card contains a telephone number.
  • a label freely defined by the user has been added to the contents of the card 80. This label has the name “CLASS” and has the value "C3".
  • the model 40 is stored in the memory 22 as well as the various applications and information necessary for the management of the cards. Then, during a step 92, the user creates cards by instantiation of the model 40. Each time a card is created, the template 40 defines the information and the format of the information that must be entered by the user.
  • the user can select one of these cards.
  • the application specified by the reference domain is executed. The content of the ADDRESS-
  • VALUE is passed as a parameter to this specific application to automatically launch the execution of a call or send an SMS message to the person to contact or to launch the presentation of the information to access.
  • the selected card describes an executable file
  • the execution of this executable file is automatically launched in response to the section of this card.
  • a step 96 of modifying and / or deleting a card In parallel with the steps of creation and selection of cards, the user can proceed, for example, to the following steps: a step 96 of modifying and / or deleting a card, and
  • a step 98 of searching for one or more cards is a step 98 of searching for one or more cards.
  • step 98 the cards are searched using criteria specified by the user such as the names and / or values of certain labels.
  • the terminal 4 may be a mobile phone or a personal assistant such as a PDA (Personal Digital Assistant) or any other communication terminal.
  • a PDA Personal Digital Assistant
  • model 40 The resources that can be described using model 40 are not limited to the examples given in the preceding description.
  • video files, documents or the like can also be described by a map obtained by instantiating the model 40.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Tourism & Hospitality (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Ce procédé de gestion de ressources comprend : la mémorisation (90) d'un modèle instanciable d'une carte destinée à contenir une description d'une ressource, ce modèle de carte imposant, lors de son instanciation pour créer une nouvelle carte, l'acquisition : d'un identifiant de la carte; d'au moins un chemin d'accès contenant une adresse; et d'un domaine de référence pour chaque chemin d'accès, le domaine de référence spécifiant, dans le cas où la ressource est une adresse, quelle est l'application informatique à exécuter parmi plusieurs applications susceptibles d'être spécifiées par le domaine de référence pour contacter la personne correspondant à cette adresse ou pour accéder à l'information correspondant à cette adresse.

Description

PROCEDE ET DISPOSITIF DE GESTION DE RESSOURCES ET SUPPORT D'ENREGISTREMENT POUR CE PROCEDE
L'invention concerne un procédé et un dispositif de gestion de ressources et un support d'enregistrement pour la mise en œuvre de ce procédé.
Les ressources sont ici des fichiers exécutables stockés dans une mémoire d'un calculateur électronique ou des adresses permettant à une application informatique de contacter une personne ou d'accéder à une information. Par procédé de gestion, on désigne un procédé qui permet de classer et de trier ces ressources selon des critères prédéterminés pour permettre à un utilisateur de retrouver facilement l'une de ces ressources. Par exemple, les procédés de gestion de ressources permettent notamment d'ordonner et de filtrer les ressources en fonction de critères prédéterminés. II existe des procédés de gestion d'adresses de personnes. Ces procédés sont également appelés procédés de gestion de carnet d'adresses. Par exemple, un tel procédé existe dans l'application Outlook de Microsoft ®. Les cartes de ce carnet d'adresses sont conçues pour contenir les différentes adresses possibles d'un contact tel que ses numéros de téléphone, ses adresses E-mail et son adresse postale. Cette carte est enregistrée dans un format spécifique à l'application qui doit l'exploiter. Ainsi, par exemple, lorsqu'un utilisateur souhaite envoyer un E-mail à un contact qu'il a sélectionné dans son carnet d'adresses, seule l'application Outlook peut exploiter le contenu de la carte pour effectuer cette tâche.
Il existe également de nombreux autres procédés de gestion d'autres ressources. Par exemple, les navigateurs Internet permettent de gérer des adresses vers des pages Web ou HTML (Hyper Text Markup Language). Ces procédés sont plus connus sous le terme de gestion des favoris. D'autres applications permettent de gérer des fichiers d'images, d'audio ou de vidéo. Toutefois, ces différents procédés de gestion sont incompatibles entre eux. Par exemple, un procédé de gestion d'un carnet d'adresses ne peut pas en plus gérer des raccourcis vers des pages Web ou des images ou des fichiers audio ou vidéo.
Il est cependant souhaitable de disposer d'un procédé de gestion de ressources permettant de gérer différents types de ressources et ceci quelle que soit l'application informatique à exécuter pour exploiter ces ressources. L'invention vise à satisfaire ce souhait. Elle a donc pour objet un procédé de gestion de ressources comprenant la mémorisation, dans une mémoire d'un calculateur électronique, d'un modèle instanciable d'une carte destinée à contenir une description d'une ressource, ce modèle de carte imposant, lors de son instanciation pour créer une nouvelle carte, l'acquisition : • d'un identifiant de la carte permettant d'identifier cette carte parmi l'ensemble des cartes déjà créées, • d'au moins un chemin d'accès contenant l'adresse dans le cas où la ressource est une adresse et un chemin d'accès dans le cas où la ressource est un fichier exécutable, et
• un domaine de référence pour chaque chemin d'accès, le domaine de référence spécifiant, dans le cas où la ressource est une adresse, quelle est l'application informatique à exécuter parmi plusieurs applications susceptibles d'être spécifiées par le domaine de référence pour contacter la personne correspondant à cette adresse ou pour accéder à l'information correspondant à cette adresse. Le modèle de carte utilisé ici permet de définir quelle est l'application qui doit être exécutée en réponse à la sélection de cette carte par un utilisateur. Ainsi, ce procédé de gestion de ressources permet de gérer avec un même modèle de carte des adresses uniquement utilisables par des applications informatiques différentes. Il devient donc possible d'utiliser un même gestionnaire de ressources pour gérer des adresses aussi diverses que des raccourcis vers des pages Web, des chemins d'accès à des fichiers vidéo ou audio, des adresses E-mail ou postales d'une personne, des numéros de téléphone de personnes, ... etc.
Les modes de réalisation de ce procédé peuvent comporter une ou plusieurs des caractéristiques suivantes : - le domaine de référence spécifie, dans le cas où la ressource est un fichier exécutable, que la ressource décrite est un fichier exécutable localisé à l'emplacement indiqué par le chemin d'accès ;
- le procédé comprend la création d'une première et d'une seconde nouvelles cartes par instanciation du modèle de carte pour décrire, respectivement, une première et une seconde adresses, les domaines de référence respectifs de ces première et seconde adresses spécifiant, respectivement, une première et une seconde applications informatiques, la première application informatique étant incapable de contacter la personne ou d'accéder à l'information correspondant à la seconde adresse ; le modèle instanciable permet également, lors de instanciation pour créer une nouvelle carte, de définir librement un nom et une valeur d'au moins une étiquette ;
- le modèle instanciable permet également, lors de son instanciation pour créer une nouvelle carte, de créer un champ destiné à contenir un lien de la carte créée vers une autre carte pour incorporer par référence le contenu de cette autre carte dans la carte créée lorsque celle-ci est présentée à un utilisateur ; le modèle instanciable permet également, lors de son instanciation pour créer une nouvelle carte, la définition d'un domaine de référence par défaut lorsque la carte créée contient plusieurs domaines de référence, le domaine de référence par défaut spécifiant l'application informatique à exécuter par défaut en réponse à la sélection de cette carte par un utilisateur ; lors de la création d'une nouvelle carte par instanciation du modèle, le domaine de référence peut spécifier une application informatique à exécuter choisie dans le groupe comprenant une application pour passer un appel téléphonique, une application pour envoyer un E-mail, une application pour jouer un fichier audio ou vidéo, une application pour afficher une page Html, et une application pour afficher un flux RSS. Ces modes de réalisation du procédé de gestion présentent en outre les avantages suivants :
- avoir un modèle de carte qui permet également de décrire des fichiers exécutables d'une application informatique permet d'adapter facilement le procédé de gestion à tout type de ressources,
- avoir un modèle instanciable qui permet à l'utilisateur de définir librement le nom et la valeur d'une étiquette, et ceci quelle que soit la ressource décrite par la carte permet ensuite de définir des critères de recherche communs permettant de sélectionner différents types de ressources exploitables par des applications informatiques incompatibles entre elles,
- avoir un modèle instanciable qui permet d'incorporer par référence le contenu d'autres cartes évite de dupliquer les informations, ce qui en fin de compte limite la taille de l'espace de stockage nécessaire pour stocker les cartes créées,
- avoir un modèle instanciable qui permet de définir un domaine de référence par défaut permet de simplifier l'utilisation de ces cartes.
L'invention a également pour objet un support d'enregistrement d'informations contenant des instructions pour l'exécution du procédé de gestion de ressources ci- dessus lorsque ces instructions sont exécutées par un calculateur électronique.
Enfin, l'invention a également pour objet un dispositif de gestion de ressources comprenant une mémoire électronique contenant un modèle instanciable d'une carte destinée à contenir une description d'une ressource, ce modèle de carte imposant, lors de son instanciation pour créer une nouvelle carte, l'acquisition :
• d'un identifiant de la carte permettant d'identifier cette carte parmi l'ensemble des cartes déjà créées,
• d'au moins un chemin d'accès contenant l'adresse dans le cas où la ressource est une adresse et un chemin d'accès dans le cas où la ressource est un fichier exécutable, et • un domaine de référence pour chaque chemin d'accès, le domaine de référence spécifiant, dans le cas où la ressource est une adresse, quelle est l'application informatique à exécuter parmi plusieurs applications susceptibles d'être spécifiées par le domaine de référence pour contacter la personne correspondant à cette adresse ou pour accéder à l'information correspondant à cette adresse.
L'invention sera mieux comprise à la lecture de la description qui va suivre donnée uniquement à titre d'exemple non limitatif et faite en se référant aux dessins sur lesquels : - la figure 1 est une illustration schématique d'un système de télécommunication incorporant un dispositif de gestion de ressources,
- la figure 2 est une illustration schématique d'un modèle instanciable d'une carte utilisée dans le dispositif de gestion de ressources de la figure 1 ,
- la figure 3 est une illustration de plusieurs cartes créées par instanciation du modèle de la figure 2 ;
- la figure 4 est une illustration d'une autre carte créée par instanciation du modèle de la figure 2, et
- la figure 5 est un organigramme d'un procédé de gestion de ressources à l'aide du dispositif de la figure 1. La figure 1 représente un système 2 de télécommunication permettant à des utilisateurs de contacter d'autres utilisateurs ou d'accéder à des informations. A cet effet, ces utilisateurs utilisent des terminaux de communication.
Pour simplifier la figure 1, seul un terminal 4 de communication a été représenté. Les principales caractéristiques des autres terminaux de communication peuvent être déduites de la description qui sera faite du terminal 4.
Le terminal 4 permet de contacter d'autres personnes par l'intermédiaire d'un réseau 6 de transmission d'informations. Par exemple, ce réseau 6 comprend le réseau Internet.
Ici, le terminal 4 est capable d'établir un appel téléphonique avec un téléphone 8 ou d'envoyer un E-mail vers un poste informatique 10.
Le terminal 4 est également apte à accéder à différentes informations telles que des fichiers audio enregistrés sur un serveur 12 distant de fichiers audio et à des pages Html enregistrées sur un serveur Internet distant 14.
Le terminal 4 est réalisé à l'aide d'un calculateur électronique apte à exécuter des instructions enregistrées sur un support d'enregistrement d'informations pour mettre en œuvre le procédé de la figure 5. Dans le cas particulier décrit ici, le terminal 4 est un ordinateur équipé d'une unité centrale 20 raccordée à une mémoire électronique 22. L'unité centrale 20 est également raccordée à une interface homme-machine comprenant un écran 24 et un clavier 26. Par exemple, l'unité centrale 20 comprend un calculateur électronique 28 apte à exécuter les instructions d'applications informatiques enregistrées dans la mémoire 22.
Ici, la mémoire 22 comprend des fichiers exécutables correspondant aux applications informatiques suivantes : - une application téléphonique 30 ayant un module pour appeler le téléphone 8 et un module pour envoyer un message SMS (Short Message Service) par l'intermédiaire du réseau 6,
- une application 32 capable d'envoyer des E-mail ou courriers électroniques vers un destinataire, - un navigateur Internet 34 capable d'accéder à des informations enregistrées sur des serveurs Internet tels que le serveur 14,
- une application informatique 36 ayant un module capable de jouer des fichiers musicaux, un module pour jouer des fichiers vidéo et un module pour afficher des images enregistrés dans une mémoire locale ou sur un serveur distant de fichiers tel que le serveur 12.
La mémoire 22 comprend également des instructions 38 nécessaires à l'exécution du procédé de la figure 5. Ainsi, l'association de ces instructions 38 et du calculateur 28 forme un dispositif de gestion de ressources implémenté dans le terminal 4.
Enfin, la mémoire 22 comporte également les différentes informations nécessaires à l'exécution du procédé de la figure 5. En particulier, la mémoire 22 comprend :
- un modèle 40 instanciable de carte,
- une liste 42 de noms d'étiquette,
- une liste 46 de noms de domaine de référence, - une liste 48 de noms de domaine de référence par défaut, et une zone 50 de stockage d'informations relatives au terminal 4 et aux utilisateurs du terminal 4.
La figure 2 représente un exemple de modèle instanciable 40 de carte. Ce modèle comporte : - un champ WCARD-ID destiné à contenir un identifiant unique permettant d'identifier la carte créée parmi l'ensemble des autres cartes déjà créées,
- un champ WCARD-NAME destiné à contenir le nom de la carte,
- une section ADDRESS destinée à contenir le chemin d'accès à la ressource ainsi que le domaine de référence associé à cette ressource, - un champ WC ARD-DOM AIN destiné à indiquer quel est le domaine de référence par défaut lorsque la carte créée comporte plusieurs chemins d'accès, et
- une section TAG destinée à contenir une ou plusieurs étiquettes. Typiquement, le contenu du champ WCARD-ID est rempli automatiquement lors de l'instanciation de ce modèle. Le champ WCARD-NAME peut être soit rempli manuellement par l'utilisateur lors de la création d'une nouvelle carte par instanciation de ce modèle soit automatiquement à partir du contenu d'autres champs du modèle.
La section ADDRESS est destinée à contenir un ou plusieurs chemins d'accès. Le chemin d'accès est une adresse d'une personne à contacter ou d'une information à accéder lorsque la ressource est une adresse. Dans le cas où la ressource est un fichier exécutable, le chemin d'accès correspond au chemin d'accès à ce fichier exécutable. La valeur du chemin d'accès est enregistrée dans un champ ADDRESS-V ALUE. Chaque chemin d'accès est associé à un domaine de référence 60. Ici, le domaine de référence 60 est défini à l'aide des champs ADDRESS-DOMAIN-NAME et ADDRESS-DOMAIN- SERVICE-LIST. Le champ ADDRESS-DOMAIN-NAME est conçu pour contenir le nom du domaine de référence. Lors de l' instanciation du modèle 40, ce nom peut uniquement être choisi dans la liste 46. Par exemple, ici, la liste 46 comporte les noms suivants : - « TELECOM-PHONE » pour indiquer que le chemin d'accès est ici un numéro de téléphone,
- « INTERNET-E-MAIL » pour indiquer que le contenu du chemin d'accès est une adresse E-mail,
- « INTERNET- WEB » pour indiquer que le chemin d'accès est une URL (Uniform Ressource Locator) d'une page Html,
- « INTERNET-RSS » pour indiquer que le chemin d'accès correspond à un flux RSS (« Reach Site Summary » ou « RDF Site Summary » ou « Really Simple Syndication »),
- « FILE-MUSIC » pour indiquer que le chemin d'accès est un chemin d'accès à un fichier audio,
- « FILE-PICTURE » pour indiquer que le chemin d'accès est un chemin d'accès à un fichier contenant une image, et
- « FILE-APPLICATION » pour indiquer que le chemin d'accès est un chemin d'accès à un fichier exécutable d'une application informatique. Le champ ADDRESS-DOMAIN-SERVICE-LIST contient une liste des applications informatiques susceptibles d'exploiter le contenu du champ ADDRESS- VALUE. Ici, le contenu du champ ADDRESS-DOMAIN-SERVICE-LIST est fonction du contenu du champ ADDRESS-DOMAIN-NAME. Par exemple, le contenu du champ ADDRESS-DOMAIN-SERVICE-LIST est défini à l'aide du tableau suivant :
Ainsi, le domaine de référence 60 définit quelle est la ou les applications informatiques qui doivent être exécutées pour exploiter le contenu du champ
ADDRESS-VALUE. Lorsque plusieurs applications sont possibles, un message s'affiche pour que l'utilisateur choisisse lui-même entre les différentes applications susceptibles d'être exécutées.
Ici les applications « PLAYER-PHONE » et « PLAYER-SMS-SEND » correspondent, respectivement, aux modules capables de passer un appel téléphonique et d'envoyer un SMS de l'application 30. L'application « PLAYER-E-MAIL-SEND » correspond à l'application 32. L'application « PLAYER-WEB » correspond à l'application 34. L'application « PLAYER-RSS » correspond à un module particulier de l'application 34 permettant de s'abonner et de lire des flux RSS. Les applications
« PLAYER-MUSIC », « PLAYER-PICTURE » et « PLAYER- VIDEO » correspondent à des modules respectifs de l'application 36. Chaque chemin d'accès est également associé à un champ ADDRESS-PLA YER-
STATUT. Le contenu de ce champ permet de discriminer entre un chemin d'accès à un fichier exécutable et un chemin d'accès correspondant à une adresse. Par exemple, ce chemin d'accès comprend la donnée « Y » lorsque le chemin d'accès est un chemin d'accès à un fichier exécutable et la valeur « N » dans le cas contraire. Lorsque le chemin d'accès est un chemin d'accès à un fichier exécutable, deux champs supplémentaires ADDRESS-PLAYER-DEVICE et ADDRESS-PLAYER- SYNTAX doivent être complétés. Le champ ADDRESS-PLAYER-DEVICE indique quel est ou quels sont les systèmes d'exploitation sur lesquels le fichier exécutable peut être exécuté. Le champ ADDRESS-PLAYER-SYNTAX décrit le format d'un ou plusieurs paramètres qui doivent être transmis à cette application lorsque celle-ci est exécutée. Typiquement, le ou les paramètres en question sont contenus dans le champs ADRESS- VALUE d'une carte.
La section ADDRESS peut contenir la description d'un ou plusieurs chemins d'accès. Dans le cas où la section ADDRESS contient la description de plusieurs chemins d'accès, le champ WC ARD-DOMAIN permet de définir quel est le chemin d'accès à utiliser par défaut lorsque la carte créée par instanciation du modèle 40 est sélectionnée par un utilisateur. Ici, le contenu de ce champ WCARD-DOMAIN est par exemple choisi dans une liste 48. Pour simplifier, ici, cette liste 48 est identique à la liste 46 à l'exception du fait qu'elle comporte en plus la valeur « PERSON » qui permet d'indiquer que la carte décrit l'adresse d'une personne. Ici, la valeur « PERSON » indique que l'application par défaut à utiliser pour joindre cette personne est « PLAYER-PHONE ».
La section TAG permet de définir lors d'une instanciation du modèle 40 une ou plusieurs étiquettes. Par exemple, ces étiquettes sont destinées à servir de critères de recherche d'une ou plusieurs cartes créées.
Ici, chaque étiquette est définie à l'aide des champs suivants :
- un champ TAG-TYPE indiquant quel est le type d'étiquette défini,
- un champ TAG-NAME destiné à contenir le nom de l'étiquette, et
- un champ TAG-VALUE destiné à contenir la valeur de l'étiquette. Ici, le modèle 40 est conçu pour imposer que le contenu du champ TAG-TYPE soit choisi dans une liste prédéterminée. Par exemple, cette liste prédéterminée contient les trois valeurs suivantes « DOMAIN », « SYSTEM », et « USER ». Lorsque la valeur du champ TAG-TYPE est « DOMAIN », alors la valeur du champ TAG-NAME peut uniquement être choisie dans la liste 42. Ici, la liste 42 associe des valeurs possibles pour le champ TAG-NAME en fonction de la valeur contenue dans le champ WCARD- DOMAIN. Par exemple, si la valeur du champ WCARD-DOMAIN est « PERSON », alors la valeur du champ TAG-NAME doit être choisie dans la liste suivante {« NOM », « PRENOM », « DATE DE NAISSANCE », ...}.
Dans le cas où le champ WCARD-DOMAIN contient la valeur « FILE- MUSIC », alors le contenu du champ TAG-NAME doit être choisi dans la liste suivante {« TYPE D'ENCODAGE », « TYPE DE FICHIER », ...}.
Si le contenu du champ TAG-TYPE est « SYSTEM », alors il s'agit d'une étiquette dont le nom et la valeur sont automatiquement déterminés par le dispositif de gestion de ressources. Par exemple, il peut s'agir d'une étiquette pour indiquer quelle est la dernière date de révision du contenu de la carte créée.
Enfin, si le contenu du champ TAG-TYPE est « USER », alors le contenu des champs TAG-NAME et TAG-VALUE peut être librement choisi par l'utilisateur lors de la création d'une carte par instanciation du modèle 40.
Le modèle 40 de carte impose donc l'acquisition, lors de la création d'une carte par instanciation de ce modèle, d'un certain nombre de champs.
La figure 3 représente quatre exemples de cartes 70 à 73 créées par instanciation du modèle 40. La carte 70 décrit une société dont le nom est « ATT ». L'identifiant de la carte 70 est « WCARDl ». La carte 70 est dépourvue d'une section ADDRESS. Par contre, le champ WCARD-DOMAIN a été rempli avec la valeur « PERSON ». La carte 70 comporte une étiquette 76 utilisée pour définir l'adresse postale de la société ATT. Dans le cas particulier représenté sur la figure 3, une étiquette du type « DOMAIN » a été utilisée pour définir l'adresse postale de cette société.
La carte 71 décrit une image. Cette carte comporte un identifiant WCARD2 et un nom « ATT logo» ainsi qu'un chemin d'accès au fichier contenant l'image à afficher. Le chemin d'accès est contenu dans le champ ADDRESS-V ALUE. Ce chemin d'accès est associé à un domaine de référence défini par la valeur des champs ADDRESS- DOMAIN-NAME et ADDRESS-SERVICE-LIST. Ici, ce domaine de référence indique que l'application à exécuter pour afficher cette image est l'application « PLAYER- PICTURE ». La carte 72 décrit un fichier audio enregistré sur un serveur distant tel que le serveur 12. Cette carte porte ici l'identifiant « WCARD3 » et le nom « RING-MUSIC ». Cette carte contient également le chemin d'accès au fichier audio sur le serveur 12 ainsi qu'un domaine de référence. Ici, le domaine de référence spécifie que l'application à exécuter pour écouter ce fichier audio est l'application « PLA YER-MUSIC ». De plus, l'utilisateur a librement défini une étiquette dont le nom est « CLASS » et dont la valeur est « C2 ». Cette étiquette est en quelques sortes une annotation de l'utilisateur destiné à lui permettre de retrouver facilement l'étiquette 72.
L'étiquette 73 décrit quant à elle une personne nommée « Tom ». Certaines personnes peuvent être contactées par téléphone ou par E-mail. La carte 73 contient donc un premier chemin d'accès contenant un numéro de téléphone et un deuxième chemin d'accès contenant l'adresse E-mail de cette personne. Chacun de ces chemins d'accès est associé à un domaine de référence spécifiant quelle est l'application à exécuter pour contacter cette personne soit par téléphone soit par E-mail. Plus précisément, lorsque le chemin d'accès contient un numéro de téléphone, le domaine de référence précise que les applications à exécuter sont « PLAYER-PHONE » et « PLAYER-SMS-SEND ». Etant donné que deux applications sont susceptibles d'être exécutées, lorsque l'utilisateur cherche à joindre cette personne en utilisant son numéro de téléphone, un écran est affiché pour demander de choisir entre ces deux applications susceptibles d'être exécutées pour joindre cette personne à l'aide de son numéro de téléphone. Dans le cas de l'adresse E-mail, le domaine de référence spécifie que l'application à exécuter est « PLAYER-E-MAIL-SEND ».
Enfin, la carte 73 comporte également cinq étiquettes. Deux de ces étiquettes sont utilisées pour définir le nom de famille et l'adresse postale de cette personne. On remarquera que la valeur de l'étiquette définissant l'adresse postale est l'identifiant « WCARDl » de la carte 70. Ainsi, dans ce cas précis, l'adresse postale de cette personne est définie par référence à une autre carte. Dans ce cas, lors de l'affichage des informations concernant cette personne, son adresse sera obtenue à partir du contenu de la carte 70.
Les autres étiquettes définies sont des étiquettes librement définies par l'utilisateur. Ici, l'utilisateur a défini une étiquette dont le nom est « LOGO » et dont la valeur comporte une référence à la carte 71 de sorte que la description du logo contenu dans la carte 71 n'a pas besoin d'être reprise dans la carte 73.
Une autre étiquette porte le nom « RING » et la valeur de cette étiquette comporte une référence à l'étiquette 72 de manière à ne pas avoir à incorporer dans la carte 73 la description complète du fichier audio déjà incluse dans la carte 72.
Enfin, la dernière étiquette définie par l'utilisateur porte le nom « CLASS » c'est- à-dire un nom identique à celui déjà utilisé dans l'étiquette 72. De plus, la valeur de cette étiquette est également « C2 » comme dans l'étiquette 72. Ainsi, si l'utilisateur recherche des cartes contenant une étiquette dont le nom est « CLASS » et dont la valeur est « C2 », il retrouvera au moins les étiquettes 72 et 73. Ainsi, l'utilisateur arrive à sélectionner et à gérer des cartes décrivant des ressources de types totalement différents.
La figure 4 représente un exemple d'une carte 80 créée par instanciation du modèle 40. Cette carte 80 décrit une application exécutable qui peut être localisée dans une mémoire à l'aide du chemin d'accès contenu dans le champ ADDRESS- VALUE. Dans ce cas, le domaine de référence indique qu'il s'agit d'un fichier exécutable. A cet effet, le champ ADDRESS-DOMAIN-NAME contient la valeur « FILE- APPLICATION ». De plus la valeur du champ ADDRESS-PLAYER-STATUT est égale à « Y». Ici, le champ ADDRESS-PLAYER-DEVICE indique que le système d'exploitation sur lequel doit être exécutée cette application est le système d'exploitation « Windows-XP » ® et qu'aucune syntaxe particulière du paramètre n'est exigée.
Ici, le nom de cette carte est « PLA YER-PHONE ». Ainsi, cette carte décrit l'application « PLA YER-PHONE » à exécuter lorsque le chemin d'accès d'une carte contient un numéro de téléphone. A titre d'illustration, une étiquette librement définie par l'utilisateur a été ajoutée au contenu de la carte 80. Cette étiquette porte le nom « CLASS » et a la valeur « C3 ».
Le fonctionnement du système 2 va maintenant être décrit plus en détail en regard du procédé de la figure 5.
Initialement, lors d'une étape 90, le modèle 40 est enregistré dans la mémoire 22 ainsi que les différentes applications et informations nécessaires pour la gestion des cartes. Ensuite, lors d'une étape 92, l'utilisateur crée des cartes par instanciation du modèle 40. Lors de chaque création d'une carte, le modèle 40 définit les informations et le format des informations qui doivent être saisies par l'utilisateur.
Une fois que plusieurs cartes ont été créées, lors d'une étape 94, l'utilisateur peut sélectionner l'une de ces cartes. En réponse à la sélection d'une carte décrivant une adresse pour contacter une personne ou pour accéder à une information, l'application spécifiée par le domaine de référence est exécutée. Le contenu du champ ADDRESS-
VALUE est transmis en tant que paramètre à cette application spécifique pour lancer automatiquement l'exécution d'un appel ou l'envoi d'un message SMS vers la personne à contacter ou pour lancer la présentation de l'information à accéder. Dans le cas où la carte sélectionnée décrit un fichier exécutable, l'exécution de ce fichier exécutable est automatiquement lancée en réponse à la section de cette carte.
En parallèle des étapes de création et de sélection de cartes, l'utilisateur peut procéder, par exemple, aux étapes suivantes : - une étape 96 de modification et/ou de suppression d'une carte, et
- une étape 98 de recherche d'une ou plusieurs cartes.
Lors de l'étape 98, les cartes sont recherchées à l'aide de critères spécifiés par l'utilisateur comme par exemple les noms et/ou valeurs de certaines étiquettes.
On comprend donc que grâce au modèle 40, il est possible de gérer des ressources quelconques à l'aide d'une même application.
De nombreux autres modes de réalisation sont possibles. Par exemple, le terminal 4 peut être un téléphone mobile ou un assistant personnel tel qu'un PDA (Personnal Digital Assistant) ou tout autre terminal de communication.
Les ressources susceptibles d'être décrites à l'aide du modèle 40 ne sont pas limitées aux exemples donnés dans la description précédente. Par exemple, des fichiers vidéo, des documents ou autres peuvent également être décrits par une carte obtenue en instanciant le modèle 40.
De même, les différentes listes 42, 46 et 48 peuvent être complétées ou modifiées comme désiré.

Claims

REVENDICATIONS
1. Procédé de gestion de ressources, ces ressources étant des fichiers exécutables stockés dans une mémoire électronique ou des adresses permettant à une application informatique de contacter une personne ou d'accéder à une information, caractérisé en ce que ce procédé comprend :
- la mémorisation (90), dans une mémoire d'un calculateur électronique, d'un modèle instanciable d'une carte destinée à contenir une description d'une ressource, ce modèle de carte imposant, lors de son instanciation pour créer une nouvelle carte, l'acquisition :
• d'un identifiant de la carte permettant d'identifier cette carte parmi l'ensemble des cartes déjà créées,
• d'au moins un chemin d'accès (ADDRES S-VALUE) contenant l'adresse dans le cas où la ressource est une adresse et un chemin d'accès dans le cas où la ressource est un fichier exécutable, et
• un domaine de référence (60) pour chaque chemin d'accès, le domaine de référence spécifiant, dans le cas où la ressource est une adresse, quelle est l'application informatique à exécuter parmi plusieurs applications susceptibles d'être spécifiées par le domaine de référence pour contacter la personne correspondant à cette adresse ou pour accéder à l'information correspondant à cette adresse.
2. Procédé selon la revendication 1, dans lequel le domaine de référence (60) spécifie, dans le cas où la ressource est un fichier exécutable, que la ressource décrite est un fichier exécutable localisé à l'emplacement indiqué par le chemin d'accès.
3. Procédé selon l'une quelconque des revendications précédentes, dans lequel le procédé comprend la création (92) d'une première et d'une seconde nouvelles cartes par instanciation du modèle de carte pour décrire, respectivement, une première et une seconde adresses, les domaines de référence respectifs de ces première et seconde adresses spécifiant, respectivement, une première et une seconde applications informatiques, la première application informatique étant incapable de contacter la personne ou d'accéder à l'information correspondant à la seconde adresse.
4. Procédé selon l'une quelconque des revendications précédentes, dans lequel le modèle instanciable permet également, lors de instanciation pour créer une nouvelle carte, de définir librement un nom et une valeur d'au moins une étiquette (TAG).
5. Procédé selon l'une quelconque des revendications précédentes, dans lequel le modèle instanciable permet également, lors de son instanciation pour créer une nouvelle carte, de créer un champ destiné à contenir un lien de la carte créée vers une autre carte pour incorporer par référence le contenu de cette autre carte dans la carte créée lorsque celle-ci est présentée à un utilisateur.
6. Procédé selon l'une quelconque des revendications précédentes, dans lequel le modèle instanciable permet également, lors de son instanciation pour créer une nouvelle carte, la définition d'un domaine de référence par défaut (WCARD-DOMAIN) lorsque la carte créée contient plusieurs domaines de référence, le domaine de référence par défaut spécifiant l'application informatique à exécuter par défaut en réponse à la sélection de cette carte par un utilisateur.
7. Procédé selon l'une quelconque des revendications précédentes, dans lequel lors de la création d'une nouvelle carte par instanciation du modèle, le domaine de référence peut spécifier une application informatique à exécuter choisie dans le groupe comprenant une application pour passer un appel téléphonique, une application pour envoyer un E-mail, une application pour jouer un fichier audio ou vidéo, une application pour afficher une page Html, et une application pour afficher un flux RSS.
8. Support (22) d'enregistrement d'informations, caractérisé en ce qu'il comporte des instructions pour l'exécution d'un procédé de gestion conforme à l'une quelconques des revendications précédentes, lorsque ces instructions sont exécutées par un calculateur électronique.
9. Dispositif de gestion de ressources, ces ressources étant des fichiers exécutables stockés dans une mémoire électronique ou une adresse permettant à une application informatique de contacter une personne ou d'accéder à une information, caractérisé en ce que ce dispositif comprend une mémoire électronique (22) contenant un modèle instanciable d'une carte destinée à contenir une description d'une ressource, ce modèle de carte imposant, lors de son instanciation pour créer une nouvelle carte, l'acquisition :
• d'un identifiant de la carte permettant d'identifier cette carte parmi l'ensemble des cartes déjà créées, • d'au moins un chemin d'accès (ADDRES S-VALUE) contenant l'adresse dans le cas où la ressource est une adresse et un chemin d'accès dans le cas où la ressource est un fichier exécutable, et
• un domaine de référence (60) pour chaque chemin d'accès, le domaine de référence spécifiant, dans le cas où la ressource est une adresse, quelle est l'application informatique à exécuter parmi plusieurs applications susceptibles d'être spécifiées par le domaine de référence pour contacter la personne correspondant à cette adresse ou pour accéder à l'information correspondant à cette adresse.
EP09761899A 2008-05-15 2009-05-14 Procédé et dispositif de gestion de ressources et support d'enregistrement pour ce procédé Withdrawn EP2286375A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0802626A FR2931267B1 (fr) 2008-05-15 2008-05-15 Procede et dispositif de gestion de ressources et support d'enregistrement pour ce procede
PCT/FR2009/050901 WO2009150348A1 (fr) 2008-05-15 2009-05-14 Procede et dispositif de gestion de ressources et support d'enregistrement pour ce procede

Publications (1)

Publication Number Publication Date
EP2286375A1 true EP2286375A1 (fr) 2011-02-23

Family

ID=40127195

Family Applications (1)

Application Number Title Priority Date Filing Date
EP09761899A Withdrawn EP2286375A1 (fr) 2008-05-15 2009-05-14 Procédé et dispositif de gestion de ressources et support d'enregistrement pour ce procédé

Country Status (7)

Country Link
US (1) US20110313970A1 (fr)
EP (1) EP2286375A1 (fr)
JP (1) JP5631303B2 (fr)
KR (1) KR101247472B1 (fr)
CN (1) CN102027493B (fr)
FR (1) FR2931267B1 (fr)
WO (1) WO2009150348A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111290995B (zh) * 2018-12-07 2023-08-25 北京字节跳动网络技术有限公司 资源管理方法和装置

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0736758A (ja) * 1993-07-20 1995-02-07 Sanyo Electric Co Ltd データ処理装置のデータ項目長定義方法及び属性定義方法
JPH08161342A (ja) * 1994-12-02 1996-06-21 Fujitsu Ltd データベース表示装置
JP3193249B2 (ja) * 1994-12-02 2001-07-30 富士通株式会社 キーワード検索方法
US5877765A (en) * 1995-09-11 1999-03-02 Microsoft Corporation Method and system for displaying internet shortcut icons on the desktop
JPH0981295A (ja) * 1995-09-14 1997-03-28 Canon Inc 情報処理装置及び該装置におけるデータ入力方法
JP4187114B2 (ja) * 1996-03-14 2008-11-26 富士ゼロックス株式会社 ハイパーメディア型文書管理装置
US7735021B2 (en) * 2001-02-16 2010-06-08 Microsoft Corporation Shortcut system for use in a mobile electronic device and method thereof
US20020194508A1 (en) * 2001-06-14 2002-12-19 International Business Machines Corporation Method, apparatus, and program for extending the global sign-on environment to the desktop
US20030088420A1 (en) * 2001-07-10 2003-05-08 Koninklijke Philips Electronics N.V. Electronic program guide for processing content-related information configured using a reference information model
JP4859549B2 (ja) * 2005-06-13 2012-01-25 豊 木内 管理用シンボルを用いた情報管理方法、及び情報管理サーバ
US7716583B2 (en) * 2005-07-12 2010-05-11 Hewlett-Packard Development Company, L.P. Shortcut for predetermined application
US7730427B2 (en) * 2005-12-29 2010-06-01 Sap Ag Desktop management scheme
JP4341656B2 (ja) * 2006-09-26 2009-10-07 ソニー株式会社 コンテンツ管理装置、ウェブサーバ、ネットワークシステム、コンテンツ管理方法、コンテンツ情報管理方法およびプログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2009150348A1 *

Also Published As

Publication number Publication date
CN102027493A (zh) 2011-04-20
JP5631303B2 (ja) 2014-11-26
KR20100134121A (ko) 2010-12-22
JP2011521341A (ja) 2011-07-21
KR101247472B1 (ko) 2013-03-29
US20110313970A1 (en) 2011-12-22
WO2009150348A1 (fr) 2009-12-17
CN102027493B (zh) 2014-04-30
FR2931267B1 (fr) 2010-05-28
FR2931267A1 (fr) 2009-11-20

Similar Documents

Publication Publication Date Title
US10182028B1 (en) Method and system for storing real-time communications in an email inbox
US6571246B1 (en) Automatic data collection and workflow management in a business process
CN102947828B (zh) 使用图像来定制搜索体验
US8413055B2 (en) Methods and systems for customizing and embedding widgets in instant messages
US6725268B1 (en) System and method for providing status information from multiple information sources in a single display
US8904274B2 (en) In-situ mobile application suggestions and multi-application updates through context specific analytics
AU2011299801A1 (en) Automatic and semi-automatic selection of service or processing providers
US20100306146A1 (en) Non-subscription based service for providing contextually-preferred new content to information system users
AU2010315627A1 (en) Mechanism for adding content from a search to a document or message
WO2008151268A2 (fr) Systèmes et procédés pour sélectionner et/ou communiquer un contenu web
WO2008137510A1 (fr) Partage de marqueur et interface de programme d'application de partage de marqueur
US20100082750A1 (en) Dynamically transforming data to the context of an intended recipient
US20110119197A1 (en) Legal communications management mobile application
CN113923175B (zh) 通讯会话的管理方法及装置
CN101454988A (zh) 移动应用程序的用户兴趣驱动发射台及其操作方法
US20130082100A1 (en) System and Method for Processing Barcodes in Electronic Data Communications
US8195718B2 (en) Methods and systems for aggregating content in an instant messaging system
US20140222865A1 (en) Method, System and Program for Interactive Information Services
US20100274793A1 (en) Method and apparatus of configuring for services based on document flows
TW200841194A (en) Using structured data for online research
EP2286375A1 (fr) Procédé et dispositif de gestion de ressources et support d'enregistrement pour ce procédé
US20090204675A1 (en) Rules extensibility engine
US11297018B1 (en) Photo space user interface facilitating contextual discussion between users of a social networking system
WO2012041216A1 (fr) Dispositif électronique portable, procédé de publication de contenu et procédé de suggestions
CN106027383A (zh) 便携式电子设备和用于便携式电子设备的内容发布方法

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20101215

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA RS

RIN1 Information on inventor provided before grant (corrected)

Inventor name: BAZIN, CLAIRE

Inventor name: HUE, CYRIL

Inventor name: DORBES, GUILLAUME

DAX Request for extension of the european patent (deleted)
111Z Information provided on other rights and legal means of execution

Free format text: AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK TR

Effective date: 20130410

17Q First examination report despatched

Effective date: 20140205

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20140318