WO2009118477A2 - Service d'adresse indirecte de connexion sur réseau étendu - Google Patents

Service d'adresse indirecte de connexion sur réseau étendu Download PDF

Info

Publication number
WO2009118477A2
WO2009118477A2 PCT/FR2009/000236 FR2009000236W WO2009118477A2 WO 2009118477 A2 WO2009118477 A2 WO 2009118477A2 FR 2009000236 W FR2009000236 W FR 2009000236W WO 2009118477 A2 WO2009118477 A2 WO 2009118477A2
Authority
WO
WIPO (PCT)
Prior art keywords
address
user
network
alias
server
Prior art date
Application number
PCT/FR2009/000236
Other languages
English (en)
Other versions
WO2009118477A3 (fr
Inventor
Thierry Lamouline
Original Assignee
Yooget
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
Priority claimed from FR0801417A external-priority patent/FR2928799B1/fr
Application filed by Yooget filed Critical Yooget
Priority to EP09725837A priority Critical patent/EP2253105A2/fr
Publication of WO2009118477A2 publication Critical patent/WO2009118477A2/fr
Publication of WO2009118477A3 publication Critical patent/WO2009118477A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/30—Managing network names, e.g. use of aliases or nicknames
    • H04L61/301—Name conversion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/30—Managing network names, e.g. use of aliases or nicknames
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2596—Translation of addresses of the same type other than IP, e.g. translation from MAC to MAC addresses

Definitions

  • the invention relates to the field of wide area computing.
  • the present invention improves the situation.
  • a network address server which comprises a storage of correspondence between address calls and network addresses, and an address supply service, arranged to respond to the presentation of a call from address by returning the corresponding network address.
  • the network address server comprises a management of user accounts.
  • the storage of mappings between address calls and network addresses includes address calls stored as bytes of a predetermined format, which format includes an item related to a user according to a predetermined naming rule.
  • network addresses are network indirect addresses (domain name, or more generally URL).
  • the address supplying service is arranged to respond to an address call in the form of a byte having said predetermined format by restoring the indirect network address that corresponds to this multiplet, subject to verification of a first condition, which involves the link to a user according to said predetermined naming rule.
  • a user computer station comprising a browser, and which further comprises a mechanism capable of establishing a connection to an indirect network address server, as defined above.
  • the connection may include a parameter comprising an address call in the form of a byte of a predetermined format.
  • said mechanism operates the browser with at least a portion of the return data as a network address.
  • the return data may include several network addresses, one of which will be chosen by the user.
  • this is expressed as a method.
  • a computer navigation assistance method in particular, in which a server provided with a storage of correspondences between address calls and network addresses is provided.
  • an address supply service arranged to respond to the presentation of an address call by reproducing a network address that corresponds to it. And this server is queried to reach a network location.
  • This method is remarkable in that it comprises the following steps: a. maintain a user account management on the server, b. storing on the server mappings between address calls and network indirect addresses, including address calls stored as bytes of a predetermined format, which format includes an item linked to a user according to a predetermined naming rule, vs. arranging the address supplying service to respond to an address call in the form of a byte having said predetermined format by restoring the indirect network address that corresponds to that byte, subject to verification of a first condition, which involves the link to a user according to said predetermined naming rule, and d.
  • At least one user station with a mechanism capable of establishing a connection to said server, the connection allowing an address call in the form of a multiplet in the predetermined format, and, on a confirmed return, to activate the browser with the return data as an indirect network address.
  • FIG. 1 is the block diagram of the basic computer structure to which may be applied the invention
  • FIG. 2 is a detailed block diagram of an embodiment of the invention
  • FIG. 3 is a flow diagram generally illustrating the creation of accounts and addressing data stored in a server according to FIG. 2;
  • FIG. 4 is a flow diagram illustrating generally the use of the data; addressing stored in a user station according to FIG.
  • FIG. 5 is a flow diagram illustrating in more detail the creation / modification of addressing data
  • FIG. 6 is a diagram illustrating the offer to a user of different modes of calling the addressing data
  • FIGS. 7 to 9 are flow diagrams illustrating these different modes of calling the addressing data.
  • Appendix A includes tables defining an example of data structures according to the present invention.
  • Figure 1 describes the general structure of a system wherein the devices and method according to the present invention can be applied.
  • SMUB for Smart Multi-Usage Bookmark
  • SMUB for Smart Multi-Usage Bookmark
  • WO2008 / 006999 provides a way to organize indexing based on document contents. But that, too, is not entirely satisfactory in all cases. We will see below various proposals to improve things.
  • a priori means a URL type address.
  • the invention can also be applied to an address in a computer station or in a local network accessible to a computer station.
  • a server station 100 consists of a web interface 102, which allows data exchanges over a wide area network (web) with a module for creating the SMUBs by account (referenced 120) and a module of use of SMUBs referenced 140.
  • a user station 200 there is also a web interface 202, which allows the user-side SMUBs creation module, referenced 210, to interact via the extended network with the module 120 of the server 100.
  • a SMUBs call module 220 may interact with the module 140 of the server 100.
  • a third station 300 may be provided, also provided with a network interface 302, which allows a SMUB call module. 350 to cooperate with the module 140 of the server 100. It will be seen that this cooperation is a little different from that of the call module 220 of a user station.
  • the creation module 120 of FIG. 1 can be considered as comprising the modules 112 to 126 of FIG. 2.
  • the module 140 of FIG. 1 can be considered as comprising the modules 142 and 152 of FIG.
  • FIG. browser 212 or other communication function, capable of cooperating with the server module 112, to execute the creation of an account, the management data of which is in a memory 114.
  • the browser can also interact with a function of creating a SMUB called "internet", as opposed to the creation of a "local” SMUB which is the function 222 of the user station.
  • the function 122 of the server 100 will first interact with an account control function for the benefit of the user requesting the creation. This function is referenced 124. It is only after this control that one can proceed to the creation of the data of the SMUB proper, in block 126.
  • the SMUB data is stored in a memory 134, which cooperates with an optional keyword management 136.
  • a creation function 222 which is similar to the function 126 of the server, but is confined to the designation of locations or directories inside the user station.
  • This local data is stored in memory 244, and may be subject to a local SMUB call at 242.
  • a user station When a user station has created SMUB internet data, it can replicate by the function 132 in the local data memory 244. This avoids calling the server to have the functions in question.
  • the data that is thus replicated on the user station 200 are those that are specific to one or more accounts assigned to user stations 200.
  • the user station 200 may also seek access to other SMUBs created by other user stations.
  • the browser 212 may have an own interface, for example a window comprising a plurality of fields, for example two, for words corresponding to a format of the SMUB.
  • the browser 212 may also include a return function 214 for using a field, for example a URL field, of an application, such as a web browser, for example in the form mot1 / word2.
  • the return function 214 called "smubit" as an example returns the variables mot1 and word2 to the browser 212 itself in which the treatment below can be performed.
  • the return function 214 interacts with another application, for example the web interface 202 or the browser 212 itself, to pick up the SMUB variables.
  • the user station 200 may comprise a voice command 216, for example comprising a microphone and recognition software such as "Dragon Naturally Speaking" ®.
  • the voice command 216 can control the filling of windows to inform the SMUB variables, and their validation.
  • the call module 242 after verifying that it is not a local SMUB, will query the use at the server SMUB internet 142.
  • the server 142 can give access to all SMUBs, subject to conditions that will be seen later.
  • a SMUB can be defined by its creator as public.
  • any third party station 300 may, from its browser 312, call SMUBs by the function 352, which then accesses the public SMUB server 152, which interrogates the subset of the SMUB data. stored in 144 which corresponds to public SMUBs.
  • Tables 1 to 4 of Appendix A give a particular embodiment of the invention.
  • the personal data are fanciful, and are not intended to correspond to actual data. This is particularly the case for addresses email, and URLs.
  • Table 1 defines 3 different users or actors, distinguished by different email addresses in the U_email column.
  • the same actor for example a ( ⁇ ), b.com can have three distinct aliases (also called short names, or nickname), for example "John”, “Mickey” and "Jdupont", as indicated in the UjshortName column. At least some of these aliases may have a long name, as indicated in the UJongName column.
  • a password for account management and SMUBS is stored in the VJPW column.
  • each line has an internal identifier in the Intjd column.
  • each alias is associated with a password of its own, and that there is no password associated with the user account
  • the password "alias” is used to manage SMUBS associated with the alias, but not those of the other aliases. This may be the case, for example, when people from the same family share the same email address.
  • Each line has an internal identifier in the O_id column.
  • This table 2 defines the correspondence between a SMUB, determined by the U_shortName and suffix columns, and an address on the WAN, or on an internal (or even external) reader of the user's station, defined in the URL column, which is accompanied by a column of URUd identifiers.
  • the same SMUB (Jean / Paris") can target several different URLs.
  • the call of this SMUB will then occur by the display of the various URLs for choice, for example in list or table.
  • Each line has an internal identifier in the KW_id column.
  • the KW column contains keywords derived from the TUIe column of Table 2.
  • the Oid column contains, in list form, the identifiers of the rows in Table 2 whose title contains the keyword of the line.
  • Table 3 includes only a few of the keywords in Table 2. Non-discriminating words, such as "My” or “to” in “My trip to Paris", can be ignored. Moreover, some words can be interpreted, like "Yellow pages", converted to "Directory”.
  • a conversion to "Directory” may be made on presentation of "Yellow Pages” as a multi-term keyword (if a multi-term keyword is allowed), or on presentation of "Yellow” and "pages". "as two uni-terms keywords (one word at a time).
  • Keywords are not necessarily stored in the title. They can be stored directly at Table 3, corresponding to the OID of the current SMUB.
  • the user is allowed to enter his own keywords, especially in view of the title.
  • This provides a human indexing of URL content, which is much more accurate and reliable than an automatic indexing system, statistically at least. If the user does not spontaneously enter a keyword, it can be expected that the system offers a title from the URL, and keywords from this title, the user validates, after having possibly modified.
  • Int id owner columns and Int id links designate aliases, by their Intjd identifier in table 1.
  • Table 4 the presentation of Table 4 is only an example, and one could conceive the contents of the Intjdjinks boxes as a list of Uid values.
  • the Intjdjinks column has the same meaning as in Table 4, but here in the form of a list, and the Oid column designates a SMUB to which the user of the Intjdjinks column can access.
  • the Oid of Table 5 must correspond to Level 1 (Private Sphere) SMUBs in Table 2, and - a user present in the Intjdjinks column of Table 5 next to an Oid must also be present in the table 4 next to the owner (creator) of the SMUB that corresponds to this Oid.
  • the next operation 414 is to open a personal account.
  • the personal identifier is the email address (e-mail) of the user, according to the table 1.
  • the user can then create one or more aliases, based on this personal account, as indicated for the operation 415. It will be possible to designate in the following an alias (and consequently a user), by its identifier in the table 1 , for example Uidl.
  • Operation 416 then allows the creator of an alias to enter third party aliases that are part of his private sphere.
  • the creative user must enter a third-party alias.
  • the system verifies its existence, then creates a line in the table 4 (for example the first one) with Intjdjowner the Uidl identifier of the alias concerned of the creator user, and Intjdjinks column the Uid4 identifier of the user. alias of the third party.
  • Another user who gave himself the alias Uid4 is included in the private sphere of the user who gave himself the alias Uidl. This assumes that the other user Uid4 has communicated his alias to the user Uidl.
  • Uid9 the email address of Uidl (exclusively); preferably, the request of Uid9 is recorded by the system, which takes care of asking the question to Uidl, and to include Uid9 in the private sphere of Uidl in case of a positive response.
  • This linking function known, is not represented.
  • the creator user can also create one or more SMUB datasets (see Table 2). This is preferably done from the favorites of the station, as indicated in operation 417. It is possible, for example, to repatriate all the favorites, and to propose, for one or more aliases UjShortNam ⁇ , to use I 1 URL of the favorite as a URL field. , a (editable) proposal from the name of the favorite as the Suffix field, and the name of the favorite (editable) as the Titie field.
  • the fields identifier Oid and URLid are created as usual, by automatic incrementation for example.
  • the operation 418 consists of duplicating the remote SMUB data, present on the server, to the local station.
  • Figure 4 illustrates the use function of a SMUB. We consider the case of Figure 2, where there is a local replication SMUB data.
  • the function 242 queries the local SMUB memory 244, and the latter returns a target network indirect address (or URL), if the conditions of the SMUB are verified. If this is the case, the target PURL is returned to the browser by operation 454, and it ends in 460. If there are multiple URLs for the same SMUB (see "John / Paris" in Table 2), then a choice is offered to the user. If the operation 452 was a failure, then there is a call to the remote site 456 with a request relating to the desired SMUB. (This is normally a SMUB created by another user.) Again, in 458, we can receive a target URL, in which case, we continue in 454 as before. Otherwise, an appropriate error processing is performed at 462.
  • a target network indirect address or URL
  • FIG. 5 is the flow diagram of the creation / modification of a SMUB.
  • the entry operation 510 recalls that it is a matter of creating / modifying a SMUB. Then, operation 512 is to go to the server site, noted by convenience http://smub.com.
  • Operation 514 is to connect to the personal account on the site, if it is not already done. Then, operation 520 makes it possible to choose one of the aliases of the personal account to which the user has connected.
  • the 530 test allows you to choose between creating a new SMUB or modifying an existing SMUB.
  • the operation 532 consists in the designation by the user of a true URL, that is to say of an existing indirect address (or presumed to exist) on the wide area network, or an address on his workstation.
  • the structure of the created SMUB responds to a predetermined format that includes two words, generically noted ⁇ word 1> and ⁇ word2>, respectively, with a predefined separator (here "/") between these two words.
  • This format can be written as:
  • an operation 534 is preferably provided by which the system proposes, for ⁇ word2>, a default suffix to complete the alias which forms the first part of the SMUB, and verifying the condition of uniqueness of the SMUB.
  • the user may decide to adjust the suffix, in which case the test 538 verifies that the set ⁇ U_alias> and ⁇ suffix> is unique. If it is not, the suffix adjustment is continued in 539 until the condition of uniqueness is satisfied.
  • the SMUB itself is then completely defined.
  • operation 545 makes it possible to define descriptive keywords associated with the actual URL targeted by the SMUB, or else with the idea that the user has,
  • operation 550 makes it possible to define a level.
  • three levels personal, private and public.
  • one or more functions are added to the natural functions of the browser.
  • An example of an additional function is to create a SMUB from a current URL in the browser. This function is activated (or visible), for example in the form of a push button on the screen, if the user is already connected to his personal account on the site SMUB, with one of the aliases of this personal account . In this case, compared with FIG. 5, the actuation of the push button makes it possible to directly jump to the operation 534 for defining the SMUB.
  • Other functions, or variants can be designed such as entering the current URL of the browser as SMUB on one or more aliases of the outstanding account, after choosing from an alias list.
  • the generic format of a SMUB is:
  • the SMUB address call is accepted after verification of a first condition, which involves at least one of the following sub-conditions: a. the respect of the naming rule, here the form ⁇ motl> / ⁇ word2>, b. the fact that ⁇ motl> is a registered user alias ⁇ U alias>, listed in the UjShortName column in Table 1 and / or Table 2, and c. the fact that ⁇ word2> is a ⁇ suffix> in the Suffix column next to ⁇ U_alias> in the UjShortName column in Table 2.
  • the first condition can stop there for public classified SMUBs (in the example, level 0 in table 3). It is more severe for the other levels, since there is one or more additional level-related sub-conditions. For example, the user who calls the SMUB may have used a "SMUB session" on the server, which identifies him. In that case :
  • a private SMUB (level 1) is accessible only if the calling alias has a Uid that appears in table 4 next to the UID of the SMUB creator, and if, in the Table 5, the Uid of the same caller appears next to the Oid of the SMUB in question.
  • a personal SMUB (level 2) is only accessible if the caller is the one who created the SMUB. The operation here depends on how passwords are used in the table
  • logging is not necessary when SMUB 242 is called in local mode, since the user is generally known by the operating system of the local station.
  • the incoming user can log on to 602 if he has an account. If no session is open (604), the incoming user has only restricted access to the public SMUBS (database 152 in Fig. 2). If a session is open (608), the incoming user potentially has access to all SMUBs (database 142 in Figure 2), subject to the conditions applicable to private and personal SMUBs.
  • the logon can be included as an option in the screen that has just been defined, the default mode (without open session) being access to public SMUBs only.
  • Other functions may also be included in this screen, including features already described, such as opening an account, and / or managing SMUBs of an already open account, or other query or query functions. search as those described here.
  • FIG. 7 illustrates the use flow diagram direct 612 of a SMUB.
  • Operation 614 consists in checking the shape of the SMUB, for cutting it in order to correctly interrogate the Table 2. This form verification can be directly associated with the input area of the SMUB in the request 612 of FIG. 6.
  • the call 600 may be accompanied by a SMUB as a parameter, in which case the corresponding request of FIG. 7 is executed directly.
  • the operation 624 searches in the table 3 according to the keyword or keywords chosen by the user. For example, the only keyword “Paris” gives the list “Oid1, Oid2, Oid3” in Table 3. But if we take (for example with a separative, or a multiple input zone) the two words- keys "Paris” and "Hotel", it remains then, by crossing, that "Oid1".
  • the operation 626 searches in the table 2 for the URL (s) corresponding to this or these "Oid" (s). , and offers this or these URLs as a choice to the user. This can be done by a table, each line of which indicates the URL found.
  • the table may include one or more additional columns, to give additional information, such as the keywords that correspond to the Oid of the URL of the line, or the SMUB and / or the title corresponding to this Oid in table 2, or the long name corresponding to the alias portion of the SMUB in table 1.
  • FIG. 9 illustrates the flow diagram of search 642 by alias.
  • the operation 644 checks whether there exists one or more aliases verifying the search condition (for example the beginning of the alias) in the table 1. If yes, the operation 646 proposes the SMUB (s) already defined and corresponding to this / these aliases in the table 2. If, in 647, the user accepts the proposed SMUB (one of the proposed SMUBs if there are several), then we return the corresponding target URL to the operation 664 If there are several SMUBs proposed, they can be presented in a table, with one or more additional columns to present additional information, for example, if there is, the long name corresponding to each alias in table 1.
  • the operation 644 searches if there is one or more aliases verifying a search condition on an element, for example a fragment, of a long user name.
  • aliases verifying a search condition on an element, for example a fragment, of a long user name.
  • the screen defined with respect to FIG. 6 may be designed as an event form, which has three input areas for operations 612, 622 and 642, respectively, and possibly other areas. or buttons for the other functions mentioned.
  • the user fills the zone for which he intends to search for a SMUB, and this entry triggers the corresponding operation.
  • a SMUB is initially a parameter, the search can be started directly at 612.
  • the examples of given tables are illustrative; it is possible to split at least some of the tables, for example by storing the URLs, associated with their URL_id identifier. It is also possible to group them at least partially, even if they create some redundancy.
  • d. The condition of uniqueness of the SMUBs is not absolutely imperative. One could admit duplicates, as long as these are reported, and / or that the creator of duplicates can remove this ambiguity.
  • the user station may include a function of using the control input bar of a software present on said station.
  • the user station may include a link with a voice command.
  • ⁇ word2> is necessarily a character string that does not include the predefined separative ( 1 V "), or even including only letters and numbers, while ⁇ motl> can be any character string, which can even include the predefined separative (here the slash "/").
  • ⁇ motl> and ⁇ word2> can be any character string, which can even include the predefined separative (here the slash "/").
  • the number of levels, and the sub-conditions associated with each of the levels are not limiting. At least in some cases, we could define the private sphere (at least partially) not by those who are included, but by those who are excluded. The same applies to SMUBs in the private sphere.
  • an "alias" is assumed to be unmodifiable. We can only destroy it, if necessary.
  • a variant would be to allow the modification of an alias. This would involve either modifying all SMUBs that result from the modified alias accordingly (if necessary by temporarily keeping SMUBs composed with the old alias), or removing all SMUBs that result from the alias, thereby forcing their recreation at will.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Serveur d'adresse réseau indirecte comprenant un stockage (144) de correspondances entre des appels d'adresse et des adresses réseau, un service de fourniture d'adresse (142), agencé pour répondre à la présentation d'un appel d'adresse en restituant une adresse réseau qui lui correspond, et une gestion de comptes d'utilisateurs (112), le stockage (144) de correspondances entre des appels d'adresse et des adresses réseau comprenant des appels d'adresse stockés comme des multiplets d'un format prédéterminé, ce format comprenant un élément lié à un utilisateur muni d'un compte selon une règle de nommage prédéterminée, tandis que les adresses réseau sont des adresses indirectes, le service de fourniture d'adresse (142) étant agencé pour répondre à un appel d'adresse sous la forme d'un multiplet possédant ledit format prédéterminé en restituant l'adresse indirecte réseau qui correspond à ce multiplet, sous réserve de vérification d'une première condition, qui implique le lien à un utilisateur selon ladite règle de nommage prédéterminée.

Description

Service d'adresse indirecte de connexion sur réseau étendu
L'invention concerne le domaine de rinformatique sur réseaux étendus.
Les postes informatiques actuels possèdent en interne une capacité de stockage de données considérable, typiquement la centaine de giga-octets, ou plus. Il est déjà difficile de s'y retrouver, même avec une structure bien choisie de répertoires. Lorsqu'il est relié à un réseau étendu, comme Internet, un tel poste a potentiellement accès à une quantité d'informations augmentée presque à l'infini, et dont l'organisation lui échappe.
Différentes solutions sont mises en œuvre pour tenter de faciliter la vie à l'usager. Mais elles ne donnent pas entière satisfaction.
La présente invention vient améliorer la situation.
Elle propose d'abord un serveur d'adresse réseau, qui comprend un stockage de correspondances entre des appels d'adresse et des adresses réseau, et un service de fourniture d'adresse, agencé pour répondre à la présentation d'un appel d'adresse en restituant l'adresse réseau qui lui correspond.
Selon un aspect de l'invention, le serveur d'adresse réseau comprend une gestion de comptes utilisateurs. Le stockage de correspondances entre des appels d'adresse et des adresses réseau comprend des appels d'adresse stockés comme des multiplets d'un format prédéterminé, ce format comprenant un élément lié à un utilisateur selon une règle de nommage prédéterminée. De leur côté, les adresses réseau sont des adresses indirectes réseau (nom de domaine, ou plus généralement URL). Et le service de fourniture d'adresse est agencé pour répondre à un appel d'adresse sous la forme d'un multiplet possédant ledit format prédéterminé en restituant l'adresse indirecte réseau qui correspond à ce multiplet, sous réserve de vérification d'une première condition, qui implique le lien à un utilisateur selon ladite règle de nommage prédéterminée. Selon un autre aspect de l'invention, il est proposé un poste informatique utilisateur, comprenant un navigateur, et qui comprend en outre un mécanisme capable d'établir une connexion vers un serveur d'adresse indirecte réseau, tel que défini ci-dessus. La connexion peut comporter un paramètre comprenant un appel d'adresse sous forme d'un multiplet d'un format prédéterminé. Sur retour confirmé, ledit mécanisme actionne le navigateur avec une partie au moins des données de retour en tant qu'adresse réseau. Par exemple, les données de retour peuvent comporter plusieurs adresses réseau, dont l'une sera choisie par l'usager.
Selon d'autres aspects de l'invention, celle-ci s'exprime sous forme de procédé.
Dans l'une des formes de procédé, il est proposé notamment un procédé d'aide à la navigation informatique, dans lequel on prévoit un serveur muni d'un stockage de correspondances entre des appels d'adresse et des adresses réseau, et d'un service de fourniture d'adresse, agencé pour répondre à la présentation d'un appel d'adresse en restituant une adresse réseau qui lui correspond. Et ce serveur est interrogé afin d'atteindre un emplacement réseau.
Ce procédé est remarquable en ce qu'il comprend les étapes suivantes : a. maintenir sur le serveur une gestion de comptes utilisateurs, b. stocker sur le serveur des correspondances entre des appels d'adresse et des adresses indirectes réseau, comprenant des appels d'adresse stockés comme des multiplets d'un format prédéterminé, ce format comprenant un élément lié à un utilisateur selon une règle de nommage prédéterminée, c. agencer le service de fourniture d'adresse pour répondre à un appel d'adresse sous la forme d'un multiplet possédant ledit format prédéterminé en restituant l'adresse indirecte réseau qui correspond à ce multiplet, sous réserve de vérification d'une première condition, qui implique le lien à un utilisateur selon ladite règle de nommage prédéterminée, et d. munir au moins un poste utilisateur d'un mécanisme capable d'établir une connexion vers ledit serveur, la connexion permettant un appel d'adresse sous forme d'un multiplet au format prédéterminé, et, sur retour confirmé, d'actionner le navigateur avec les données de retour en tant qu'adresse indirecte réseau.
D'autres caractéristiques et avantages de l'invention apparaîtront à l'aide de la description qui suit, et des dessins annexés, sur lesquels: - la figure 1 est le schéma par blocs de la structure informatique de base à laquelle peut s'appliquer l'invention,
- la figure 2 est le schéma par blocs détaillé d'un mode de réalisation de l'invention,
- la figure 3 est un diagramme de flux illustrant de façon générale la création de comptes et de données d'adressage stockées dans un serveur selon la figure 2, - la figure 4 est un diagramme de flux illustrant de façon générale l'utilisation des données d'adressage stockées dans un poste utilisateur selon la figure 2,
- la figure 5 est un diagramme de flux illustrant de façon plus détaillée la création/modification de données d'adressage,
- la figure 6 est un schéma illustrant l'offre à un utilisateur de différents modes d'appel des données d'adressage, et
- les figures 7 à 9 sont des diagrammes de flux illustrant ces différents modes d'appel des données d'adressage.
Les dessins et la description ci-après contiennent, pour l'essentiel, des éléments de caractère certain. Ils pourront donc non seulement servir à mieux faire comprendre la présente invention, mais aussi contribuer à sa définition, le cas échéant.
En outre, la description détaillée est augmentée des annexes suivantes: - L'annexe A comprend des tables définissant un exemple de structures de données selon la présente invention.
Ces Annexes sont mises à part dans un but de clarification, et pour faciliter les renvois. Elles sont parties intégrante de la description, et pourront donc non seulement servir à mieux faire comprendre la présente invention, mais aussi contribuer à sa définition, le cas échéant. Ceci s'applique également en tous points aux dessins.
Il est maintenant fait référence à la figure 1, qui décrit la structure générale d'un système où les dispositifs et le procédé selon la présente invention peuvent s'appliquer.
Dans la présente description, l'acronyme SMUB (pour Smart Multi-Usage Bookmark) désigne une chaîne de caractères obéissant à un format prédéterminé choisi, qui, dans le mode de réalisation préférentiel, est du type <motl >/<mot2>.
On sait que sur un réseau étendu tel qu'Internet, il existe des adresses physiques, ou adresses IP, qui sont peu parlantes, donc rarement utilisées directement. On préfère utiliser les URL ("Uniform Resource Locator"), qui peuvent être vues comme une adresse indirecte, permettant de retrouver l'adresse physique, à travers ce que l'on appelle un serveur de nom de domaine (DNS). De même, dans un poste informatique, on utilise peu ou pas l'adressage direct d'un disque ou autre support de mémoire ; on utilise plutôt des répertoires, qui sont aussi une forme d'adressage indirect. Il en est encore de même dans un réseau local. La présente demande concerne ce type d'adressage indirect, qui, quoique plus parlant que les adresses directes, devient très vite hermétique et/ou difficile à gérer lui aussi.
Parmi les outils disponibles, on connaît les "favoris" ou "raccourcis". Ils sont simples d'utilisation. Mais le problème se reporte alors sur la gestion et l'organisation des raccourcis. De plus, un utilisateur d'informatique nomade devra recopier ses raccourcis sur les différents postes qu'il utilise. L'usage des "favoris" ou "raccourcis" n'est donc pas véritablement satisfaisant.
D'où le succès des moteurs de recherche, dont les versions récentes opèrent aussi bien à l'intérieur du poste local que sur le réseau étendu. Ils ont également des inconvénients. Tout d'abord, l'indexation intégrale des données stockées sur le poste local consomme des ressources considérables, tant en stockage qu'en capacité de traitement. De plus, une fois que l'on a trouvé l'emplacement des données recherchées, il faut recourir à un raccourci ou favori, si l'on ne veut pas recommencer la même recherche la prochaine fois. On retrouve alors les inconvénients d'organisation des raccourcis, et aussi celui de leur caractère local.
WO2008/006999 propose un moyen d'organiser l'indexation en fonction des contenus de documents. Mais cela, non plus, n'est pas entièrement satisfaisant dans tous les cas. On verra ci-après différentes propositions pour améliorer les choses.
Dans la suite, par "adresse indirecte sur le réseau étendu" ou plus brièvement "adresse indirecte", on entend a priori une adresse de type URL. Mais l'invention peut s'appliquer aussi à une adresse dans un poste informatique ou dans un réseau local accessible à un poste informatique.
A droite de la figure 1, un poste serveur 100 est constitué d'une interface web 102, qui permet des échanges de données sur un réseau étendu (web) avec un module de création des SMUBs par compte (référencé 120) et un module d'utilisation des SMUBs référencé 140.
Au niveau d'un poste utilisateur 200, il est posé également une interface web 202, qui permet au module de création de SMUBs côté utilisateur, référencé 210, d'interagir par l'intermédiaire du réseau étendu avec le module 120 du serveur 100. De même, un module d'appel de SMUBs 220 peut interagir avec le module 140 du serveur 100. Enfin, on peut prévoir un poste tiers 300, également muni d'une interface réseau 302, qui permet à un module d'appel de SMUBs 350 de coopérer avec le module 140 du serveur 100. On verra que cette coopération est un peu différente de celle du module d'appel 220 d'un poste utilisateur.
La même structure se retrouve sur la figure 2, mais de manière plus détaillée, correspondant à un mode de réalisation particulier de l'invention.
Le module de création 120 de la figure 1 peut être considéré comme comprenant les modules 112 à 126 de la figure 2.
Le module 140 de la figure 1 peut être considéré comme comprenant les modules 142 et 152 de la figure 2.
Si l'on se tourne maintenant vers le poste utilisateur 200, la figure 2 fait apparaître un navigateur 212, ou autre fonction de communication, capable de coopérer avec le module 112 du serveur, pour exécuter la création d'un compte, dont les données de gestion sont dans une mémoire 114.
Cette création de compte peut se faire de manière classique, adaptée comme on le verra plus loin.
Le navigateur peut également interagir avec une fonction de création d'un SMUB dit "internet", par opposition à la création d'un SMUB "local" qui est la fonction 222 du poste utilisateur.
La fonction 122 du serveur 100 va d'abord interagir avec une fonction de contrôle de l'existence d'un compte au profit de l'utilisateur qui demande la création. Cette fonction est référencée 124. C'est seulement après ce contrôle que l'on pourra procéder à la création des données du SMUB proprement dites, dans le bloc 126.
Les données du SMUB sont stockées dans une mémoire 134, qui coopère avec une gestion de mots clés 136, optionnelle.
Si l'on revient maintenant au poste utilisateur 200, il est également possible d'y créer des SMUBs locaux, par une fonction de création 222 qui est semblable à la fonction 126 du serveur, mais se trouve confinée à la désignation d'emplacements ou répertoires situés à l'intérieur du poste utilisateur.
Ces données locales sont stockées dans la mémoire 244, et pourront faire l'objet d'un appel de SMUB local en 242.
Lorsqu'un poste utilisateur a créé des données SMUB internet, il peut les répliquer par la fonction 132 dans la mémoire des données locales 244. Ceci évite d'appeler le serveur pour avoir les fonctions en question.
Les données qui sont ainsi répliquées sur le poste utilisateur 200 sont celles qui sont propres à un ou des comptes attribués aux postes utilisateurs 200.
Le poste utilisateur 200 peut également chercher à accéder à d'autres SMUBs créés par d'autres postes utilisateurs. Le navigateur 212 peut posséder une interface propre, par exemple une fenêtre comprenant une pluralité de champs, par exemple deux, pour des mots correspondant à un format du SMUB. Le navigateur 212 peut également comprendre une fonction de renvoi 214 pour se servir d'un champ, par exemple un champ d'URL, d'une application, tel qu'un navigateur web, par exemple sous la forme motl/mot2 . La fonction de renvoi 214 dénommée « smubit » à titre d'exemple renvoie les variables motl et mot2 vers le navigateur 212 proprement dit au sein duquel le traitement ci-dessous peut être effectué. La fonction de renvoi 214 interagit avec une autre application, par exemple l'interface web 202 ou le navigateur 212 proprement dit, pour prélever les variables du SMUB.
Le poste utilisateur 200 peut comprendre une commande vocale 216, par exemple comprenant un microphone et un logiciel de reconnaissance tel que « Dragon Naturally Speaking » ®. La commande vocale 216 peut commander le remplissage de fenêtres pour renseigner les variables du SMUB, et leur validation.
Dans ce cas, le module d'appel 242, après avoir vérifié qu'il ne s'agit pas d'un SMUB local, interrogera l'utilisation au niveau du serveur SMUB internet 142. S'agissant d'un poste utilisateur ayant un ou des comptes ouverts, le serveur 142 peut lui faire accéder à tous les SMUBs, sous réserve de conditions que l'on verra plus loin.
Un SMUB peut être défini par son créateur comme public. Dans ce cas, n'importe quel poste tiers 300 pourra, à partir de son navigateur 312, procéder à un appel de SMUBs par la fonction 352, qui accède alors au serveur de SMUBs publics 152, lequel interroge le sous-ensemble des données SMUB stockées en 144 qui correspond à des SMUBs publics.
Les Tables 1 à 4 de l'annexe A donnent un exemple particulier de réalisation de l'invention. Dans ces tables, les données à caractère personnel sont fantaisistes, et ne visent pas à correspondre à des données réelles. C'est le cas notamment pour les adresses courriel, et les URL.
La Table 1 définit 3 utilisateurs ou acteurs différents, distingués par des adresses courriel différentes dans la colonne U_email. Un même acteur, par exemple a(α),b.com peut avoir trois alias distincts (également nommés nom courts, ou pseudo), par exemple "Jean", "Mickey" et "Jdupont", comme indiqué dans la colonne UjshortName. Certains au moins de ces alias peuvent avoir un nom long, comme indiqué dans la colonne UJongName. Un mot de passe de gestion du compte et des SMUBS est stocké dans la colonne VJPW. Enfin, chaque ligne possède un identifiant interne dans la colonne Intjd.
Suivant un choix de configuration du serveur, on peut prévoir :
- soit que le mot de passe est associé à un compte utilisateur, et reste le même pour les différents alias de celui-ci,
- soit que chaque alias est associé à un mot de passe qui lui est propre, et qu'il n'y a pas de mot de passe associé au compte utilisateur,
- soit encore qu'il existe à la fois un mot de passe « compte » associé à un compte utilisateur, et, en plus, un autre mot de passe pour chaque alias, avec des privilèges différents. Par exemple, le mot de passe « alias » permet de gérer des SMUBS associés à l'alias, mais pas ceux des autres alias. Ceci peut convenir par exemple, lorsque des personnes d'une même famille partagent la même adresse courriel.
La Table 2 est maintenant considérée. Chaque ligne possède un identifiant interne dans la colonne O_id. Cette table 2 définit la correspondance entre un SMUB, déterminé par les colonnes U_shortName et suffix, et une adresse sur le réseau étendu, ou bien sur un lecteur interne (voire externe) du poste de l'utilisateur, définie dans la colonne URL, laquelle est assortie d'une colonne d'identifiants URUd. On prévoit très avantageusement une colonne, notée U_priv, pour une indication de niveau, et/ou une colonne d'intitulé, notée Title.
On voit par exemple que, sous ses trois alias différents de la Table 1, l'utilisateur dont l'adresse courriel est a@b.com dans la Table 1 possède en tout 6 lignes de SMUBs dans la table 2. La seconde Oid2 permet de pointer sur son disque dur interne (C:). La dernière Oid6 permet de pointer sur une adresse courriel. Les autres visent des emplacements ou adresses indirectes sur le réseau étendu, ici Internet. L'homme du métier comprendra pour le reste la structure de la Table 2, dont le fait que le premier chiffre de l'identifiant d'URL URLid est spécifique de l'alias concerné UjShortName.
Comme l'illustre aussi la table 2, le même SMUB (« Jean/Paris ») peut viser plusieurs URL différentes. L'appel de ce SMUB se produira alors par l'affichage des différentes URL pour choix, par exemple en liste ou tableau.
La Table 3 est maintenant considérée. Chaque ligne possède un identifiant interne dans la colonne KW_id. La colonne KW contient des mots-clés tirés ici de la colonne d'intitulé TUIe de la Table 2. La colonne Oid contient, ici sous forme de liste, les identifiants des lignes de la table 2 dont l'intitulé contient le mot-clé de la ligne. Pour simplifier, la Table 3 ne comprend que quelques uns des mots clés de la Table 2. Les mots non discriminants, comme "My" ou "to" dans "My trip to Paris", peuvent être ignorés. Par ailleurs, certains mots peuvent être interprétés, comme "Yellow pages", converti en "Directory".
Réciproquement, une conversion en "Directory", pourra être faite sur présentation de "Yellow Pages" comme mot-clé pluri-terme (si un mot-clé pluri-terme est admis), ou encore sur présentation de "Yellow" et "pages" comme deux mots-clés uni-termes (un seul mot à la fois).
Les mots-clés ne sont pas nécessairement stockés dans le titre. Ils peuvent être stockés directement au niveau de la Table 3, en correspondance de l'Oid du SMUB en cours.
De préférence, on laisse l'utilisateur saisir ses propres mots clés, notamment au vu du titre. Cela fournit une indexation humaine des contenus des URL, qui est beaucoup plus précise et fiable qu'un système d'indexation automatique, statistiquement du moins. Si l'utilisateur ne saisit pas spontanément de mot-clé, on peut prévoir que le système propose un titre tiré de l'URL, et des mots clés tirés de ce titre, que l'utilisateur valide, après les avoir éventuellement modifiés.
Il est maintenant fait référence à la Table 4. Les colonnes Int id owner et Int id links désignent des alias, par leur identifiant Intjd dans la table 1. Bien entendu, la présentation de la Table 4 n'est qu'un exemple, et l'on pourrait concevoir le contenu des cases Intjdjinks comme une liste de valeurs Uid.
Dans la Table 5, la colonne Intjdjinks a le même sens que dans la Table 4, mais ici sous la forme d'une liste, et la colonne Oid désigne un SMUB auquel l'utilisateur de la colonne Intjdjinks peut accéder. Ici :
- les Oid de la Table 5 doivent correspondre à des SMUBs de niveau 1 (sphère privée) dans la Table 2, et - un utilisateur présent dans la colonne Intjdjinks de la Table 5 en regard d'un Oid doit être également présent dans la table 4 en regard du propriétaire (créateur) du SMUB qui correspond à cette Oid.
Il est maintenant fait référence au diagramme de flux de la figure 3. Celui-ci représente la fonction « ouvrir un compte », notée 410. Pour cela, il convient d'abord d'aller sur le site du serveur, comme indiqué par l'opération 412. Le serveur est noté ici http://smub.com.
L'opération suivante 414 consiste à ouvrir un compte personnel. Il est actuellement préféré que l'identifiant personnel soit l'adresse courriel (e-mail) de l'utilisateur, selon la table 1.
L'utilisateur peut alors créer un ou plusieurs alias, sur la base de ce compte personnel, comme indiqué pour l'opération 415. On pourra désigner dans la suite un alias (et par conséquent un utilisateur), par son identifiant dans la table 1, par exemple Uidl .
L'opération 416 permet alors au créateur d'un alias de saisir les alias de tiers qui font partie de sa sphère privée. L'utilisateur créateur doit saisir un alias de tiers. Le système en vérifie l'existence, puis crée une ligne dans la table 4 (par exemple la première) avec en Intjdjowner l'identifiant Uidl de l'alias concerné de l'utilisateur créateur, et en colonne Intjdjinks l'identifiant Uid4 de l'alias du tiers. Ainsi, un autre utilisateur qui s'est donné l'alias Uid4 se trouve inclus dans la sphère privée de l'utilisateur qui s'est donné l'alias Uidl. Cela suppose que l'autre utilisateur Uid4 a communiqué son alias à l'utilisateur Uidl . Cela se fait en principe par communication personnelle directe ou indirecte. Toutefois, on peut aussi prévoir dans le système un mécanisme d'extension de la sphère privée, par exemple sur la base du principe "un ami d'un ami peut devenir un ami". On suppose qu'un alias utilisateur Uid9 (non représenté dans la table 1 ) fait partie de la sphère privée de l'alias utilisateur Uid4. Comme Uid4 fait lui-même partie de la sphère privée de Uidl , Uid9 peut s'en prévaloir pour demander à Uidl de faire partie de sa propre sphère privée. Pour cela, on peut communiquer à Uid9 l'adresse courriel de Uidl (exclusivement) ; de préférence, la requête de Uid9 est enregistrée par le système, qui se charge lui-même de poser la question à Uidl, et d'inclure Uid9 dans la sphère privée de Uidl en cas de réponse positive. Cette fonction de mise en relation, connue, n'est pas représentée.
Pour chaque alias, l'utilisateur créateur pourra créer également un ou plusieurs jeux de données SMUB (voir Table 2). Cela se fait de préférence à partir des favoris du poste, comme indiqué à l'opération 417. On peut par exemple rapatrier tous les favoris, et proposer, pour un ou des alias UjShortNamβ, d'utiliser I1URL du favori comme champ URL, une proposition (modifiable) tirée du nom du favori comme champ Suffix, et le nom du favori (modifiable) comme champ Titie. Les champs identifiants Oid et URLid sont créés comme à l'accoutumée, par incrémentation automatique par exemple.
Avant la fin 420, optionnellement, l'opération 418 consiste à dupliquer les données SMUB distantes, présentes sur le serveur, vers le poste local.
La figure 4 illustre la fonction utilisation d'un SMUB. On se place dans le cas de la figure 2, où il existe une réplication locale des données SMUB.
À l'opération 452, la fonction 242 interroge la mémoire SMUB locale 244, et celle-ci retourne une adresse indirecte réseau (ou URL) cible, si les conditions du SMUB sont vérifiées. Si tel est le cas, PURL cible est retournée au navigateur par l'opération 454, et c'est terminé en 460. S'il y a plusieurs URL pour le même SMUB (voir « Jean/Paris » dans la Table 2), alors un choix est proposé à l'utilisateur. Si l'opération 452 a été un échec, il y a alors appel du site distant 456 avec une requête relative au SMUB désiré. (C'est en principe un SMUB créé par un autre utilisateur.). Là aussi, en 458, on peut recevoir une URL cible, auquel cas, on continue en 454 comme précédemment. Sinon, on procède en 462 un traitement d'erreur approprié.
La figure 5 est le diagramme de flux de la création/modification d'un SMUB. L'opération d'entrée 510 rappelle qu'il s'agit de créer/modifier un SMUB. Ensuite, l'opération 512 consiste à aller sur le site du serveur, noté par convenance http://smub.com.
L'opération 514 consiste à se connecter au compte personnel sur le site, si ce n'est pas déjà fait. Ensuite, l'opération 520 permet de choisir l'un des alias du compte personnel auquel l'utilisateur s'est connecté.
Le test 530 permet de choisir entre la création d'un nouveau SMUB ou la modification d'un SMUB existant.
S'il s'agit de créer un nouveau SMUB, l'opération 532 consiste en la désignation par l'utilisateur d'une URL vraie, c'est-à-dire d'une adresse indirecte étendue existant (ou présumée exister) sur le réseau étendu, ou bien d'une adresse sur son poste de travail.
Par contre, ici, la modification d'un SMUB ne permettra que de modifier son URL à l'opération 533, et/ou son suffixe à l'opération 536 décrite ci-après.
Par défaut, et dans un mode de réalisation particulier, la structure du SMUB créé répond à un format prédéterminé qui comprend deux mots, notés génériquement <mot 1 > et <mot2>, respectivement, avec un séparatif prédéfini (ici "/") entre ces deux mots. Ce format peut donc s'écrire :
<motl>/<mot2>
On note génériquement <U_alias> un alias d'utilisateur. Un appel d'adresse est valide s'il est de la forme
< U alias >/<mot2> Dans la suite du diagramme de la Figure 5, on prévoit de préférence une opération 534 par laquelle le système propose, pour <mot2>, un suffixe par défaut pour compléter l' alias qui forme la première partie du SMUB, et vérifiant la condition d'unicité du SMUB.
En 536, l'utilisateur peut décider d'ajuster le suffixe, auquel cas le test 538 vérifie que l'ensemble <U_alias> et <suffixe> est unique. Si cela n'est pas, l'ajustement de suffixe est poursuivi en 539 jusqu'à satisfaction de la condition d'unicité.
Le SMUB en lui-même est alors complètement défini.
Ensuite sont prévues des opérations optionnelles (individuellement) :
- Opération 540, ce qui permet de définir un titre pour le couple alias + suffixe formant le SMUB,
- l'opération 545 permet de définir des mots-clés descriptifs associés à l'URL réel visé par le SMUB, ou bien à l'idée qu'en a l'utilisateur,
- l'opération 550 permet de définir un niveau. Dans le mode de réalisation décrit sont prévus trois niveaux : personnel, privé et public.
Ensuite, l'opération 555 consiste à construire l'URL SMUB = <alias>/<suffixe>, de sorte qu'elle soit directement accessible sur le site par une phrase d'interrogation qui pourrait être du genre : http://SMUB.com /<U_alias>/<suffixe>
Dans une variante intéressante, il est ajouté une ou des fonctions additionnelles aux fonctions naturelles du navigateur. Un exemple de fonction additionnelle consiste à créer un SMUB à partir d'une URL en cours dans le navigateur. Cette fonction est activée (ou visible), par exemple sous la forme d'un bouton poussoir à l'écran, si l'utilisateur est déjà connecté à son compte personnel sur le site SMUB, avec l'un des alias de ce compte personnel. Dans ce cas, par rapport à la figure 5, l'actionnement du bouton poussoir permet de sauter directement à l'opération 534 de définition du SMUB. On peut concevoir d'autres fonctions, ou des variantes, comme inscrire l'URL en cours du navigateur comme SMUB sur un ou plusieurs des alias du compte encours, après choix dans une liste d'alias. En bref, dans l'exemple décrit, le format générique d'un SMUB est :
<motl>/<mot2>
On note génétiquement <U_alias> un alias existant d'utilisateur, et <sufiβχe> un suffixe existant pour cet alias. Un appel d'adresse est valide s'il est de la forme
< U_alias >/<suffïxe> tandis que < U alias > est contenu dans les colonnes U_ShortName des tables 1 et 2, et <suffixe> est contenu dans la colonne Suffix de la table 2 en regard de < U alias > dans la colonne UJShortNamβ.
Ainsi, l'appel d'adresse par SMUB est accepté après vérification d'une première condition, qui implique l'une au moins des sous-conditions suivantes : a. le respect de la règle de nommage, ici la forme <motl>/<mot2>, b. le fait que <motl> soit un alias d'utilisateur enregistré < U alias >, figurant en colonne UjShortName dans la table 1 et/ou la table 2, et c. le fait que <mot2> soit un <suffixe> figurant en colonne Suffix en regard de <U_alias> dans la colonne UjShortName dans la table 2.
La première condition peut s'arrêter là pour les SMUBs classés publics (dans l'exemple, de niveau 0 dans la table 3). Elle est plus sévère pour les autres niveaux, puisqu'il s'y ajoute une ou des sous-conditions supplémentaires liées au niveau. On peut utiliser par exemple le fait que l'utilisateur qui appelle le SMUB ait ouvert une "session SMUB" sur le serveur, ce qui l'identifie. Dans ce cas :
- dans l'exemple décrit, un SMUB privé (niveau 1) n'est accessible que si l'alias appelant possède un Uid qui figure dans la table 4 en regard de l'Uid du créateur du SMUB, et si, dans la Table 5, l'Uid de ce même appelant figure en regard de l'Oid du SMUB considéré.
- un SMUB personnel (niveau 2) n'est accessible que si l'appelant est celui qui a créé le SMUB. Le fonctionnement dépend ici du mode d'utilisation des mots de passe dans la table
1. S'il n'y a qu'un seul mot de passe pour un utilisateur donné, quel que soit son alias, alors le SMUB personnel est accessible à l'utilisateur, quel que soit son alias. Si au contraire on prévoit un mot de passe différent pour chaque alias d'un même utilisateur, et que ce mot de passe d'alias est demandé à l'ouverture de la "session SMUB", alors on peut prévoir qu'un SMUB personnel n'est accessible qu'à un seul alias d'utilisateur.
On notera que l'ouverture de session n'est pas nécessaire lors d'un appel de SMUB 242 en mode local, puisque l'utilisateur est généralement connu par le système d'exploitation du poste local.
Il est maintenant fait référence à la figure 6, qui illustre sur un exemple les possibilités offertes à un utilisateur accédant au serveur http://SMUB.com.
À l'accès au serveur 600, l'utilisateur entrant peut ouvrir une session en 602, s'il dispose d'un compte. Si aucune session n'est ouverte (604), l'utilisateur entrant n'a qu'un accès restreint aux SMUBS publics (base de données 152 sur la figure 2). Si une session est ouverte (608), l'utilisateur entrant a potentiellement accès à tous les SMUBs (base de données 142 sur la figure 2), sous réserve des conditions applicables aux SMUBs privés et personnels.
Ensuite, un écran lui est offert avec trois possibilités :
- en 612, désigner directement un SMUB, en tant que requête dans la base de données concernée,
- en 622, faire une recherche par mots clés, dans la base de données concernée,
- en 642, faire une recherche par alias (par exemple), dans la base de données concernée.
En pratique, l'ouverture de session pourra être incluse comme une option dans l'écran qui vient d'être défini, le mode par défaut (sans session ouverte) étant l'accès aux seuls SMUBs publics. On peut aussi inclure dans cet écran d'autres fonctions, notamment des fonctions déjà décrites, comme l'ouverture d'un compte, et/ou la gestion des SMUBs d'un compte déjà ouvert, ou d'autres fonction de requête ou de recherche que celles ici décrites.
Il est maintenant fait référence à la figure 7 qui illustre le diagramme de flux de l'utilisation directe 612 d'un SMUB. L'opération 614 consiste à vérifier la forme du SMUB, pour le découper afin d'interroger correctement la Table 2. Cette vérification de forme peut être directement associée à la zone de saisie du SMUB dans la requête 612 de la figure 6.
Ensuite, il est procédé en 616 à une recherche dans la table 2, pour déterminer s'il existe le couple <motl>, <mot2> avec une URL en correspondance. Si oui, alors on retourne l'URL cible ainsi trouvée à l'opération 664. Sinon, c'est un échec 618, sur lequel on peut par exemple offrir à nouveau l'écran de saisie de la figure 6. On notera ici que l'opération 614 n'est pas absolument impérative, puisqu'une requête SMUB incorrecte se traduira en principe par un échec.
Sur la figure 6, l'appel 600 peut être accompagné d'un SMUB comme paramètre, auquel cas on passe directement à l'exécution de la requête correspondante de la Figure 7.
II est maintenant fait référence à la figure 8 qui illustre le diagramme de flux de la recherche par mots clés 622.
L'opération 624 recherche dans la table 3 selon le ou les mots-clés choisis par l'utilisateur. Par exemple, le seul mot-clé "Paris" donne la liste "Oid1 , Oid2, Oid3" dans la Table 3. Mais si l'on prend (par exemple avec un séparatif, ou une zone de saisie multiple) les deux mots-clés "Paris" et "Hôtel", il ne reste alors, par croisement, que "Oid1".
On admet qu'en 625, il est trouvé un ou plusieurs identifiants de SMUB (« Oid ») dans la table 3. Alors, l'opération 626 va chercher dans la table 2 la ou les URL correspondant à ce ou ces « Oid », et propose cette ou ces URL comme choix à l'utilisateur. Cela peut se faire par un tableau, dont chaque ligne indique l'URL trouvée. Le tableau peut comporter une ou des colonnes supplémentaires, pour donner des informations additionnelles, comme ceux des mots-clés qui correspondent à l'Oid de l'URL de la ligne, ou encore le SMUB et/ou le titre correspondant à cet Oid dans la table 2, ou le nom long correspondant à la partie alias du SMUB dans la table 1.
Si, en 627, l'utilisateur accepte l'une des URL proposées, alors on retourne l'URL cible sélectionnée à l'opération 664.
Si l'utilisateur refuse en 627, on va en échec 628. On va de même en échec (au besoin avec un message approprié) si rien n'a été trouvé à l'opération 625. Sur un échec, on peut par exemple offrir à nouveau l'écran de saisie de la figure 6, comme précédemment.
Il est maintenant fait référence à la figure 9 qui illustre le diagramme de flux de la recherche 642 par alias.
L'opération 644 recherche s'il existe un ou des alias vérifiant la condition de recherche (par exemple le début de l'alias) dans la table 1. Si oui, l'opération 646 proposer le ou les SMUB déjà définis et correspondant à cet/ces alias dans la table 2. Si, en 647, l'utilisateur accepte le SMUB proposé (l'un des SMUBs proposés s'il y en a plusieurs), alors on retourne l'URL cible correspondante à l'opération 664. S'il y a plusieurs SMUBs proposés, il peuvent être présentés en tableau, avec une ou plusieurs colonnes supplémentaires pour présenter des informations additionnelles, par exemple, s'il existe, le nom long correspondant à chaque alias dans la table 1.
Le même genre de recherche peut être fait sur d'autres éléments contenus dans les tables, par exemple le nom long. Dans ce cas, l'opération 644 recherche s'il existe un ou des alias vérifiant une condition de recherche sur un élément, par exemple un fragment, d'un nom long d'utilisateur. A cet égard, on notera dans la Table 1 que le nom long "Jean Dupont" permet d'accéder à l'alias "Jean", lequel permet (optionnellement) d'accéder à l'alias "Mickey", bien que ce dernier ne soit pas associé au nom long "Jean Dupont". On peut choisir par construction de ne proposer que les alias qui ont effectivement associés au nom long, ou au contraire de proposer tous les alias, qu'ils soient ou non associés au nom long recherché (cette dernière option peut être réservée aux usagers demandeurs qui ont accès à la sphère privée de l'utilisateur ayant le nom long).
Si l'utilisateur refuse en 647, on va en échec 648. On va de même en échec (au besoin avec un message approprié) si rien n'a été trouvé à l'opération 644. Sur un échec, on peut par exemple offrir à nouveau l'écran de saisie de la figure 6, comme précédemment. Comme le comprendra l'homme du métier, l'écran défini à propos de la figure 6 peut être conçu comme un formulaire événementiel, qui présente trois zones de saisie pour les opérations 612, 622 et 642, respectivement, et éventuellement d'autres zone ou boutons pour les autres fonctions mentionnées. L'usager remplit celle des zones pour laquelle il entend rechercher un SMUB, et cette saisie déclenche l'opération correspondante. Cependant, si un SMUB arrive au départ comme paramètre, on peut lancer directement la recherche en 612.
Bien entendu, on peut aussi croiser des conditions de recherche, par exemple croiser une recherche par alias avec une recherche par mots-clés.
L'invention n'est pas limitée aux modes de réalisation ci-dessus décrits mais en embrasse toutes les variantes contenues dans le cadre des revendications ci-après, notamment les suivantes : a. le format générique d'un SMUB étant du genre <motl>/<mot2>, ou semblable, on peut aussi ajouter des contraintes sur la longueur de <motl> et/ou <mot2> ; b. on pourrait se passer du séparatif (la barre oblique) dans certains cas, par exemple si <motl> est de longueur fixe, ou bien si <mot2> commence par une majuscule, tout le reste étant en minuscules. c. Les exemples de tables donnés sont illustratifs ; il est possible de découper certaines au moins des tables, par exemple en stockant à part les URL, associées à leur identifiant URL_id. Il est également possible de les regrouper au moins partiellement, quitte à créer une certaine redondance. d. La condition d'unicité des SMUBs n'est pas absolument impérative. On pourrait admettre des doublons, dès lors que ceux-ci sont signalés, et/ou que le créateur de doublons puisse lever cette ambiguïté. e. Le poste utilisateur peut comprendre une fonction d'utilisation de la barre d'entrée de commande d'un logiciel présent sur ledit poste. f. Le poste utilisateur peut comprendre une liaison avec une commande vocale.
Des règles particulières peuvent être définies. Par exemple, on peut prévoir que <mot2> est nécessairement une chaîne de caractères ne comprenant pas le séparatif prédéfini (1V"), ou même ne comprenant que des lettres et des chiffres, tandis que <motl> peut être une chaîne de caractères quelconque, qui peut même comprendre le séparatif prédéfini (ici la barre oblique "/"). Dans ce cas, on peut distinguer <motl> et <mot2>, et les séparer l'un de l'autre, en faisant une recherche de « / » à partir de la droite dans la chaîne de caractères complète du SMUB qui est de la forme <motl>/<mot2>.
Ceci peut permettre notamment de faciliter la création d'alias aux nombreux utilisateurs potentiels prénommés "Jean", en incorporant une partie de leur nom de famille dans l'alias. On peut alors distinguer par exemple les alias "Dup/jean" et "Pla/jean".
Les exemples donnés pour la « première condition », ses sous-conditions, ainsi que les conditions additionnelles liées aux niveaux sont illustratifs et non limitatifs. On pourra naturellement construire différemment des conditions équivalentes, et en éliminer les éventuelles redondances.
De même, le nombre de niveaux, et les sous-conditions associées à chacun des niveaux (autres que « public ») ne sont pas limitatives. On pourrait, dans certains cas du moins, définir la sphère privée (au moins partiellement) non pas par ceux qui y sont inclus, mais par ceux qui en sont exclus. La même remarque s'applique aux SMUBs de la sphère privée.
Dans ce qui précède, un "alias" est supposé non modifiable. On peut seulement le détruire, le cas échéant. Une variante consisterait à autoriser la modification d'un alias. Cela impliquerait soit de modifier en conséquence tous les SMUBs qui découlent de l'alias modifié (au besoin en conservant temporairement les SMUBs composés avec l'ancien alias), ou encore de supprimer tous les SMUBs qui découlent de l'alias, en forçant ainsi leur recréation à volonté.
Par ailleurs, d'autres formes de procédés selon l'invention peuvent être tirées de la description qui précède, notamment en liaison avec les dessins.
Bien entendu, certains des moyens décrits ci-dessus peuvent être omis dans les variantes où ils ne servent pas. Table 1
K)
Figure imgf000022_0001
o
Figure imgf000022_0002
Figure imgf000023_0002
Figure imgf000023_0001
Figure imgf000023_0003
Figure imgf000023_0004
LO

Claims

Revendications
1. Serveur d'adresse réseau indirecte, du genre comprenant :
- un stockage (144) de correspondances entre des appels d'adresse et des adresses réseau, et
- un service de fourniture d'adresse (142) , agencé pour répondre à la présentation d'un appel d'adresse en restituant une adresse réseau qui lui correspond, caractérisé en ce qu'il comprend une gestion de comptes d'utilisateurs (1.12),
- en ce que le stockage (144) de correspondances entre des appels d'adresse et des adresses réseau comprend des appels d'adresse stockés comme des multiplets d'un format prédéterminé, ce format comprenant un élément lié à un utilisateur muni d'un compte selon une règle de nommage prédéterminée, tandis que les adresses réseau sont des adresses indirectes, et en ce que le service de fourniture d'adresse (142) est agencé pour répondre à un appel d'adresse sous la forme d'un multiplet possédant ledit format prédéterminé en restituant l'adresse indirecte réseau qui correspond à ce multiplet, sous réserve de vérification d'une première condition, qui implique le lien à un utilisateur selon ladite règle de nommage prédéterminée.
2. Serveur d'adresse réseau selon la revendication 1, caractérisé en ce que le stockage d'un appel d'adresse (144) comprend en outre une indication de niveau, définie par l'utilisateur, et en ce que ladite première condition fait intervenir aussi l'indication de niveau.
3. Serveur d'adresse sur réseau selon l'une des revendications 1 et 2, caractérisé en ce que la gestion de comptes utilisateurs (114) est agencée de sorte que chaque compte utilisateur soit associé à au moins un alias d'utilisateur, et en ce que la règle de nommage comprend l'insertion d'un alias utilisateur en position prédéfinie dans ledit format prédéterminé.
4. Serveur d'adresse réseau selon la revendication 3, caractérisé en ce que le format prédéterminé comprend l'alias utilisateur, suivi d'un séparatif, puis d'un suffixe.
5. Serveur d'adresse réseau selon l'une des revendications 3 et 4, caractérisé en ce qu'il comprend un outil d'ouverture de session utilisateur, et en ce que ladite première condition fait intervenir aussi le fait que l'appel d'adresse provient d'un utilisateur qui possède une session ouverte avec habilitation au niveau voulu pour cet appel d'adresse.
6. Serveur d'adresse réseau selon l'une des revendications 3 à 5, caractérisé en ce que le stockage d'un appel d'adresse (144) comprend en outre un intitulé, défini par l'utilisateur, en ce que le serveur comprend en outre un outil de recherche par mots-clés tirés des intitulés (136), capable de pointer sur un ou des appels d'adresse dont l'intitulé comporte le ou les mots-clés présentés, sous réserve de vérification de la première condition, et en ce que le service de fourniture d'adresse (142 ; 152) est également agencé pour permettre la recherche par mots-clés, afin d'obtenir une adresse indirecte sur le réseau étendu.
7. Serveur d'adresse réseau selon l'une des revendications 3 à 6, caractérisé en ce que la gestion de comptes utilisateurs (114) comprend une première table comportant, pour chaque ligne, un identifiant d'utilisateur, un alias d'utilisateur, ainsi qu'une donnée de contrôle, et - ledit stockage de correspondances (144) comprend une seconde table comportant, pour chaque ligne, un alias d'utilisateur, une représentation de l'adresse d'une connexion sur le réseau étendu, ainsi qu'une indication de niveau.
8. Serveur d'adresse réseau selon la revendication 7, caractérisé en ce que le service de fourniture d'adresse (142 ; 152) est également agencé pour permettre la recherche par alias, afin d'obtenir une adresse indirecte sur le réseau étendu.
9. Poste informatique utilisateur, comprenant un navigateur (212 ; 312), caractérisé en ce qu'il comprend un mécanisme (242;352) capable d'établir une connexion vers un serveur d'adresse indirecte réseau selon l'une des revendications précédentes, la connexion comportant un paramètre comprenant un appel d'adresse sous forme d'un multiplet d'un format prédéterminé, et, sur retour confirmé, d'actionner le navigateur (212 ; 312) avec une partie au moins des données de retour en tant qu'adresse réseau.
10. Poste informatique utilisateur selon la revendication 9, caractérisé en ce qu'il comprend une réplication locale (244) du service de fourniture d'adresses, pour les multiplets correspondant à un utilisateur du poste, cette réplication locale interrogeant le serveur d'adresse (142) pour les multiplets ne correspondant pas à un utilisateur en cours du poste.
1 1. Procédé d'aide à la navigation informatique, dans lequel on prévoit un serveur muni d'un stockage de correspondances entre des appels d'adresse et des adresses réseau, et d'un service de fourniture d'adresse, agencé pour répondre à la présentation d'un appel d'adresse en restituant une adresse réseau qui lui correspond, ce serveur étant interrogé afin d'atteindre un emplacement réseau, caractérisé en ce qu'il comprend les étapes suivantes : a. maintenir sur le serveur une gestion de comptes utilisateurs (114), b. stocker sur le serveur des correspondances (144) entre des appels d'adresse et des adresses indirectes réseau, comprenant des appels d'adresse stockés comme des multiplets d'un format prédéterminé, ce format comprenant un élément lié à un utilisateur selon une règle de nommage prédéterminée, c. agencer le service de fourniture d'adresse (142 ; 152) pour répondre à un appel d'adresse sous la forme d'un multiplet possédant ledit format prédéterminé en restituant l'adresse sur le réseau étendu qui correspond à ce multiplet, sous réserve de vérification d'une première condition, qui implique le lien à un utilisateur selon ladite règle de nommage prédéterminée, et d. munir au moins un poste utilisateur (200 ; 300) d'un mécanisme capable d'établir une connexion vers ledit serveur, la connexion permettant un appel d'adresse sous forme d'un multiplet au format prédéterminé, et, sur retour confirmé, d'actionner le navigateur avec les données de retour en tant qu'adresse indirecte réseau.
12. Procédé selon la revendication 11, caractérisé en ce qu'il comprend en outre l'étape suivante : e. munir au moins un poste utilisateur d'un mécanisme (210) d'accès à un compte, capable d'interagir avec la gestion de compte utilisateurs (114) de l'étape a.
13.Procédé selon la revendication 12, caractérisé en ce qu'il comprend en outre l'étape suivante : f. munir le poste de l'étape e. d'une réplication (244) du service tel qu'agencé à l'étape c.
14.Procédé selon l'une des revendications 11 à 13, caractérisé en ce que :
- le stockage de l'étape b. comprend en outre, pour chaque correspondance, une indication de niveau, et
- la première condition de l'étape c. tient compte aussi de l'indication de niveau.
15. Procédé selon l'une des revendications 11 à 14, caractérisé en ce que la gestion de comptes utilisateurs (114) de l'étape a. est agencée de sorte que chaque compte utilisateur soit associé à au moins un alias d'utilisateur, et en ce que la règle de nommage de l'étape b. comprend l'insertion d'un alias utilisateur en position prédéfinie dans ledit format prédéterminé.
16. Procédé selon la revendication 15, caractérisé en ce que le format prédéterminé comprend l'alias utilisateur, suivi d'un séparatif, puis d'un suffixe.
17. Procédé selon l'une des revendications 11 à 16, caractérisé en ce que l'étape c. comprend une offre d'ouverture de session utilisateur (602), et en ce que ladite première condition de l'étape c. fait intervenir aussi le fait que l'appel d'adresse provient d'un utilisateur qui possède une session ouverte avec habilitation au niveau voulu pour cet appel d'adresse.
18. Procédé selon l'une des revendications 11 à 17, caractérisé en ce que le stockage d'un appel d'adresse (144) à l'étape b. comprend en outre le stockage d'un intitulé, défini par l'utilisateur, en ce que l'étape c. comprend en outre une offre de recherche par mots-clés tirés des intitulés (136), capable de pointer sur un ou des appels d'adresse dont l'intitulé comporte le ou les mots-clés présentés, sous réserve de vérification de la première condition, afin d'obtenir au moins une adresse indirecte sur le réseau étendu.
19. Procédé selon l'une des revendications 11 à 18, caractérisé en ce que
- la gestion de comptes utilisateurs (114) de l'étape a. comprend une première table comportant, pour chaque ligne, un identifiant d'utilisateur, un alias d'utilisateur, ainsi qu'une donnée de contrôle, et
- ledit stockage de correspondances (144) de l'étape b. comprend une seconde table comportant, pour chaque ligne, un alias d'utilisateur, une représentation de l'adresse d'une connexion sur le réseau étendu, ainsi qu'une indication de niveau.
20.Procédé selon la revendication 19, caractérisé en ce que l'étape c. est également agencée (142 ; 152) pour permettre la recherche par alias, afin d'accéder à un ou des multiplets, permettant d'obtenir au moins une adresse indirecte sur le réseau étendu.
PCT/FR2009/000236 2008-03-14 2009-03-06 Service d'adresse indirecte de connexion sur réseau étendu WO2009118477A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP09725837A EP2253105A2 (fr) 2008-03-14 2009-03-06 Service d'adresse indirecte de connexion sur réseau étendu

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
FR0801417A FR2928799B1 (fr) 2008-03-14 2008-03-14 Service d'adresse indirecte de connexion sur reseau etendu
FR08/01417 2008-03-14
FR08/02782 2008-05-22
FR0802782 2008-05-22

Publications (2)

Publication Number Publication Date
WO2009118477A2 true WO2009118477A2 (fr) 2009-10-01
WO2009118477A3 WO2009118477A3 (fr) 2009-12-30

Family

ID=41062966

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2009/000236 WO2009118477A2 (fr) 2008-03-14 2009-03-06 Service d'adresse indirecte de connexion sur réseau étendu

Country Status (3)

Country Link
US (1) US20090232134A1 (fr)
EP (1) EP2253105A2 (fr)
WO (1) WO2009118477A2 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9094235B2 (en) * 2012-11-28 2015-07-28 Dell Products L.P. Systems and methods for link bandwidth conservation in a local area network connected to a trill network

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997019564A2 (fr) * 1995-11-07 1997-05-29 Netword Llc Systeme universel de denotation, de demande et de fourniture de ressources electroniques
EP0889418A2 (fr) * 1997-06-30 1999-01-07 Sun Microsystems, Inc. Résolution d'adresses URL abstraites par un service de redirection
EP0987868A2 (fr) * 1998-09-14 2000-03-22 Phone.Com Inc. Procédé et architecture pour l'interaction de dispositifs interactifs à deux voies avec un réseau
EP1118947A1 (fr) * 2000-01-19 2001-07-25 Lucent Technologies Inc. Résolution hiérarchique d'adresses dans un réseau de données
EP1154611A2 (fr) * 2000-05-08 2001-11-14 Internet Number Corporation Procédé et système d'accès à des informations dans un réseau avec des fonctions de messages alias comprenant des fonctions fantômes de rappel
GB2364409A (en) * 2000-05-22 2002-01-23 Bango Net Ltd Mapping URL addresses to secondary addresses or short-cuts

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5864676A (en) * 1996-11-14 1999-01-26 Triteal Corporation URL login
US8037168B2 (en) * 1999-07-15 2011-10-11 Esdr Network Solutions Llc Method, product, and apparatus for enhancing resolution services, registration services, and search services
US6493702B1 (en) * 1999-05-05 2002-12-10 Xerox Corporation System and method for searching and recommending documents in a collection using share bookmarks
US6321228B1 (en) * 1999-08-31 2001-11-20 Powercast Media, Inc. Internet search system for retrieving selected results from a previous search
US6668376B1 (en) * 2000-01-07 2003-12-23 Ricoh Company, Ltd. System and method for automatically loading a device driver
JP2002077452A (ja) * 2000-09-01 2002-03-15 Matsushita Electric Ind Co Ltd 情報通信装置、情報通信方法および記録媒体
JPWO2002042920A1 (ja) * 2000-11-22 2004-04-02 株式会社エヌ・ティ・ティ・ドコモ ネットワークへのアクセスを管理する方法および装置
EP2261796A3 (fr) * 2001-05-14 2011-02-23 NTT DoCoMo, Inc. Système de gestion de programme stocké dans un bloc de stockage d'un terminal mobile
US20070198246A1 (en) * 2004-03-03 2007-08-23 Goradia Gautam D Interactive system for building, organising, and sharing one's own encyclopedia in one or more languages
US7526472B2 (en) * 2005-03-11 2009-04-28 International Business Machines Corporation Shared bookmarks based on user interest profiles
PL378889A1 (pl) * 2006-02-04 2007-08-06 Iloggo Spółka Z Ograniczoną Odpowiedzialnością Raportowanie wyników wyszukiwania

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997019564A2 (fr) * 1995-11-07 1997-05-29 Netword Llc Systeme universel de denotation, de demande et de fourniture de ressources electroniques
EP0889418A2 (fr) * 1997-06-30 1999-01-07 Sun Microsystems, Inc. Résolution d'adresses URL abstraites par un service de redirection
EP0987868A2 (fr) * 1998-09-14 2000-03-22 Phone.Com Inc. Procédé et architecture pour l'interaction de dispositifs interactifs à deux voies avec un réseau
EP1118947A1 (fr) * 2000-01-19 2001-07-25 Lucent Technologies Inc. Résolution hiérarchique d'adresses dans un réseau de données
EP1154611A2 (fr) * 2000-05-08 2001-11-14 Internet Number Corporation Procédé et système d'accès à des informations dans un réseau avec des fonctions de messages alias comprenant des fonctions fantômes de rappel
GB2364409A (en) * 2000-05-22 2002-01-23 Bango Net Ltd Mapping URL addresses to secondary addresses or short-cuts

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"FREE BOOKMARK MANAGERS" INTERNET CITATION, [Online] XP002941075 Extrait de l'Internet: URL:HTTP://WWW.EMAILADDRESSES.COM/EMAIL_BOOKMARKS.HTM> [extrait le 2001-03-03] *
LI W-S ET AL: "PowerBookmarks: a system for personalizable Web information organization, sharing, and management" COMPUTER NETWORKS, ELSEVIER SCIENCE PUBLISHERS B.V., AMSTERDAM, NL, vol. 31, no. 11-16, 17 mai 1999 (1999-05-17), pages 1375-1389, XP004304561 ISSN: 1389-1286 *

Also Published As

Publication number Publication date
US20090232134A1 (en) 2009-09-17
WO2009118477A3 (fr) 2009-12-30
EP2253105A2 (fr) 2010-11-24

Similar Documents

Publication Publication Date Title
CN100547589C (zh) 用于处理搜索查询的方法和系统
EP1470501A2 (fr) Procedes et systemes de recherche et d&#39;association de ressources d&#39;information telles que des pages web
WO2009050345A2 (fr) Procede et dispositif de creation d&#39;applications informatiques
EP1836636A1 (fr) Support personnel de mémoire de masse portatif et système informatique d&#39;accès sécurisé a un espace utilisateur via un réseau
EP1590939A1 (fr) SYSTEME ET PROCEDE DE SYNCHRONISATION DE DONNEES ENTRE DES PORTAILS DE SERVICES ET DES PLATES-FORMES D&amp;rsquo;ACCES A DES SERVICES UTILISANT UN TEL SYSTEME DE SYNCHRONISATION
CN1732452A (zh) 用于自动启动和访问网络地址和应用程序的系统和方法
EP1977365B1 (fr) Procede de gestion de documents electroniques
Kunze et al. The ARK identifier scheme
WO2007141446A1 (fr) Système de gestion d&#39;un service interactif multimodal
EP1637989A1 (fr) Procédé et système de séparation de comptes de données personnelles
EP2253105A2 (fr) Service d&#39;adresse indirecte de connexion sur réseau étendu
FR2928799A1 (fr) Service d&#39;adresse indirecte de connexion sur reseau etendu
WO2012056169A1 (fr) Indexation et execution d&#39;applications logicielles dans un reseau
FR2930099A1 (fr) Procede et dispositif de routage de donnees
WO2002003245A1 (fr) Procede de stockage d&#39;objets informationnels au format xml dans une base de donnees relationnelle
WO2015049472A1 (fr) Procédé de dématérialisation d&#39;une démarche
WO2023118770A1 (fr) Système de distribution de contenu internet personnalisé
FR3030820A1 (fr) Procede pour l&#39;acces a un contenu numerique dans un reseau de communication, au moyen d&#39;un equipement terminal connecte audit reseau de communication
WO2007074284A2 (fr) Procede de creation d&#39;un profil utilisateur dans un systeme d&#39;information et systeme de gestion d&#39;identites numeriques
FR2919403A1 (fr) Procede et dispositif de transformation de pages de la toile pour affichage de liens
WO2001086496A1 (fr) Systeme et procede de traitement de donnes pour l&#39;acces cible a un serveur a partir d&#39;une interrogation en langage naturel
Christensen-Dalsgaard 1991 and networked interoperability
FR2829656A1 (fr) Procede d&#39;annotation de documents informatiques, et systeme associe
FR2901380A1 (fr) Support personnel de memoire de masse portatif et systeme informatique d&#39;acces securise a un espace utilisateur via un reseau
FR2901386A1 (fr) Support personnel de memoire de masse portatif et systeme informatique d&#39;acces securise a un reseau par des utilisateurs.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09725837

Country of ref document: EP

Kind code of ref document: A2

WWE Wipo information: entry into national phase

Ref document number: 2009725837

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE