The invention relates to a method and 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 enabling a computer application to contact a person or access a piece of information.
Management method refers to a method which makes it possible to classify and sort these resources based on predetermined criteria in order to enable a user to easily find one of these resources. For example, the resource management methods particularly make it possible to order and filter the resources based on predetermined criteria.
There are methods for managing people's addresses. These methods are also known as address book management methods For example, such a method exists within the application known as Microsoft® Outlook. The entries (“cards”) within this address book are designed to contain various possible addresses of a contact, such as his or her telephone numbers, e-mail addresses, and mailing address. This card is recorded in a format specific to the application which is to use it. Thus, for example, whenever a user wishes to send an e-mail to a contact which he or she has selected within his or her address book, only the Outlook application can make use of the card's content in order to perform this task.
There are also many other methods for managing other resources. For example, Internet browsers can be used to manage addresses leading to web or HTML (Hyper Text Markup Language) pages. These methods are better known by the term bookmark management. Other applications make it possible to manage image, audio, or video files. However, these various management methods are incompatible with one another. For example, an address book's management method cannot also manage shortcuts to webpages, images, or audio or video files.
It is, however, desirable to have a method for managing resources that makes it possible to manage different types of resources, regardless of the computer application to be executed in order to use those resources.
The invention aims to satisfy this desire. Its object is therefore a resource management method including the saving, within a memory of an electronic calculator, of an instantiable model of a card intended to contain a description of a resource, said card model requiring, when it is instantiated to create a new card, the acquisition of
The card model used here makes it possible to define which application must be executed in response to the selection of that card by a user. Thus, this method for managing resources makes it possible to manage, with a single card model, addresses that may only be used by different computer applications. It therefore becomes possible to use a single resource manager to manage addresses as varied as shortcuts to webpages, access paths to video or audio files, a person's e-mail or postal addresses, people's telephone numbers, etc.
The embodiments of this method may comprise one or more of the following characteristics:
These embodiments of the management method further exhibit the following advantages:
Another object of the invention is an information recording medium containing instructions for executing the aforementioned resource management method whenever these instructions are executed by an electronic calculator.
Finally, another object of the invention is a resource management device comprising an electronic memory containing an instantiable model of a card intended to contain a description of a resource, this card model, during the instantiation thereof to create a new card, forcing the acquisition of:
The invention will be better understood upon reading the following description given only by way of a non-limiting example with reference to the drawings in which:
To simplify
The terminal 4 makes it possible to contact other people by means of an information transmission network 6. For example, this network 6 comprises the Internet network.
Here, the terminal 4 is capable of establishing a telephone call with a telephone 8 or sending an e-mail to a computer workstation 10.
The terminal 4 is also capable of accessing various information such as audio files saved on a remote audio file server 12 and HTML pages saved on a remote Internet server 14.
The terminal 4 is constructed with the assistance of an electronic calculator capable of executing instructions saved on an information recording medium to implement the method of
For example, the central processing unit 20 comprises an electronic calculator 28 capable of executing the computer application instructions saved within the memory 22.
Here, the memory 22 comprises executable files corresponding to the following computer applications:
The memory 22 also comprises instructions 38 necessary to execute the method of
Finally, the memory 22 also comprises the various information needed to execute the method of
Typically, the contents of the WCARD-ID field are automatically filled out when this model is instantiated.
The WCARD-NAME field may either be filled out manually by the user when a new card is created by instantiating that model, or automatically based on the content of the model's other fields.
The ADDRESS section is intended to contain one or more access paths. The access path is an address of a person to be contacted or of a piece of information to be accessed when the resource is an address. If the urce is an executable file, the access path corresponds to that executable file's access path. The value of the access path is saved in an ADDRESS-VALUE field. Each access path is associated with a reference domain 60. Here, the reference domain 60 is defined with the help of the ADDRESS-DOMAIN-NAME and ADDRESS-DOMAIN-SERVICE-LIST fields. The ADDRESS-DOMAIN-NAME field is designed to contain the name of the reference domain. When the model 40 is instantiated, this name may only be chosen from the list 46. For example, here, the list 46 comprises the following names:
The ADDRESS-DOMAIN-SERVICE-LIST field contains a list of computer applications that may use the content of the ADDRESS-VALUE field. Here, the content of the ADDRESS-DOMAIN-SERVICE-LIST field is a function of the conference of the ADDRESS-DOMAIN-NAME field. For example, the content of the ADDRESS-DOMAIN-SERVICE-LIST field is defined with the help of the following table:
Thus, the reference domain 60 defines which computer application(s) must be executed in order to use the content of the ADDRESS-VALUE field. Whenever multiple applications are possible, a message is displayed so that the user himself can choose among the different applications that may be executed.
Here, the applications “PLAYER-PHONE” and “PLAYER-SMS-SEND” respectively correspond to the application's 30 modules capable of making a telephone call and sending an SMS. The application “PLAYER-E-MAIL-SEND” corresponds to the application 32. The application “PLAYER-WEB” corresponds to the application 34. The application “PLAYER-RSS” corresponds to particular module of the application 34 used to subscribe to and read RSS feeds. The applications “PLAYER-MUSIC”, “PLAYER-PICTURE” and “PLAYER-VIDEO” correspond to respective modules of the application 36.
Each access path is also associated with an ADDRESS-PLAYER-STATUT field. The content of this field makes it possible to discriminate between an access path to an executable file and an access path corresponding to an address. For example, this access path comprises the data “Y” when the access path is an access path to an executable file and the value “N” if not.
Whenever the access path is an access pa to an executable file, two additional fields ADDRESS-PLAYER-DEVICE and ADDRESS-PLAYER-SYNTAX must be completed. The ADDRESS-PLAYER-DEVICE field indicates the operating system(s) on which the executable file may be executed.
The ADDRESS-PLAYER-SYNTAX field describes the format of one or more parameters which must be transmitted to that application whenever it is executed. Typically, the parameter(s) in question are contained within a card's ADDRESS-VALUE fields.
The ADDRESS section may contain a description of one or more access paths. In the event that the ADDRESS section contains the description of multiple access paths, the WCARD-DOMAIN domain makes it possible to define which access path to use by default when the card created by instantiating the model 40 is selected by a user. Here, the content of that WCARD-DOMAIN field is, for example, chosen from a list 48. To simplify, here, this list 48 is identical to the list 46 except for the fact that it additionally comprises the “PERSON” value which makes it possible to indicate that the card describes a person's address. Here, the value “PERSON” indicates that the default application to use to reach this person is “PLAYER-PHONE”.
The TAG section is used to define one or more tags when the model 40 is instantiated. For example, these tags are intended to serve as criteria for searching for one or more created cards.
Here, each tag is defined using the following fields:
Here, the model 40 is designed to require that the content of the TAG-TYPE field be chosen from a predetermined list. For example, this predetermined list contains the following three values “DOMAIN”, “SYSTEM”, and “USER”. Whenever the value of the TAG-TYPE field is “DOMAIN”, then the vale of the TAG-NAME field may only be chosen from the list 42. Here, the list 42 associates possible values for the TAG-NAME field based on the value contained with the WCARD-DOMAIN field. For example, if the value of the WCARD-DOMAIN field is “PERSON”, then the value of the TAG-NAME field must be chosen from the following list {“LAST NAME”, “FIRST NAME”, “DATE OF BIRTH”, etc.}.
If the WCARD-DOMAIN field contains the value “FILE-MUSIC”, then the content of the TAG-NAME field must be chosen from the following list {“TYPE OF ENCODING”, “TYPE OF FILE”, etc.}.
If the content of the TAG-TYPE field is “SYSTEM”, then it is a tag whose name and value are automatically determined by the resource management device. For example, it may be a tag for indicating when the last revision date of the created card's content was.
Finally, if the content of the TAG-TYPE field is “USER”, then the content of the TAG-NAME and TAG-VALUE fields may be freely chosen by the user when a card is creating through the instantiation of the model 40.
The card model 40 therefore requires the acquisition, when a card is created by instantiating that model, of a certain number of fields.
The card 71 describes a picture. This card comprises a WCARD2 identifier and an “ATT logo” name as well as an access path to the file containing the picture to be displayed. The access path is contained within the ADDRESS-VALUE field. This access 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 in order to display that picture is the “PLAYER-PICTURE” application.
The card 72 describes an audio file saved on a remote server such as the server 12. Here, this card has the identifier “WCARD3” and the name “RING-MUSIC”. This card also contains the access path to the audio file on the server 12 as well as a reference domain. Here, the reference domain specifies that the application to be executed to listen to this audio file is the application “PLAYER-MUSIC”.
Additionally, the user has freely defined a tag whose name is “CLASS” and whose value is “C2”. This tag is in some ways an annotation by the user intended to enable him to easily find the tag 72.
The tag 73 describes a person named “Tom”. Some people may be contacted by telephone or by 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 that person. Each of these access paths is associated with a reference domain specifying which application to be executed in order to contact that person, either by telephone or by e-mail. More specifically, whenever the access path contains a telephone number, the reference domain specifies that the applications to be executed are “PLAYER-PHONE” and “PLAYER-SMS-SEND”. Given that two app cations may be executed, when the user seeks to contact that person by using his telephone number, a screen is displayed prompting the user to choose between these two applications that may be executed to contact this person using his telephone number.
For the e-mail address, the reference domain specifies that the application to be executed is “PLAYER-E-MAIL-SEND”.
Finally, the card 73 also comprises five tags. Two of these tags are used to define the family name and mailing address of that person. It should be noted that the value of the tag defining the mailing address is the “WCARD1” identifier from the card 70. Thus, in this specific situation, that person's mailing address is defined by reference to another card. In this situation, when information regarding that person is displayed, his or her address will be obtained from the content of the card 70.
The other defined tags are tags freely defined by the user. Here, the user has defined a tag whose name is “LOGO” and whose value comprises a reference to the card 71 such that the description of the logo contained within the card 71 does not need to be repeated within the card 73.
Another tag bears the name “RING”, and its value comprises a reference to the tag 72 so that it is not necessary to incorporate into the card 73 the full description of the audio file already included within the card 72.
Finally, the last tag defined by the user bears the name “CLASS”, meaning a name identical to that already used within the tag 72. Additionally, the value of that tag is also “C2” as within the tag 72. Thus, if the user searches for cards containing a tag whose name is “CLASS” and whose value is “C2”, he will find at least the tags 72 and 73. Thus, the user is able to select and manage cards describing resources of totally different types.
Here, the name of this card is “PLAYER-PHONE”. Thus, this card describes the application “PLAYER-PHONE” to be executed when the access path of a card contains a telephone number.
By way of an example, a tag freely defined by the user has been added to the content of the card 80. This tag bears the name “CLASS” and has the value “C3”.
The operation of the system 2 will now be described in greater detail with respect to the method of
Initially, during a step 90, the model 40 is saved within the memory 22 along with the various applications and information needed to manage the cards. Next, during a step 92, the user creates cards by instantiating the model 40. When each card is created, the model 40 defines the information and format of the information that must be entered by the user.
Once multiple cards have been created, during a step 94, the user may select one of those cards. In response to the selection of a card describing an address for contacting a person or accessing a piece of information, the application specified by the reference domain is executed. The content of the ADDRESS-VALUE field is transmitted as a parameter to that specific application in order to automatically trigger the execution of a call or sending of an SMS message to the person to be contacted or in order to trigger the presentation of the information to be accessed. In the event that the selected card describes an executable file, the execution of this executable file is automatically triggered in response to that card's section.
In parallel with the steps of creating of selecting cards, the user may, for example, proceed with the following steps:
During the step 98, the cards are searched for using criteria specified by the user, such as the names and/or values of certain tags.
It is therefore understood that owing to the model 40, it is possible to manage any resources using a single application.
Many other embodiments are possible. For example, the terminal 4 may be a mobile telephone or a personal assistant such as a PDA (Personal Digital Assistant) or any other communication terminal.
The resources that may be described using the model 40 are not limited to the examples given in the preceding description. For example, video files, documents, or other files may also be described by a card obtained by instantiating the model 40.
Likewise, the various lists 42, 46, and 48 may be completed or modified as desired.
Number | Date | Country | Kind |
---|---|---|---|
0802626 | May 2008 | FR | national |
Number | Date | Country | |
---|---|---|---|
Parent | PCT/FR2009/050901 | May 2009 | US |
Child | 12926268 | US |