EP2561454A1 - Système informatique de partage et procédé correspondant - Google Patents

Système informatique de partage et procédé correspondant

Info

Publication number
EP2561454A1
EP2561454A1 EP11720558A EP11720558A EP2561454A1 EP 2561454 A1 EP2561454 A1 EP 2561454A1 EP 11720558 A EP11720558 A EP 11720558A EP 11720558 A EP11720558 A EP 11720558A EP 2561454 A1 EP2561454 A1 EP 2561454A1
Authority
EP
European Patent Office
Prior art keywords
data
page
share
sharing
editor
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP11720558A
Other languages
German (de)
English (en)
Inventor
Thierry Lamouline
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Smub France
Original Assignee
Smub France
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Smub France filed Critical Smub France
Publication of EP2561454A1 publication Critical patent/EP2561454A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • G06F16/972—Access to data in other repository systems, e.g. legacy data or dynamic Web page generation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Definitions

  • the invention relates to the field of WAN computing.
  • the advent of the internet has provided new channels of expression for both individuals and publishers. This has been particularly reinforced with Web 2.0, in which social networks make it possible to share information more quickly.
  • Various technological solutions have been developed to allow Internet users to easily share an internet link of interest with their knowledge.
  • the invention improves the situation.
  • the invention proposes a computer system, arranged to access a wide area network that includes:
  • an extractor arranged to receive an access request and to derive a share page identifier and an editor profile identifier
  • a sifter arranged to derive share page data from a share page identifier
  • a engine arranged to generate a share page from share page structure data, share page data, and publisher profile data, and
  • a driver arranged to receive an access request from an element of the extended network, to call the screener with the share page identifier and the profile identifier editor defined by the extractor, for calling the engine with the resulting data and the sharing page structure data, and for returning the resulting page to said WAN element.
  • FIG. 1 represents a generic diagram of a computing environment in which the invention is implemented
  • FIG. 2 represents a flow diagram of an access to a sharing page according to the invention
  • FIG. 3 represents an exemplary partition page model produced according to the invention
  • FIG. 4 represents a flow diagram for creating and / or modifying an editor profile in the context of the invention
  • FIG. 5 represents a flow diagram for creating and / or modifying a sharing page in the context of the invention
  • FIG. 6 represents a partition page data generation flow diagram in the context of the invention.
  • FIG. 7 shows another example of page layout produced according to the invention.
  • FIG. 1 represents a generic diagram of an environment implementing a system according to the invention.
  • client stations 2 and 4 can communicate via an extended network 6 (for example the Internet) with a computer system 8 according to the invention.
  • the computer stations are a laptop 2 and a mobile phone 4.
  • the computer system 8 is in the example described here, a single-user web server.
  • This server can be made in any suitable form as a cluster of servers, possibly distributed in several different locations.
  • the main feature of the server 8 is its ability to receive requests for access to the sharing pages, and to provide them.
  • the laptop 2 and the phone 4 each include a character recognition program. This program makes it possible to detect a string of characters in an image processed by these devices.
  • This image can be recorded on the memory of these devices, or taken from a photographic sensor of the phone 4 or a webcam incorporated in the laptop 2.
  • the computer stations 2 and 4 also include a program arranged to send a request access to a share page on the server 8, which contains the text taken from the character recognition.
  • the access request program and the character recognition program may be incorporated into the same program, or may be separate elements invoked by another program.
  • an application can be made available to users.
  • This application is programmed for:
  • the server 8 comprises a driver 10, a management program 12, an extractor 13, a sifter 14 and an assembly motor 16, as well as memories 18, 20 and 22 for respectively storing profile data, page data. sharing and content data.
  • the memories 18, 20 and 22 can be physically connected to the server 8, or be accessible remotely. They can be performed within a single memory, or in separate memory units.
  • FIG. 2 represents an exemplary implementation of a request for access to a sharing page from the server 8.
  • a first operation 200 the computing device 2 or 4 generates a request for access to the sharing page. This operation is performed by a function Gen (), which generates the query from the string obtained as described above.
  • the Gen () function concatenates this string with a text string that forms a request skeleton.
  • the server 8 is a web server.
  • the function Gen () concatenates it with the address of the server 8 to which the access requests are sent.
  • the page that is invoked to view a share page can be a page "page_de_partage.htm" of the server 8.
  • the character string with which the character string will be concatenated then will be of the type http: // Server_L URL / Split_Page. html, where Server URL is the URL of server 8.
  • a Send () function is used to send this request to the server 8 in an operation 202.
  • This request is received by the server 8, and in an operation 204 it processes it and generates share page data that defines a share page that matches the string "recognized_text_string", using server-specific functions. 8 referred to here as the function Mk (ShPgDat).
  • the ShPDat page page data may vary depending on the origin of the access request to the shared page. Indeed, as will be seen in FIG. 6, the server 8 will not treat in the same way a request coming from a specific application and a request coming from a web browser.
  • FIG. 3 shows a split page skeleton that is populated with information obtained from the Req request by the server 8.
  • the zones EXT Z, PUB Z and TIT_Z are aligned vertically in this order, above areas ART Z and CONT_Z which are substantially parallel with each other in this order, and above the zone SOC_Z. All of these areas can be populated with various types of content that may vary depending on settings made by the publisher of the share page.
  • the zone Ext_Z is intended to receive elements outside the context of the shared page, and designated by the creator of the page. For example, this area may receive advertising data, which may allow the publisher to be paid based on their viewing. In addition, the content of these pages can be customized according to the data provided by the publisher of the page of sharing and the supplier of advertising pages.
  • the purpose of the Pub Z zone is to receive data that identifies the publisher of the sharing page. For example, when the share page is a page linked to an article in a magazine, the Pub Z area may receive a logo from the magazine or magazine publisher, as well as links to a subscription page or other. In the example described here, this zone is common to the sharing pages created by the same editor.
  • Tit_Z is intended to receive data that identifies the share page. This may for example be a title possibly associated with a content. This area is fully dynamic, that is, it changes with each new sharing page. It remains of course possible to use identical data for Tit_Z zones of two separate partition pages.
  • the purpose of the Art_Z zone is to receive data which constitutes the main content of the sharing page, that is to say the object of the sharing page itself.
  • This can for example be a photo accompanied by a text that summarizes the article, this area forming a hypertext link that leads to the actual address of the article that is the subject of this page of sharing. Again, this area is fully dynamic, that is, it changes with each new sharing page. It remains possible to use identical data for Art_Z zones of two separate sharing pages.
  • the Cont Z zone is intended to receive content data associated with the article presented in the Art_Z zone. These contents can be photos, videos, a link to a discussion forum on this article, one or more links to articles on the same theme, etc. The description in Figure 4 will show that this content can be particularly varied and again dynamic. Finally the Soc_Z area is intended to receive social sharing data from this page sharing. More precisely, this zone can receive two types of sharing elements:
  • social networking sites eg Facebook, Twitter, Digg, an email account or others
  • links to social networking sites are not just redirects to the main page of the site in question: they also contain command parameters necessary for sharing required by each site concerned. They could be interpreted as requests.
  • one or more backup links which will allow the user to save this page among his favorites in a service connected to the server 8 to which the user is subscribed, for later consultation with simplified access .
  • zone Pub_Z zone Soc_Z is in the example described here common to the pages of sharing created by the same publisher.
  • Figure 4 describes a function of creating / updating an editor profile for centralizing this information.
  • this function is implemented by a web page on the server 8 (or on another server) to which the editor accesses. It is the management program 12 that manages these pages as well as the entries and accesses to the memories 18, 20 and 22.
  • a program may be executed locally on a publisher machine, which executes the same operations as those described with the Figure 4, and that synchronizes this data with the publisher's profile on the server 8 later.
  • the U Profiler Profile is created.
  • this operation will be an authentication operation, for example by means of a pair of publisher name / password.
  • the publisher has access to a page which allows him to define the PubJD data of the zone Pub Z.
  • these data are common to the pages that are created by the publisher, and they make it possible to identify it clearly, for example by means of a logo and / or a name.
  • these data comprise a logo, which the publisher can pay directly to the server 8, or indicate by reference by giving a link from another server on which this logo is accessible, as well as two links hypertext.
  • the logo should be limited in size by the schema used for the shared page, as shown in Figure 3. This ensures that the publisher can not produce distorted pages by uploading a large logo size.
  • the server 8 may include an application that resizes a logo when it is too large.
  • the image data can for example be stored in the memory 22.
  • the two hypertext links can be customized by the editor to guide a user to links of interest. For example, one of the links can be customized to guide the user to a publisher's paper subscription page, and the other link can take the user to a page that allows them to subscribe to publisher information feeds, such as an RSS feed or an electronic newsletter.
  • this page may be in the form of a selection page where each social network is accompanied by an identification icon of this network and a box of type "radio button” or “check box "to select the corresponding network.
  • identifiers of these networks are recorded in the profile of the publisher.
  • each time the Z share zone is activated in a sharing page it will display the list of icons of the social networks selected by the editor. These icons will themselves be hypertext links on which the user can click as described above.
  • the user will be able to share the address of the article that is the subject of the sharing page with his contacts, either by direct sending of a message containing this address, or by publication of this address in his status page for example.
  • the publisher can create as many categories as he wants. Optionally, some categories can be created by default and can not be deleted, for example "photo” and "video”.
  • these categories will appear when provided as a button of a predetermined format, which contains text describing the category name, and which is a link to an address containing the content associated with that category. category.
  • the editor can assign a default value to the address associated with each of the categories.
  • the publisher can directly and automatically integrate the address of this forum, without the need to recreate each time.
  • each operation is carried out by a specific web page, which makes it possible to categorize the actions of the editor, while keeping a reasonable size, which avoids a complex navigation in the screen for be sure to have filled in all the necessary fields.
  • Figure 5 describes a function for creating / updating a sharing page by an editor.
  • this function is implemented by a web page on the server 8 (or on another server) to which the editor accesses.
  • the management program 12 that manages these pages as well as the entries and access to the memoirs 18, 20 and 22.
  • a program may be run locally on an editor machine, which performs the same operations as those described in Figure 5, and synchronizes this data with the share page data on the server. 8 later.
  • a share page profile URL_D is created.
  • this operation will be an authentication operation, for example by means of a pair of publisher name / password and entry of an identifier of the share page ( by manual input or by selection with the mouse for example).
  • the editor enters the address at which the sharing page will be accessible.
  • the address of the share page can be a composite between a global address assigned to the editor of type http: / publisher_l URL / and a particular address that the editor chooses for the share page.
  • the operation 502 is followed by an operation 504 in which the editor can define data Art_D for their publication in the zones Tit Z and Art_Z.
  • the Art_D data can comprise on the one hand title data for the article, which is displayed in the zone Tit Z, between the data of the zone Art Z and the data of the zone Pub_Z, and on the other hand data of the article that the publisher wishes to present on the page of sharing.
  • the article's data may include an image whose size is limited by a frame, similar to what is done for the publisher's logo, an accompanying text and a hypertext link to the article itself. even.
  • this image is a thumbnail of the article that is the subject of the sharing page. This reassures the user as to the page he is about to share with his contacts.
  • This thumbnail can be generated automatically when the publisher creates the sharing page, or generated at each consultation by a user. Of course, not all of this data is needed, and the hyperlink alone may suffice.
  • the image data can for example be stored in the memory 22.
  • Ext D data for filling the Ext_Z field.
  • this data will be formed by one or more URLs that contain the designation of an advertising network, and an identifier of the editor (optional) depending on the mode of operation of the control room. It goes without saying that other contents can be designated by the addresses of the data Ext D, the idea being here that these data designate a content that the publisher does not necessarily control.
  • the editor can define data Cont_D to fill the zone Cont Z.
  • This operation can comprise two steps:
  • the publisher chooses the categories of content that must be displayed for the sharing page
  • the publisher fills in the content of the categories he has selected in the first step
  • the first step therefore allows this selection, the basic choice of which corresponds to the content categories defined in the publisher profile.
  • This first step can also provide for a maximum number of categories, in order to preserve the readability of the sharing page.
  • the editor can also activate or deactivate the contents of the Soc_Z zone by ticking a box, depending on whether the publisher wants the user to be able to share the page or not.
  • the second step is to specify for each of the categories selected in the first step the hypertext link associated with them, when it is not predefined (see operation 406).
  • the two steps can be performed without reloading the page, which simplifies the editor's task and improves the ergonomics of the page.
  • each operation of the example just described is carried out by a specific web page, which makes it possible to categorize the publisher's actions, while keeping a reasonable size, which avoids a complex navigation in the screen to be sure to have filled all the necessary fields.
  • FIG. 6 will make it possible to better understand how the access to a sharing page is managed by the server 8.
  • a first operation 600 the server 8 receives the access request to a sharing page. This operation is the result of the operation 202 of FIG.
  • the driver 10 calls the extractor 13 of the server 8 to analyze the access request received to the operation 600, which derives the publisher profile identifier (first part of the URL address of the request) and the identifier of the share page that is targeted by this request (second part of the URL of the request).
  • the driver 10 calls the server 14 sieve 14 to request the partition page data memory 20 and look for whether the share page identifier from the request is present there. Then, if this identifier is found, then the corresponding partition page data is retrieved. Otherwise, the sender 14 returns an error information which is relayed to the transmitter device 2 or 4.
  • the sifter 14 can determine the partition page identifier closest to that derived from the extractor. 13, as well as the corresponding partition page data.
  • the sifter 14 can determine a plurality of page-sharing identifiers close to that taken from the extractor 13, and ask the user to choose among these identifiers.
  • driver 10 processes the share page data obtained at operation 604 in an operation 606.
  • the driver 10 will first determine whether to call the engine 6 to generate the share page or not.
  • This distinction can for example be made from the "User Agent" information contained in the request of operation 600.
  • the invention when the invention is implemented from a mobile device such as a mobile phone, it may contain a specific application for viewing the sharing pages of the invention, so that it is not necessary to format the data of the operation 606, otherwise gathering them in the file ShPDat , and sending them to the requesting device in an operation 608.
  • the application on the mobile phone includes a motor adapted to receive the raw data ShPDat, and to display the corresponding partition page in accordance with the diagram of Figure 3.
  • this engine uses structural data of page sharing which form a pattern corresponding to Figure 3, and generates the share page by introducing the ShPDat share page data mentioned in the previous paragraph.
  • these data are stored in the memory 22.
  • the canvas of the share page is in XML language. This canvas describes frames for each area described above. These frames define identified content classes.
  • the share page data taken from the memories 18, 20 are also in XML, and include identifiers corresponding to those of the classes of the template. Thus, these elements are integrated in their corresponding areas when the engine integrates them into the canvas.
  • this environment reduces the amount of data that is transmitted to the device, which is advantageous in terms of cost and processing time.
  • the application on the device itself that is responsible for making the page sharing.
  • the driver 10 determines that the request for the operation 600 comes from a web browser, then it calls the engine 16 to generate the share page, similar to what has been described for the mobile phone engine.
  • the ShPDat data is then constituted by the sharing page itself.
  • Figure 7 shows a template variation for the sharing page that is more suitable for viewing on a computer or tablet.
  • the server 8 stores partition page structure data for each pattern.
  • the engine 16 may for example determine the pattern to be applied according to the "User Agent" information contained in the request of the operation 600. This can be done during the operation 606 for example. Thus, if the information "User Agent" indicates for example that the request comes from the web browser of a tablet, then the engine 16 can generate the appropriate sharing page. In this case, the request for the operation 600 can be issued by the web browser, by entering the text string corresponding to the share page in the address bar of the latter.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Système informatique, agencé pour accéder à un réseau étendu, caractérisé en ce qu'il comprend : - une mémoire (20) stockant des données de page de partage, - une mémoire (22) stockant des données de structure de page de partage, - une mémoire (18) stockant des données de profil d'éditeur, - un extracteur (13), agencé pour recevoir une requête d'accès et pour en tirer un identifiant de page de partage et un identifiant de profil d'éditeur, - un cribleur (14) agencé pour tirer des données de page de partage à partir d'un identifiant de page de partage, - un moteur (16) agencé pour générer une page de partage à partir de données de structure de page de partage, de données de page de partage, et de données de profil d'éditeur, et - un pilote (10), agencé pour recevoir une requête d'accès d'un élément du réseau étendu, pour appeler le cribleur (14) avec l'identifiant de page de partage et l'identifiant de profil d'éditeur déterminés par l'extracteur (13), pour appeler le moteur (16) avec les données résultantes et les données de structure de page de partage, et pour renvoyer la page résultante audit élément du réseau étendu.

Description

Système informatique de partage et procédé correspondant
L'invention concerne le domaine de l'informatique sur réseau étendu. L'avènement de l'internet a fourni de nouveaux canaux d'expression, tant aux particuliers, qu'aux professionnels de la publication. Cela s'est particulièrement renforcé avec le Web 2.0 au sein duquel les réseaux sociaux permettent de partager des informations toujours plus rapidement. Diverses solutions technologiques ont été développées pour permettre aux utilisateurs d'Internet de partager facilement un lien internet d'intérêt avec leurs connaissances.
Cependant, ces outils ne permettent que de partager des éléments relatifs à la consultation du Web. Il n'existe actuellement aucune solution qui permette à un lecteur d'une publication imprimée écrite de partager un article, ou d'accéder à un contenu associé à cet article.
L'invention vient améliorer la situation. A cet effet, l'invention propose un système informatique, agencé pour accéder à un réseau étendu qui comprend :
- une mémoire stockant des données de page de partage,
- une mémoire stockant des données de structure de page de partage,
- une mémoire stockant des données de profil d'éditeur,
- un extracteur, agencé pour recevoir une requête d'accès et pour en tirer un identifiant de page de partage et un identifiant de profil d'éditeur,
- un cribleur agencé pour tirer des données de page de partage à partir d'un identifiant de page de partage,
- un moteur agencé pour générer une page de partage à partir de données de structure de page de partage, de données de page de partage, et de données de profil d'éditeur, et
- un pilote, agencé pour recevoir une requête d'accès d'un élément du réseau étendu, pour appeler le cribleur avec l'identifiant de page de partage et l'identifiant de profil d'éditeur déterminés par l'extracteur, pour appeler le moteur avec les données résultantes et les données de structure de page de partage, et pour renvoyer la page résultante audit élément du réseau étendu. D'autres caractéristiques et avantages de l'invention apparaîtront mieux à la lecture de la description qui suit, tirée d'exemples donnés à titre illustratif et non limitatif, tirés des dessins sur lesquels :
- la figure 1 représente un schéma générique d'un environnement informatique dans lequel l'invention est mise en œuvre,
- la figure 2 représente un diagramme de flux d'un accès à une page de partage selon l'invention,
- la figure 3 représente un exemple de maquette de page de partage produite selon l'invention,
- la figure 4 représente un diagramme de flux de création et/ou de modification d'un profil d'éditeur dans le cadre de l'invention,
- la figure 5 représente un diagramme de flux de création et/ou de modification d'une page de partage dans le cadre de l'invention,
- la figure 6 représente un diagramme de flux de génération de données de page de partage dans le cadre de l'invention, et
- la figure 7 représente un autre exemple de maquette de page produite selon l'invention.
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.
La figure 1 représente un schéma générique d'un environnement mettant en œuvre un système selon l'invention.
Dans cet environnement, des postes clients 2 et 4 peuvent communiquer via un réseau étendu 6 (par exemple Internet) avec un système informatique 8 selon l'invention. Dans l'exemple décrit, les postes informatiques sont un ordinateur portable 2 et un téléphone mobile 4.
Cependant d'autres dispositifs peuvent être envisagés, comme un ordinateur de bureau ou un ordinateur de type "tablette". La principale caractéristique de ces dispositifs est leur capacité à se connecter au système informatique 8 et à afficher les pages que celui- ci leur renvoie.
Le système informatique 8 est dans l'exemple décrit, ici, un serveur web monoposte. Ce serveur peut être réalisé sous toute forme appropriée comme une grappe de serveurs, éventuellement répartis en plusieurs emplacements différents. La principale caractéristique du serveur 8 est sa capacité à recevoir les requêtes d'accès aux pages de partage, et à fournir celles-ci. Dans l'exemple décrit ici, l'ordinateur portable 2 et le téléphone 4 comprennent chacun un programme de reconnaissance de caractères. Ce programme permet de détecter une chaîne de caractères dans une image traitée par ces dispositifs.
Cette image peut être enregistrée sur la mémoire de ces dispositifs, ou tirée d'un capteur photographique du téléphone 4 ou d'une webcam incorporée à l'ordinateur portable 2. Les postes informatiques 2 et 4 comportent également un programme agencé pour envoyer une requête d'accès à une page de partage sur le serveur 8, qui contient le texte tiré de la reconnaissance de caractères. Le programme de requête d'accès et celui de reconnaissance de caractères peuvent être incorporés à un même programme, ou constituer des éléments séparés invoqués par un autre programme.
Ainsi, si l'on considère l'exemple d'une application sur un téléphone mobile moderne, tel l'iPhone (marque enregistrée de la société Apple), une application peut être mise à disposition des utilisateurs. Cette application est programmée pour :
- accéder au flux vidéo du capteur photographique de l'iPhone,
- appeler un module de reconnaissance de texte sur une partie de ce flux, et
- appeler directement le serveur 8 et afficher en retour la page de partage.
Ces actions peuvent être exécutées en restant dans l'application et en faisant appel à des modules logiciels incorporés à l'iPhone. En variante, tout ou partie du code peut également être réécrit. Ce dernier cas peut être très avantageux comme on le verra avec la figure 6.
Le serveur 8 comprend un pilote 10, un programme de gestion 12, un extracteur 13, un cribleur 14 et un moteur d'assemblage 16, ainsi que des mémoires 18, 20 et 22 pour stocker respectivement des données de profil, des données de page de partage et des données de contenu.
Les mémoires 18, 20 et 22 peuvent être physiquement reliées au serveur 8, ou bien être accessibles à distance. Elles peuvent être réalisées au sein d'une mémoire unique, ou dans des unités de mémoire séparées. La figure 2 représente un exemple de mise en œuvre d'une requête d'accès à une page de partage auprès du serveur 8.
Dans une première opération 200, le dispositif informatique 2 ou 4 génère une requête d'accès à la page de partage. Cette opération est réalisée par une fonction Gen(), qui génère la requête à partir de la chaîne de caractère obtenue comme décrit plus haut.
La fonction Gen() concatène cette chaîne de caractère avec une chaîne de texte qui forme un squelette de requête. Dans un mode de réalisation décrit ici, le serveur 8 est un serveur Web. La fonction Gen() la concatène avec l'adresse du serveur 8 à laquelle sont envoyées les requêtes d'accès. Par exemple la page qui est invoquée pour consulter une page de partage peut être une page "page_de_partage.htm" du serveur 8. La chaîne de caractère avec laquelle la chaîne de caractère sera concaténée sera alors du type http://URL_Serveur/page_dejpartage.html, où URL Serveur est l'adresse URL du serveur 8.
Une fois les deux chaînes concaténées, la requête http qui sera émise aura la forme suivante :
GET http://URL_Serveur/page_de_partage.html?page=chaîne_de_texte_reconnue HTTP/1.0
User-Agent : user_agent_du_dispositif
Une fois que cette requête est mise en forme par la fonction Gen(), une fonction Send() est utilisée pour envoyer cette requête au serveur 8 dans une opération 202.
Cette requête est reçue par le serveur 8, et dans une opération 204, celui-ci la traite et produit des données de page de partage qui définissent une page de partage qui correspond à la chaîne "chaîne_de_texte_reconnue", au moyen de fonctions propres au serveur 8 désignées ici sous le nom de fonction Mk(ShPgDat).
Comme on le verra dans la suite, les données de page de partage ShPDat peuvent varier en fonction de l'origine de la requête d'accès à la page partagée. En effet, comme on le verra avec la figure 6, le serveur 8 ne traitera pas de la même manière une requête issue d'une application spécifique et une requête issue d'un navigateur Web.
Ensuite, le serveur 8 renvoie les données de page de partage Sh_Pg_Dat générées à l'opération 204 vers le dispositif 2 ou 4 émetteur dans une opération 206 au moyen de la fonction Send(). Enfin, l'utilisateur peut accéder à la page de partage sur le dispositif émetteur 2 ou 4 dans une opération 208, via une fonction Brws(). La figure 3 représente un squelette de page de partage qui est rempli avec des informations obtenues à partir de la requête Req par le serveur 8.
Le détail de la génération de cette page apparaîtra mieux avec la figure 6. L'exemple représenté ici est particulièrement adapté à l'affichage sur un téléphone mobile.
Comme on peut le voir sur la figure 3, les pages de partage sont divisées en plusieurs zones :
- une zone EXT Z,
- une zone PUB_Z,
-une zone TIT Z,
-une zone ART Z,
- une zone CONT Z, et
- une zone SOC Z.
Les zones EXT Z, PUB Z et TIT_Z sont alignées verticalement dans cet ordre, au dessus des zones ART Z et CONT_Z qui sont sensiblement parallèle l'une avec l'autre dans cet ordre, et au dessus de la zone SOC_Z. Toutes ces zones peuvent être remplies avec divers types de contenu qui peuvent varier selon des paramètres établis par l'éditeur de la page de partage.
La zone Ext_Z a pour vocation de recevoir des éléments extérieurs au contexte de la page partagée, et désignés par le créateur de la page. Par exemple, cette zone peut recevoir des données de publicités, qui peuvent permettre à l'éditeur d'être rémunéré en fonction de leur consultation. Par ailleurs, le contenu de ces pages peut être personnalisé en fonction des données fournies par l'éditeur de la page de partage et du fournisseur de pages de publicité. La zone Pub Z a pour vocation de recevoir des données qui permettent d'identifier l'éditeur de la page de partage. Par exemple, lorsque la page de partage est une page liée à un article d'un magazine, la zone Pub Z pourra recevoir un logo du magazine ou de l'éditeur du magazine, ainsi que des liens à une page d'abonnement ou autre. Dans l'exemple décrit ici, cette zone est commune aux pages de partage créées par un même éditeur. La zone Tit_Z a pour vocation de recevoir des données qui permettent d'identifier la page de partage. Cela peut par exemple être un titre éventuellement associé à un contenu. Cette zone est entièrement dynamique, c'est-à-dire qu'elle change avec chaque nouvelle page de partage. Il reste bien sûr possible d'utiliser des données identiques pour des zones Tit_Z de deux pages de partage distinctes.
La zone Art_Z a pour vocation de recevoir des données qui constituent le contenu principal de la page de partage, c'est-à-dire l'objet de la page de partage elle-même. Cela peut par exemple être une photo accompagnée d'un texte qui résume l'article, cette zone formant un lien hypertexte qui amène à l'adresse réelle de l'article faisant l'objet de cette page de partage. Là encore, cette zone est entièrement dynamique, c'est-à-dire qu'elle change avec chaque nouvelle page de partage. Il reste là encore possible d'utiliser des données identiques pour des zones Art_Z de deux pages de partage distinctes.
La zone Cont Z a pour vocation de recevoir des données de contenu associé à l'article présenté dans la zone Art_Z. Ces contenus peuvent être des photos, des vidéos, un lien vers un forum de discussion sur cet article, un ou plusieurs liens vers des articles portant sur le même thème, etc. La description de la figure 4 montrera que ce contenu peut être particulièrement varié et là encore dynamique. Enfin la zone Soc_Z a pour vocation de recevoir des données de partage social de cette page de partage. Plus précisément, cette zone peut recevoir deux types d'éléments de partage :
- d'une part des liens vers des sites de réseaux sociaux (par exemple Facebook, Twitter, Digg, un compte email ou autres) qui vont permettre à l'utilisateur de partager simplement l'adresse de l'article faisant l'objet de la page de partage avec ses connaissances. Les liens vers les sites de réseaux sociaux ne sont pas des simples redirections vers la page principale du site concerné : ils contiennent également les paramètres de commande nécessaires au partage requis par chaque site concerné. On pourrait les interpréter comme étant des requêtes.
- d'autre part un ou plusieurs liens de sauvegarde, qui vont permettre à l'utilisateur d'enregistrer cette page parmi ses favoris dans un service relié au serveur 8 auquel l'utilisateur est abonné, pour permettre une consultation ultérieure avec un accès simplifié.
Comme la zone Pub_Z la zone Soc_Z est dans l'exemple décrit ici commune aux pages de partage créées par un même éditeur.
Comme cela apparaîtra mieux avec les figures 4 à 6, ces zones peuvent être remplies dynamiquement et très simplement grâce à l'architecture de l'invention.
Comme on l'a vu précédemment, les pages de partages suivent un prototype de présentation ou squelette, ici figé, et l'éditeur vient "remplir" les zones en fonction de ses besoins.
Cependant, l'éditeur peut être amené à créé plusieurs dizaines, voire des centaines de pages de partage. Dans ce contexte, il est intéressant de créer des profils d'éditeur sur le serveur 8, dans lequel l'éditeur peut centraliser un certain nombre de données qui seront valables pour toutes les pages de partage qu'il crée, ce qui diminuera sa charge de travail.
Ainsi, la figure 4 décrit une fonction de création/mise à jour d'un profil d'éditeur permettant de centraliser ces informations. Dans l'exemple décrit ici, cette fonction est mise en œuvre par une page web sur le serveur 8 (ou sur un autre serveur) à laquelle l'éditeur accède. C'est le programme de gestion 12 qui gère ces pages ainsi que les écritures et accès aux mémoires 18, 20 et 22. Dans d'autres modes de réalisation, un programme pourra être exécuté localement sur une machine de l'éditeur, qui exécute les mêmes opérations que celles décrites avec la figure 4, et qui synchronise ces données avec le profil de l'éditeur sur le serveur 8 plus tard.
Dans une opération 400, le profil d'éditeur U Prof est créé. Lorsqu'un éditeur viendra modifier plus tard son profil, cette opération sera une opération d'authentification, par exemple au moyen d'un couple nom d'éditeur/ mot de passe.
Ensuite, dans une opération 402, l'éditeur a accès à une page qui lui permet de définir les données PubJD de la zone Pub Z.
Comme cela a été décrit précédemment, ces données sont communes aux pages qui sont créées par l'éditeur, et elles permettent de l'identifier clairement, par exemple au moyen d'un logo et/ou d'un nom. Dans l'exemple décrit ici, ces données comprennent un logo, que l'éditeur peut télé verser directement sur le serveur 8, ou indiquer par référence en donnant un lien d'un autre serveur sur lequel ce logo est accessible, ainsi que deux liens hypertextes.
Le logo doit avoir une taille limitée par le schéma retenu pour la page partagée, comme illustré sur la figure 3. Cela garantit que l'éditeur ne peut pas produire des pages déformées en téléversant un logo de taille trop importante. En variante, le serveur 8 peut comprendre une application qui redimensionne un logo lorsque celui-ci est trop grand. Les données d'image peuvent par exemple être stockées dans la mémoire 22. Les deux liens hypertextes peuvent être personnalisés par l'éditeur pour guider un utilisateur vers des liens d'intérêt. Par exemple, l'un des liens peut être personnalisé pour guider l'utilisateur vers une page d'abonnement au contenu papier de l'éditeur, et l'autre lien peut emmener l'utilisateur vers une page qui permet de s'abonner à des flux d'informations concernant l'éditeur, comme un flux RSS ou une lettre d'information électronique.
D'une manière générale, ces deux liens sont deux liens de nature textuels choisis arbitrairement par l'éditeur. Ensuite, dans une opération 404, l'éditeur peut définir des données Soc D pour la zone Soc_Z. Les données Soc Z vont porter sur les deux types de liens qui ont été décrits plus haut. De manière avantageuse, cette page pourra se présenter sous la forme d'une page de sélection où chaque réseau social est accompagné d'une icône d'identification de ce réseau et d'une case de type "bouton radio" ou "case à cocher" pour sélectionner le réseau correspondant.
Une fois que l'éditeur a fait le choix de tous les éléments de partage via des réseaux sociaux ou la sauvegarde qu'il souhaite présenter, des identifiants de ces réseaux sont enregistrés dans le profil de l'éditeur.
Ainsi, à chaque fois que la zone de partage Soc Z sera activée dans une page de partage, celle-ci affichera la liste des icônes des réseaux sociaux sélectionnés par l'éditeur. Ces icônes seront elles-mêmes des liens hypertexte sur lesquels l'utilisateur pourra cliquer comme décrit plus haut.
À partir de là, l'utilisateur pourra partager l'adresse de l'article faisant l'objet de la page de partage avec ses contacts, soit par envoi direct d'un message contenant cette adresse, soit par publication de cette adresse dans sa page de statut par exemple.
Enfin, dans une opération 406, l'éditeur peut définir des données de catégorie de contenu. En effet, on a vu avec la figure 3 que la zone Cont Z est dédiée à la liaison de contenus choisis par l'éditeur. Ces contenus peuvent être de diverses natures :
- photo,
- vidéo,
- forum,
- commentaire,
- flux RSS,
- offre spéciale liée à l'article,
- etc. L'éditeur peut créer autant de catégories qu'il le souhaite. De manière optionnelle, certaines catégories peuvent être créées par défaut et ne peuvent pas être supprimées, par exemple "photo" et "vidéo".
Dans la zone Cont_Z, ces catégories apparaîtront lorsqu'elles sont prévues en tant que bouton d'un format prédéterminé, qui contient un texte décrivant le nom de la catégorie, et qui est un lien qui mène vers une adresse contenant le contenu associé à cette catégorie.
Optionnellement, l'éditeur peut affecter une valeur par défaut à l'adresse associée à chacune des catégories. Ainsi, si l'une des catégories est un forum par exemple, l'éditeur pourra intégrer directement et automatiquement l'adresse de ce forum, sans avoir besoin de la recréer à chaque fois.
Ensuite la création/modification de profil éditeur se termine dans une opération 408.
Dans l'exemple qui vient d'être décrit, chaque opération est réalisée par une page web spécifique, ce qui permet de catégoriser les actions de l'éditeur, tout en gardant une taille raisonnable, qui évite une navigation complexe dans l'écran pour être sûr d'avoir rempli tous les champs nécessaires.
Cependant, toutes ces opérations pourraient être regroupées sur une seule et unique page de formulaire. En outre, les opérations présentées ci-dessus pourraient être réalisées dans n'importe quel ordre. De même, toutes les opérations ne sont pas nécessaires à la création et/ou la modification d'un profil. Certaines pourront être omises en fonction des besoins de l'éditeur.
La figure 5 décrit une fonction de création/mise à jour d'une page de partage par un éditeur. Dans l'exemple décrit ici, cette fonction est mise en uvre par une page web sur le serveur 8 (ou sur un autre serveur) à laquelle l'éditeur accède. Ici encore, c'est le programme de gestion 12 qui gère ces pages ainsi que les écritures et accès aux mémoires 18, 20 et 22. Dans d'autres modes de réalisation, un programme pourra être exécuté localement sur une machine de l'éditeur, qui exécute les mêmes opérations que celles décrites avec la figure 5, et qui synchronise ces données avec les données de page de partage sur le serveur 8 plus tard.
Dans une opération 500, un profil de page de partage URL_D est créé. Lorsqu'un éditeur viendra modifier plus tard cette page de partage, cette opération sera une opération d'authentification, par exemple au moyen d'un couple nom d'éditeur/ mot de passe et saisie d'un identifiant de la page de partage (par saisie manuelle ou par sélection à la souris par exemple).
Ensuite, dans une opération 502, l'éditeur saisit l'adresse à laquelle la page de partage sera accessible. Selon une première variante, l'adresse de la page de partage peut être un composite entre une adresse globale affectée à l'éditeur de type http:/ URL_Editeur/ et une adresse particulière que l'éditeur choisit pour la page de partage.
Ce type de convention d'adresse présente plusieurs avantages.
Tout d'abord, il permet d'offrir une certaine homogénéité aux pages de partage créées par l'éditeur. Cela signifie qu'un utilisateur pourra identifier l'éditeur non seulement par les données de la zone Pub_Z, mais également par la première partie de l'adresse URL de la page de partage.
Ensuite, cela réduit la quantité de données que l'éditeur a besoin de rentrer pour créer une page de partage. Cela représente un gain de temps non négligeable (les URL peuvent prendre un temps conséquent à écrire du fait des caractères spéciaux qu'elles contiennent), mais également une sécurité, car les risques d'erreurs de frappe liées à la première partie de l'URL sont éliminés. Enfin, cela permet un traitement facilité par le serveur lorsqu'il reçoit une requête d'accès à une page: cela rend possible d'aller directement chercher dans les pages de partages publiées par un éditeur donné au lieu de chercher dans l'ensemble de toutes les pages de partage créées.
Dans d'autres variantes, il sera possible de permettre à l'éditeur de définir l'adresse de la page de partage, partiellement ou dans son intégralité.
L'opération 502 est suivie d'une opération 504 dans laquelle l'éditeur peut définir des données Art_D pour leur publication dans les zones Tit Z et Art_Z.
Les données Art_D peuvent comprendre d'une part des données de titre pour l'article, qui est affiché dans la zone Tit Z, entre les données de la zone Art Z et les données de la zone Pub_Z, et d'autre part des données de l'article que l'éditeur souhaite présenter sur la page de partage.
Les données de l'article peuvent comprendre une image dont la taille est limitée par un cadre, de même similaire à ce qui est fait pour le logo de l'éditeur, un texte d'accompagnement et un lien hypertexte vers l'article lui-même.
Dans l'exemple décrit ici, cette image est une miniature de l'article qui fait l'objet de la page de partage. Cela permet de rassurer l'utilisateur quant à la page qu'il est sur le point de partager avec ses contacts. Cette miniature peut être générée automatiquement à la création de la page de partage par l'éditeur, ou être générée à chaque consultation par un utilisateur. Bien sûr ces données ne sont pas toutes nécessaires, et le lien hypertexte seul peut suffire. Les données d'image peuvent par exemple être stockées dans la mémoire 22.
Ensuite, dans une opération 506, l'éditeur peut définir des données Ext D pour le remplissage de la zone Ext_Z. Généralement, ces données seront formées par une ou plusieurs adresses URL qui contiennent la désignation d'une régie publicitaire, ainsi qu'un identifiant de l'éditeur (optionnel) selon le mode de fonctionnement de la régie. Il va de soi que d'autres contenus peuvent être désignés par les adresses des données Ext D, l'idée étant ici que ces données désignent un contenu que l'éditeur ne maîtrise pas forcément. Enfin, dans une opération 508, l'éditeur peut définir des données Cont_D pour remplir la zone Cont Z.
Cette opération peut comprendre deux étapes :
- dans une première étape, l'éditeur choisit les catégories de contenu qui doivent être affichées pour la page de partage,
- dans une deuxième étape, l'éditeur remplit le contenu des catégories qu'il a sélectionnées à la première étape
En effet, ce contenu peut être varié en fonction de la page de partage considérée. La première étape permet donc cette sélection, dont le choix de base correspond aux catégories de contenu définies dans le profil d'éditeur.
Cette première étape peut également prévoir un nombre maximum de catégories, afin de préserver la lisibilité de la page de partage. Dans cette première étape, l'éditeur peut également activer ou désactiver le contenu de la zone Soc_Z en cochant une case, selon que l'éditeur souhaite que l'utilisateur puisse partager la page ou pas.
La deuxième étape consiste à préciser pour chacune des catégories sélectionnées à la première étape le lien hypertexte qui leur est associé, lorsque celui-ci n'est pas prédéfini (voir opération 406).
On notera que, grâce aux possibilités de code modernes, les deux étapes peuvent être réalisées sans recharger la page, ce qui et simplifie la tâche de l'éditeur et améliore l'ergonomie de la page.
Enfin cette opération se termine en 510. De manière similaire à la figure 4, chaque opération de l'exemple qui vient d'être décrit est réalisée par une page web spécifique, ce qui permet de catégoriser les actions de l'éditeur, tout en gardant une taille raisonnable, qui évite une navigation complexe dans l'écran pour être sûr d'avoir rempli tous les champs nécessaires.
Cependant, toutes ces opérations pourraient être regroupées sur une seule et unique page de formulaire. En outre, les opérations présentées ci-dessus pourraient être réalisées dans n'importe quel ordre. De même, toutes les opérations ne sont pas nécessaires à la création et/ou la modification d'un profil. Certaines pourront être omises en fonction des besoins de l'éditeur.
Maintenant que la structure des pages de partage apparaît clairement en correspondance du profil de l'éditeur qui les crée, la figure 6 va permettre de mieux comprendre comment l'accès à une page de partage est géré par le serveur 8.
Dans une première opération 600, le serveur 8 reçoit la requête d'accès à une page de partage. Cette opération est le résultat de l'opération 202 de la figure 2.
Ensuite, dans des opérations 602 à 606, nous allons décrire un exemple de mise en œuvre de la fonction Mk(Sh P) de l'opération 204.
Dans l'opération 602, le pilote 10 appelle l'extracteur 13 du serveur 8 pour analyser la requête d'accès reçue à l'opération 600, qui en tire l'identifiant de profil d'éditeur (première partie de l'adresse URL de la requête) et l'identifiant de la page de partage qui est visée par cette requête (deuxième partie de l'adresse URL de la requête).
Ensuite, dans l'opération 604, le pilote 10 appelle le cribleur 14 du serveur 8 pour requêter la mémoire 20 de données de page de partage et chercher si l'identifiant de page de partage tiré de la requête y est présent. Ensuite, si cet identifiant est trouvé, alors les données de page de partage correspondantes sont récupérées. Sinon, le cribleur 14 renvoie une information d'erreur qui est relayée jusqu'au dispositif émetteur 2 ou 4. Selon une première variante, le cribleur 14 peut déterminer l'identifiant de page de partage le plus proche de celui tiré de l'extracteur 13, ainsi que les données de page de partage correspondante.
Selon une seconde variante, le cribleur 14 peut déterminer une pluralité d'identifiants de page de partage proches de celui tiré de l'extracteur 13, et demander à l'utilisateur de choisir parmi ces identifiants.
Ces mêmes opérations sont également réalisées sur l'identifiant de profil d'éditeur dans la mémoire 18 pour récupérer les données de page de partage qui sont communes aux pages de partage d'un même éditeur.
Une fois que toutes les données concernant la page de partage sont récupérées, le pilote 10 traite les données de page de partage obtenues à l'opération 604 dans une opération 606.
Pour cela, le pilote 10 va dans un premier temps déterminer s'il doit appeler le moteur 6 pour générer la page de partage ou non. Cette distinction peut par exemple être réalisée à partir de l'information « User Agent » que contient la requête de l'opération 600. En effet, lorsque l'invention est mise en œuvre à partir d'un dispositif mobile comme un téléphone portable, celui-ci peut contenir une application spécifique à la consultation des pages de partage de l'invention, de sorte qu'il n'est pas nécessaire de mettre en forme les données de l'opération 606, sinon en les rassemblant dans le fichier ShPDat, et en les envoyant au dispositif requêteur dans une opération 608. Dans ce cas, l'application sur le téléphone mobile comprend un moteur adapté à recevoir les données ShPDat sous forme brute, et à afficher la page de partage correspondante conformément au schéma de la figure 3. Pour cela, ce moteur utilise des données de structure de page de partage qui forment un canevas correspondant à la figure 3, et génère la page de partage en y introduisant les données de page de partage ShPDat mentionnées au paragraphe précédent. Dans l'exemple décrit ici, ces données sont stockées dans la mémoire 22. Dans l'exemple décrit ici, le canevas de la page de partage est en langage en XML. Ce canevas décrit des cadres pour chaque zone décrite plus haut. Ces cadres définissent des classes de contenu identifiés.
De manière similaire, les données de page de partage tirée des mémoires 18, 20 sont également en langage XML, et comportent des identifiants correspondant à ceux des classes du canevas. Ainsi, ces éléments sont intégrés dans les zones leur correspondant quand le moteur les intègre au canevas.
Cela est particulièrement avantageux pour plusieurs raisons.
Tout d'abord, cet environnement permet de réduire la quantité de données qui est transmise au dispositif, ce qui est avantageux en termes de coût et de temps de traitement. En outre, comme c'est l'application sur le dispositif elle-même qui se charge de rendre la page de partage. En conséquence, il n'y a qu'une seule application à maintenir à jour et à adapter par système d'exploitation.
Cela est avantageux quand on connaît l'étendue des divergences de traitement du code HTML par les divers navigateurs Web du marché. C'est d'autant plus vrai que le moteur de l'application n'a besoin de rendre qu'un seul type de page, et qu'il est donc peu complexe. Lorsque le pilote 10 détermine que la requête de l'opération 600 provient d'un navigateur Web, alors il appelle le moteur 16 pour générer la page de partage, de manière similaire à ce qui a été décrit pour le moteur du téléphone mobile. Les données ShPDat sont alors constituées par la page de partage elle-même.
Enfin, une fois que le moteur 16 a construit la page de partage correspondant à la requête de l'opération 600, le pilote 10 renvoie cette page vers le dispositif qui a émis la requête pour consultation dans l'opération 608. La figure 7 montre une variante de canevas pour la page de partage qui est plus adaptée pour une consultation sur un ordinateur ou une tablette.
Pour cela, le serveur 8 stocke des données de structure de page de partage pour chaque canevas. Le moteur 16 pourra par exemple déterminer le canevas à appliquer en fonction de l'information « User Agent » que contient la requête de l'opération 600. Cela peut être réalisé lors de l'opération 606 par exemple. Ainsi, si l'information « User Agent » indique par exemple que la requête provient du navigateur Web d'une tablette, alors le moteur 16 pourra générer la page de partage adaptée. Dans ce cas, la requête de l'opération 600 peut être émise par le navigateur Web, en entrant la chaîne de texte correspondant à la page de partage dans la barre d'adresse de celui-ci.

Claims

Revendications
1. Système informatique, agencé pour accéder à un réseau étendu, caractérisé en ce qu'il comprend :
- une mémoire (20) stockant des données de page de partage,
- une mémoire (22) stockant des données de structure de page de partage,
- une mémoire (18) stockant des données de profil d'éditeur,
- un extracteur (13), agencé pour recevoir une requête d'accès et pour en tirer un identifiant de page de partage et un identifiant de profil d'éditeur,
- un cribleur (14) agencé pour tirer des données de page de partage à partir d'un identifiant de page de partage,
- un moteur (16) agencé pour générer une page de partage à partir de données de structure de page de partage, de données de page de partage, et de données de profil d'éditeur, et
- un pilote (10), agencé pour recevoir une requête d'accès d'un élément du réseau étendu, pour appeler le cribleur (14) avec l'identifiant de page de partage et l'identifiant de profil d'éditeur déterminés par l'extracteur (13), pour appeler le moteur (16) avec les données résultantes et les données de structure de page de partage, et pour renvoyer la page résultante audit élément du réseau étendu.
2. Système informatique selon la revendication 1, comprenant en outre un programme de gestion (12) agencé pour permettre à un éditeur de définir des données de profil d'éditeur pour stockage dans la mémoire (18) de données de profil d'éditeur.
3. Système informatique selon la revendication 2, dans lequel les données de profil d'éditeur comprennent des données choisies parmi le groupe comprenant des données d'image d'éditeur, des données de nom d'éditeur, des données de sites de réseaux sociaux, et des données de catégorie.
4. Système informatique selon l'une des revendications 1 à 3, dans lequel le programme de gestion (12) est en outre agencé pour permettre à un éditeur de définir des données de page de partage pour stockage dans la mémoire (20) de données de page de partage.
5. Système informatique selon la revendication 4, dans lequel les données de page de partage comprennent des données choisies parmi le groupe comprenant des données de titre, des données d'article, des données de catégorie, des données de partage, des données externes et des données de contenu.
6. Système selon la revendication 5, dans lequel certaines au moins des données de page de partage comprennent un lien hypertexte associé à un texte et/ou à une image d'affichage.
7. Environnement informatique comprenant un système informatique selon l'une des revendications précédentes et un dispositif informatique comprenant un module de reconnaissance de texte, et une interface de communication réseau, ainsi qu'une application agencée pour appeler le système informatique via ladite interface de communication réseau avec une requête d'accès à une page de partage, la requête comprenant des données tirées dudit module de reconnaissance de texte.
8. Environnement informatique selon la revendication 7, dans lequel le dispositif comprend en outre un module d'acquisition de données d'image, et dans lequel ladite application est agencée pour appeler ledit module de reconnaissance de texte avec des données d'image tirées dudit module d'acquisition de données d'images pour générer la requête d'accès à une page de partage.
9. Environnement informatique selon la revendication 8, dans lequel les données d'image sont tirées d'un magazine papier.
10. Environnement informatique selon la revendication 9, dans lequel l'application comprend un moteur agencé pour générer une page de partage à partir de données de page de partage, et dans lequel le pilote (10) est agencé pour recevoir une requête d'accès d'un élément du réseau étendu, pour appeler le cribleur (14) avec l'identifiant de page de partage et l'identifiant de profil d'éditeur déterminés par l'extracteur (13), et pour renvoyer les données résultantes audit dispositif sans appeler le moteur (16).
EP11720558A 2010-04-23 2011-04-11 Système informatique de partage et procédé correspondant Withdrawn EP2561454A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1001750A FR2959375B1 (fr) 2010-04-23 2010-04-23 Systeme informatique de partage et procede correspondant
PCT/FR2011/000209 WO2011131852A1 (fr) 2010-04-23 2011-04-11 Système informatique de partage et procédé correspondant

Publications (1)

Publication Number Publication Date
EP2561454A1 true EP2561454A1 (fr) 2013-02-27

Family

ID=43088413

Family Applications (1)

Application Number Title Priority Date Filing Date
EP11720558A Withdrawn EP2561454A1 (fr) 2010-04-23 2011-04-11 Système informatique de partage et procédé correspondant

Country Status (4)

Country Link
US (1) US20130132459A1 (fr)
EP (1) EP2561454A1 (fr)
FR (1) FR2959375B1 (fr)
WO (1) WO2011131852A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130328932A1 (en) * 2012-06-08 2013-12-12 Samsung Electronics Co., Ltd Add social comment keeping photo context

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5987480A (en) * 1996-07-25 1999-11-16 Donohue; Michael Method and system for delivering documents customized for a particular user over the internet using imbedded dynamic content
US7047033B2 (en) * 2000-02-01 2006-05-16 Infogin Ltd Methods and apparatus for analyzing, processing and formatting network information such as web-pages
JP2005339039A (ja) * 2004-05-25 2005-12-08 Fuji Xerox Co Ltd 文書処理装置および文書処理方法
US7551780B2 (en) * 2005-08-23 2009-06-23 Ricoh Co., Ltd. System and method for using individualized mixed document
US9602605B2 (en) * 2007-10-26 2017-03-21 Facebook, Inc. Sharing digital content on a social network

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
FR2959375A1 (fr) 2011-10-28
WO2011131852A1 (fr) 2011-10-27
FR2959375B1 (fr) 2012-11-16
US20130132459A1 (en) 2013-05-23

Similar Documents

Publication Publication Date Title
US10637899B1 (en) Collaborative design
US9369688B2 (en) 3D user personalized media templates
EP2174472A2 (fr) Procede et dispositif de creation d'applications informatiques
EP1193947A2 (fr) Système de communication basé sur le langage WSDL
WO2013140076A2 (fr) Procede et systeme de developpement d'applications de consultation de contenus et services sur un reseau de telecommunciation
WO2007141446A1 (fr) Système de gestion d'un service interactif multimodal
WO2017194777A1 (fr) Système permettant la création et le déploiement d'applications multiplateformes
EP2187321B1 (fr) Procédé et dispositif d'édition d'un objet représenté dans une page web
EP2561454A1 (fr) Système informatique de partage et procédé correspondant
EP2633440B1 (fr) Indexation et execution d'applications logicielles dans un reseau
EP1997040A1 (fr) Procédé, dispositif et système de gestion d'informations structurées au sein d'une scène graphique
FR2930099A1 (fr) Procede et dispositif de routage de donnees
US20200106722A1 (en) Bot platform for mutimodal channel agnostic rendering of channel response
Hayes-Roth et al. Radical simplicity: transforming computers into ME-centric appliances
EP1086561B1 (fr) Interfonctionnement entre des equipements par page d'accueil hypertexte
Lahti et al. A mobile phone-based context-aware video management application
FR2919403A1 (fr) Procede et dispositif de transformation de pages de la toile pour affichage de liens
EP3560147A1 (fr) Automatisation des échanges entre objets communicants
EP1295203A1 (fr) Procede de structuration, de transfert et d'interpretation d'un ensemble d'informations destinees a la conception d'interfaces graphiques
Pascalau TowardsWeb User-Centric Development
FR2910660A1 (fr) Procede de mise a jour d'au moins un espace personnel de publication, terminal de communication, serveur intermediaire et produit programme d'ordinateur correspondants.
EP3320419A1 (fr) Systeme et procede pour l'adaptation d'une interface d'utilisateur
WO2003023651A1 (fr) Procede d'annotation de documents informatiques, et systeme associe
FR2930102A1 (fr) Procede et dispositif de mise en communication de personnes
FR2930060A1 (fr) Procede et dispositif de creation,d'organisation,de livraison,d'exploitation et/ou d'acces a des services

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20121026

AK Designated contracting states

Kind code of ref document: A1

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

RIN1 Information on inventor provided before grant (corrected)

Inventor name: LAMOULINE, THIERRY

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20130611