ES2881253T3 - Procedimiento de construcción de un mensaje por un terminal - Google Patents

Procedimiento de construcción de un mensaje por un terminal Download PDF

Info

Publication number
ES2881253T3
ES2881253T3 ES15160223T ES15160223T ES2881253T3 ES 2881253 T3 ES2881253 T3 ES 2881253T3 ES 15160223 T ES15160223 T ES 15160223T ES 15160223 T ES15160223 T ES 15160223T ES 2881253 T3 ES2881253 T3 ES 2881253T3
Authority
ES
Spain
Prior art keywords
challenge
user
terminal
message
multimedia content
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.)
Active
Application number
ES15160223T
Other languages
English (en)
Inventor
Geneviève Dijoux
Cyrielle Lemaitre
Halim Bendiabdallah
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.)
Orange SA
Original Assignee
Orange SA
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 Orange SA filed Critical Orange SA
Application granted granted Critical
Publication of ES2881253T3 publication Critical patent/ES2881253T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/07—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail characterised by the inclusion of specific contents
    • H04L51/10—Multimedia information
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0484—Interaction techniques based on graphical user interfaces [GUI] for the control of specific functions or operations, e.g. selecting or manipulating an object, an image or a displayed text element, setting a parameter value or selecting a range
    • G06F3/04842—Selection of displayed objects or displayed text elements
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0484—Interaction techniques based on graphical user interfaces [GUI] for the control of specific functions or operations, e.g. selecting or manipulating an object, an image or a displayed text element, setting a parameter value or selecting a range
    • G06F3/04847—Interaction techniques to control parameter settings, e.g. interaction with sliders or dials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/07—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail characterised by the inclusion of specific contents
    • H04L51/18—Commands or executable codes
    • 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/131—Protocols for games, networked simulations or virtual reality

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Information Transfer Between Computers (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Procedimiento de recepción por un terminal (3) de un mensaje (M') proveniente de un servidor (4), a través de una red de telecomunicaciones, comprendiendo este mensaje metadatos (META) que definen, en relación con al menos un contenido multimedia un desafío a presentar, a un usuario (B) del terminal (3), una respuesta esperada a este desafío, y datos de acceso (@CONT) a dicho al menos un contenido multimedia en dicho servidor, agrupando dichos metadatos la información requerida para la ejecución de dicho desafío en dicho terminal (3), comprendiendo el procedimiento de recepción: - una etapa de descarga (E220, E230) de dicho al menos un contenido multimedia a partir de dichos datos de acceso; - una etapa de presentación del desafío (E240, E250) definido por los metadatos por un módulo de presentación de desafío instalado en el terminal (3), comprendiendo esta etapa de presentación: - una etapa de presentación (E240) al usuario (B) del terminal (3) de al menos una página de interfaz de usuario con el desafío; - una etapa de obtención de una respuesta del usuario (B) a este desafío; - una etapa de verificación de una correspondencia entre la respuesta obtenida del usuario (B) y la respuesta esperada al desafío definida en los metadatos; y - una etapa de restitución o no de dicho contenido multimedia en su totalidad dependiendo de si la respuesta obtenida del usuario (B) corresponde o no a la respuesta esperada al desafío.

Description

DESCRIPCIÓN
Procedimiento de construcción de un mensaje por un terminal
Antecedentes de la invención
La invención se refiere al campo general de las aplicaciones de software.
La invención se refiere, más particularmente, a un mecanismo que permite enriquecer las funcionalidades de una aplicación de software con carácter lúdico instalada en un terminal de un usuario, y, en concreto, en un terminal móvil como por ejemplo un teléfono inteligente o "smartphone" en inglés, una tableta digital, etc.
Hoy asistimos a una locura por parte de los usuarios por los juegos electrónicos o videojuegos, y más particularmente, por los juegos que los usuarios pueden instalar en sus terminales móviles.
Estos juegos instalados en los terminales de los usuarios son, generalmente, de carácter individual, es decir que proponen desafíos destinados exclusivamente a un solo jugador (es decir, el usuario del terminal) y no permiten a varios usuarios comunicarse o interactuar directamente entre sí.
Algunos juegos están dotados de una funcionalidad que les permite publicar las puntuaciones obtenidas por los usuarios en un servidor web o un servidor de una red social para compartir esta puntuación con otros usuarios. Sin embargo, las interacciones entre usuarios siguen siendo limitadas.
Por lo tanto, los inventores han constatado que en la actualidad, en el estado de la técnica, no existe un procedimiento que permita asociar en terminales, y en concreto en terminales móviles, un juego que propone un desafío (es decir, un programa o una aplicación de software de carácter lúdico) y un software o un servicio de comunicación que permita a los usuarios comunicarse con otros usuarios, por ejemplo, mediante un mensaje.
El documento GB 2359640 describe un procedimiento y un sistema de difusión de información que puede aplicarse en el marco de un juego en línea.
Objeto y sumario de la invención
La invención propone un mecanismo que, basándose en principios técnicos de un juego (a través de la producción de un desafío y la presentación de este desafío a un usuario destinatario), ofrece un nuevo modo de interacción entre dos usuarios o más para la implementación de dichos juegos, aprovechando la existencia de servicios de comunicación por mensaje disponibles en una red de telecomunicaciones, tal como, en concreto, en una red de telecomunicaciones móvil.
Este mecanismo se basa en tres entidades distintas así como en los procedimientos implementados por estas entidades, a saber un terminal de un usuario emisor de un mensaje en el que se insertan datos de definición de un desafío (es decir de un challenge), y por medio del cual el usuario emisor puede compartir un contenido multimedia con otro usuario llamado destinatario, el terminal del usuario destinatario que es capaz de presentar (es decir de ejecutar) el desafío propuesto por el usuario emisor al usuario destinatario, y un servidor colocado en corte de flujo entre el terminal del usuario emisor y el terminal del usuario destinatario y que es capaz de suministrar el contenido multimedia al terminal del usuario destinatario.
Por contenido multimedia, se entiende en el presente documento cualquier tipo de contenido digital como, por ejemplo, un contenido de audio o vídeo, un texto o incluso una imagen.
Más específicamente, la invención está definida por las reivindicaciones independientes adjuntas.
Por datos de acceso al contenido multimedia, se entiende en el presente documento bien el propio contenido multimedia, o bien datos tales como por ejemplo una dirección o una URL (Uniform Resource Locator) que permiten acceder al contenido multimedia en una entidad local o remota.
La invención tiene como objetivo enriquecer las posibilidades de interacción entre varios usuarios a través de juegos en forma de desafíos. La implementación de la invención hace uso de un módulo de definición de desafío en el terminal emisor del mensaje, siendo este módulo de definición de desafío capaz de generar metadatos que definen un desafío y de transmitir estos metadatos con destino a un usuario destinatario, para procesamiento y decodificación de los metadatos del desafío por un módulo correspondiente - llamado módulo de presentación de desafío - ejecutado en el terminal del usuario destinatario.
El desafío creado de este modo está destinado a acompañar un contenido multimedia seleccionado por el usuario emisor para el usuario destinatario que hace lúdico el acceso a este contenido por el usuario destinatario. El usuario puede, en concreto, en este contexto elegir contenidos multimedia que no revisten un carácter de urgencia o de importancia.
Por "metadatos que definen, en relación con un contenido multimedia, un desafío a presentar a un usuario destinatario", se entiende en el presente documento que los metadatos definen un desafío destinado a enmarcar el suministro del contenido multimedia al usuario destinatario. Este desafío puede, de este modo, por ejemplo condicionar la restitución (es decir, presentación) en sentido estricto del contenido multimedia al usuario destinatario, o proponer una restitución parcial de este contenido multimedia o una restitución de una versión transformada del contenido multimedia (por ejemplo, resultante de un truncamiento, una ofuscación o un enmascaramiento de ciertas partes del contenido), siendo suministrado el contenido multimedia en su totalidad al usuario destinatario en caso de resolución con éxito del desafío por este. El desafío definido por los metadatos puede ser independiente del contenido multimedia (por ejemplo, una pregunta cualquiera, un acertijo) o estar definido a partir de este (por ejemplo, un rompecabezas construido a partir del contenido multimedia a reconstituir, una imagen truncada del contenido multimedia a adivinar, etc.).
Los metadatos de un desafío son datos de definición de ese desafío que definen (es decir, describen) explícitamente o de manera codificada al menos un desafío y la respuesta esperada a ese desafío. Se trata de datos alfanuméricos (es decir, de tipo texto), de acuerdo, preferentemente, con una lógica de codificación común al módulo de definición de desafío y al módulo de presentación de desafío instalado en el terminal de dicho al menos un usuario destinatario, a fin de limitar la cantidad de información que debe transmitirse al terminal del usuario destinatario para permitir la ejecución del desafío.
En otras palabras, los metadatos agrupan la información requerida para la ejecución del desafío por el módulo de presentación de desafío instalado en el terminal de dicho al menos un usuario destinatario del mensaje.
Estos metadatos pueden comprender en concreto el tipo de desafío propuesto por el usuario emisor, parámetros de este desafío como por ejemplo preguntas planteadas durante la presentación (es decir durante la ejecución) del desafío para un desafío de tipo cuestionario o QCM, la respuesta esperada al desafío, la posición de las piezas del rompecabezas para un desafío de tipo rompecabezas, etc.
También pueden comprender una duración máxima para suministrar una respuesta al desafío tras una presentación del desafío a un llamado usuario destinatario. Esta característica permite añadir una dimensión lúdica suplementaria al desafío propuesto por el usuario emisor al usuario destinatario del mensaje.
Los metadatos también pueden servir para identificar al menos una operación a ejecutar tras la presentación del desafío por el módulo de presentación de desafío instalado en el terminal del usuario destinatario, dependiendo de si una respuesta suministrada por dicho al menos un usuario destinatario corresponde o no a la respuesta esperada. Pueden comprender además según el tipo de desafío previsto, una información representativa de la naturaleza de dicho al menos un contenido multimedia, permitiendo de este modo al módulo de presentación de desafío instalado en el terminal del usuario destinatario utilizar un módulo de restitución apropiado del contenido multimedia.
La invención propone, de este modo, una alternativa lúdica a los servicios de comunicación actuales, tales como los servicios de comunicación por SMS (Short Messaging Service) o por MMS (Multimedia Messaging Service). Amplía ventajosamente las capacidades de los servicios que existen actualmente en las redes de comunicaciones móviles proponiendo una nueva experiencia a los usuarios, sin dejar de ser compatibles con estos servicios.
La invención permite, en efecto, a un usuario de un terminal crear sus propios desafíos gracias a su terminal, por medio, por ejemplo, de una interfaz de usuario prevista a tal efecto. El desafío puede consistir en ocultar un contenido multimedia en el desafío así creado, y en presentar a un destinatario de su elección el desafío y el contenido multimedia oculto en el desafío. La resolución con éxito del desafío (en otras palabras, el suministro de la respuesta esperada al desafío, también incluida en los metadatos del desafío) permite al usuario destinatario del mensaje acceder al contenido multimedia que le ha enviado el usuario emisor. La experiencia de los usuarios en materia de comunicaciones se enriquece de este modo, volviéndose las interacciones entre los usuarios lúdicas gracias a la invención.
Diferentes tipos de desafíos pueden ser producidos fácilmente por el usuario emisor a través de su terminal, como por ejemplo:
- rompecabezas elaborados a partir del contenido multimedia seleccionado por el usuario,
- pruebas a ciegas, pruebas de tipo cuestionario o preguntas de opción múltiple en relación o no con el contenido multimedia,
- fotografías misteriosas o, más generalmente, contenido multimedia misterioso que presenta al usuario destinatario el contenido multimedia seleccionado por el usuario emisor después de haberlo sometido a una transformación (por ejemplo, truncamiento, ofuscación o enmascaramiento de ciertas partes del contenido).
- etc.
Preferentemente, estos desafíos se seleccionan para ser simples y rápidos de ejecutar por el usuario destinatario del mensaje.
En un modo particular de realización, el desafío puede ser seleccionado por el usuario emisor entre un catálogo de desafíos predeterminados adaptado a dicho al menos un usuario destinatario del mensaje.
Este catálogo de desafíos se puede actualizar con al menos un nuevo desafío seleccionado para dicho al menos un usuario destinatario después de la recepción de un mensaje del servidor. Este mensaje informa por ejemplo al usuario emisor de los éxitos o de los fracasos del usuario destinatario en resolver los desafíos que le propone.
El usuario emisor puede personalizar, de este modo, su mensaje.
De este modo, de acuerdo con la invención, el módulo de presentación de desafío instalado en el terminal del usuario destinatario es capaz de analizar e interpretar los metadatos de desafío recibidos para:
- presentar al usuario destinatario al menos una página de interfaz de usuario con un desafío al que debe responder, combinando una plantilla de página de interfaz de usuario con los metadatos, y opcionalmente (en función del tipo de desafío considerado) el contenido multimedia definido por el usuario emisor;
- obtener la respuesta suministrada por este usuario y determinar si la respuesta dada es buena o mala, y - desencadenar
- una restitución de dicho al menos un contenido multimedia.
De este modo, de acuerdo con la invención, durante la presentación de un desafío por el terminal del usuario destinatario, una sucesión de páginas de interfaz de usuario es presentada al usuario destinatario.
El diseño de una de estas páginas de interfaz de usuario utilizadas para la presentación de un desafío está predefinido, preferentemente, a partir de un modelo de interfaz de usuario o plantilla (en inglés "template"). Cada página de interfaz de usuario comprende una pluralidad de elementos que participan en la presentación del desafío al usuario destinatario (como por ejemplo para un desafío de tipo cuestionario, una lista que propone diferentes opciones de respuestas entre las cuales figura la respuesta esperada al desafío, etc.). La disposición y el tamaño de estos elementos que aparecen en cada página de interfaz de usuario así como la sucesión de las diferentes páginas son predefinidas para un tipo de desafío dado, de modo que solo el elemento que debe ser presentado en el lugar elegido en una página para este elemento necesita ser especificado por el usuario emisor para que el desafío pueda ser presentado al usuario destinatario en una forma comprensible y utilizable. De este modo, solo algunos parámetros del desafío (incluyendo los elementos a mostrar en las páginas de interfaz de usuario) y uno o varios contenidos multimedia deben ser transmitidos por mensaje de un terminal al otro para la implementación de un desafío, y no páginas de interfaz de usuario completas.
El tipo de desafío y los parámetros del desafío mencionados anteriormente se describen ventajosamente en los metadatos de un desafío que son transmitidos de un terminal a otro. Al haber páginas completas de interfaz de usuario que no necesitan ser transmitidas, la cantidad de información a transmitir del terminal del usuario emisor hacia el terminal del usuario destinatario se reduce.
Al recibir los metadatos de un desafío, la o las plantillas de páginas de interfaz de usuario asociado al tipo de desafío identificado en los metadatos son utilizados entonces por el módulo de presentación de desafío del terminal del usuario destinatario, modificados a partir de los metadatos del desafío para generar una o varias páginas de interfaz de usuario a presentar durante la presentación del desafío.
Como se ha mencionado anteriormente, según un modo particular de realización, los metadatos de desafío son datos alfanuméricos de acuerdo con una lógica de codificación común al módulo de definición de desafío del terminal del usuario emisor y al módulo de presentación de desafío del terminal del usuario destinatario.
Por ejemplo un código alfanumérico de uno o dos bytes se puede utilizar para codificar el tipo de desafío y un desarrollo asociado a este tipo de desafío, es decir una sucesión de páginas de interfaz de usuario asociada. De esta manera, la cantidad de información a transmitir de un terminal de un usuario a otro se reduce.
Según un tercer aspecto, la invención tiene como propósito también un sistema que comprende un servidor, que juega de este modo el papel de proxy entre el terminal del usuario emisor del mensaje y el terminal del usuario destinatario. Almacena ventajosamente el o los contenidos multimedia seleccionados por el usuario emisor para el usuario destinatario para limitar la cantidad de datos enviada hacia el terminal del usuario destinatario. El o los contenidos multimedia pueden ser, de este modo, descargados por el terminal del usuario destinatario únicamente cuando el usuario destinatario prevé ejecutar el desafío que le es propuesto, previamente a esta ejecución.
Cabe señalar que desde el punto de vista del usuario emisor en el origen del mensaje, la presencia del servidor es transparente. El usuario emisor continúa seleccionando el destinatario de su mensaje como lo hace para cualquier mensaje enviado desde su terminal (tal como, por ejemplo, para un mensaje que responde a la norma de telefonía móvil).
En un modo particular de realización, dicho al menos un contenido multimedia es transmitido al servidor en el mensaje que contiene los metadatos. Este mensaje es, por ejemplo, una solicitud HTTP (HyperText Transfer Protocol) de tipo POST, conocida per se. Esta transmisión "agrupada" facilita el procesamiento de los datos enviados por el terminal emisor (metadatos y contenido(s) multimedia) por el servidor.
En otro modo de realización, dicho al menos un contenido multimedia es transmitido al servidor en un mensaje distinto del mensaje que contiene los metadatos. Los metadatos son, por ejemplo, transmitidos en una solicitud HTTP de tipo GET, mientras que el o los contenidos multimedia son transmitidos en una solicitud HTTP de tipo POST utilizando como parámetro un identificador suministrado por el servidor que le permite asociar los metadatos recibidos en la solicitud de tipo GET al o a los contenidos multimedia recibidos en la solicitud de tipo POST.
Como variante, los metadatos y/o los contenidos multimedia pueden ser enviados según otro formato de mensaje, como, en concreto, un mensaje SMS, un mensaje MMS, un formato de mensaje aceptado en un paquete de comunicación, tal como por ejemplo un paquete de comunicación enriquecida RICH o "Joyn ®", un formato de mensaje aceptado por una red social, tal como por ejemplo "Facebook ®", etc.
En un modo particular de realización, el procedimiento de procesamiento comprende:
- una etapa de verificación de que el terminal de dicho al menos un usuario destinatario del mensaje está equipado con un módulo de presentación de desafío capaz de presentar el desafío definido por los metadatos; - si el terminal de dicho al menos un usuario destinatario no está equipado con el módulo de presentación de desafío, una etapa de envío de un mensaje que invita a este terminal a instalar este módulo de presentación de desafío;
siendo el mensaje que comprende los metadatos enviado al terminal cuando el módulo de presentación de desafío está instalado en este.
Este modo de realización se acomoda ventajosamente debido a que todos los terminales no están necesariamente equipados para interpretar y procesar los metadatos emitidos por el terminal emisor, y ejecutar el desafío definido en estos metadatos. Propone a tal efecto implementar a nivel del servidor colocado en corte de flujo entre los terminales de los usuarios emisor y destinatario, una verificación que tiene como propósito asegurarse de que el terminal del usuario destinatario es bien capaz de presentar al usuario destinatario el desafío construido por el usuario emisor, y si este no es el caso, de enviar un mensaje al terminal destinatario permitiéndole instalar un módulo de presentación de desafío capaz de interpretar los metadatos enviados por mensaje por el terminal del usuario emisor.
En un modo particular de realización, el procedimiento de construcción comprende una etapa de registro previa del terminal del usuario emisor en del servidor como usuario de un módulo de definición de desafío y/o de un módulo de presentación de desafío.
Esta etapa de registro previa permite facilitar el procesamiento del mensaje enviado por el terminal del usuario emisor al servidor. Permite al servidor identificar más rápidamente los terminales compatibles con la invención, dicho de otro modo los que disponen de un módulo de definición y de presentación de desafío de acuerdo con la invención. De este modo, por ejemplo, la etapa de verificación puede limitarse entonces a la verificación de que dicho al menos un usuario destinatario del contenido multimedia enviado por el terminal del usuario emisor es registrada en del servidor.
Además, esto permite al servidor anticipar la verificación de los terminales compatibles con la invención, y esto desde el registro del terminal.
En un modo particular de realización, la etapa de registro puede comprender el suministro al servidor de una lista de contactos del usuario emisor memorizado en el terminal en el que está asociado al identificador del usuario destinatario un identificador de terminal.
El usuario emisor no está, de este modo, obligado a especificar un identificador de terminal cuando compone su mensaje para designar el usuario destinatario pero puede utilizar cualquier tipo de identificador en cuanto este está asociado en su lista de contactos a un identificador de terminal. Esto hace más fácil la composición del mensaje por el usuario emisor.
En un modo particular de realización de la invención del procedimiento de procesamiento, el mensaje de invitación es enviado al segundo terminal a través de una red de telecomunicaciones móvil. Se trata, por ejemplo, de un mensaje corto de tipo SMS.
La invención tiene, de este modo, una aplicación privilegiada pero no limitativa cuando los terminales son terminales móviles. Además, se basa ventajosamente en soportes de comunicación que ya existen en estos terminales, en este caso particular un SMS.
En un modo particular de realización, el procedimiento de procesamiento implementado por el servidor comprende una etapa de recepción de un mensaje proveniente del terminal de un llamado usuario destinatario que informa de un fracaso o un éxito de dicho usuario destinatario para suministrar la respuesta esperada al desafío durante la presentación de este desafío por el terminal.
Este mensaje puede permitir ventajosamente al servidor mantener puntuaciones para los usuarios para valorarlos y animarlos a dilucidar los desafíos que se les envían. De este modo, por ejemplo, el procedimiento de procesamiento implementado por el servidor puede comprender una etapa de actualización de una puntuación asociada a dicho al menos un usuario destinatario en función del fracaso o del éxito informado en el mensaje recibido del terminal de este usuario destinatario.
Además de la valoración de los usuarios, las puntuaciones mantenidas actualizadas por el servidor pueden ser utilizadas para proponer nuevos desafíos a los usuarios o adaptar los desafíos que les son propuestos, como se ha mencionado anteriormente.
Como variante, una puntuación también puede atribuirse a cada usuario emisor de un mensaje construido de acuerdo con la invención para valorar los usuarios más activos.
Como variante, el mensaje enviado por el terminal del usuario destinatario puede permitir al servidor desbloquear el contenido multimedia presente en el mensaje construido de acuerdo con la invención en caso de fracaso informado por este terminal y tras el acuerdo del usuario emisor.
En un modo particular de realización, el procedimiento de procesamiento implementado por el servidor comprende, después de la etapa de actualización:
- una etapa de clasificación de dicho al menos un usuario destinatario en función de su puntuación con respecto a una pluralidad de usuarios registrados en el servidor; y
- una etapa de envío de la clasificación al terminal de dicho al menos un usuario destinatario y/o al terminal del usuario emisor.
En un modo particular de realización, las diferentes etapas del procedimiento de construcción de un mensaje y/o del procedimiento de procesamiento y/o del procedimiento de recepción según la invención son determinadas por instrucciones de programas informáticos.
En consecuencia, la invención también tiene como propósito un programa informático en un soporte de información, siendo este programa susceptible de ser implementado en un terminal o más generalmente en un ordenador, constando este programa de instrucciones adaptadas a la implementación de las etapas de un procedimiento de construcción de un mensaje tal como se ha descrito anteriormente.
La invención también tiene como propósito un programa informático en un soporte de información, siendo este programa susceptible de ser implementado en un servidor o más generalmente en un ordenador, constando este programa de instrucciones adaptadas a la implementación de las etapas de un procedimiento de procesamiento tal como se describió anteriormente.
La invención también se refiere a un programa informático en un soporte de información, siendo este programa susceptible de ser implementado en un terminal o más generalmente en un ordenador, constando este programa de instrucciones adaptadas a la implementación de las etapas de un procedimiento de recepción tal como se ha descrito anteriormente.
Cada uno de estos programas puede utilizar cualquier lenguaje de programación, y estar en forma de código fuente, código objeto o código intermedio entre código fuente y código objeto, tal como en una forma parcialmente compilada, o en no importa qué otra forma deseable.
La invención también tiene como propósito un soporte de información legible por un ordenador, y que consta de instrucciones de un programa informático tal como se mencionó anteriormente.
El soporte de información puede ser cualquier entidad o dispositivo capaz de almacenar el programa. Por ejemplo, el soporte puede constar de un medio de almacenamiento, tal como una ROM, por ejemplo, un CD-ROM o una r Om de circuito microelectrónico o también un medio de registro magnético, por ejemplo, un disquete (floppy disc) o un disco duro.
Por otra parte, el soporte de información puede ser un soporte transmisible, tal como una señal eléctrica u óptica, que puede encaminarse a través de un cable eléctrico u óptico, por radio o por otros medios. El programa de acuerdo con la invención puede descargarse en particular desde una red de tipo Internet.
Como alternativa, el soporte de información puede ser un circuito integrado en el que está incorporado el programa, estando adaptado el circuito para ejecutar o para ser utilizado en la ejecución del procedimiento en cuestión.
Según otro aspecto, la invención tiene como propósito un sistema que comprende:
- un terminal de un usuario llamado emisor de acuerdo con la invención;
- al menos un terminal de al menos un usuario llamado destinatario según la invención; y
- un servidor según la invención;
siendo el terminal del usuario emisor capaz de enviar un mensaje y datos de acceso a al menos un contenido multimedia al servidor, comprendiendo este mensaje metadatos que definen, en relación con dicho al menos un contenido multimedia, un desafío a presentar a dicho al menos un usuario destinatario y una respuesta esperada a este desafío, siendo dicho servidor capaz de retransmitir los metadatos y dicho al menos un contenido multimedia a dicho al menos un terminal de dicho al menos un usuario destinatario para presentación de este desafío.
El sistema dispone de las mismas ventajas que las mencionadas anteriormente para los terminales y el servidor según la invención.
La invención propone, por lo tanto, un nuevo servicio que ofrece un uso de una red de telecomunicaciones lúdico, espontáneo, fácil y sencillo, así como una nueva forma de comunicarse entre los usuarios.
También se puede prever, en otros modos de realización, que el procedimiento de construcción, el procedimiento de procesamiento, el procedimiento de recepción, los terminales, el servidor y el sistema según la invención presenten en combinación todas o parte de las características mencionadas anteriormente.
Breve descripción de los dibujos
Otras características y ventajas de la presente invención se pondrán de manifiesto a partir de la descripción realizada más adelante, con referencia a los dibujos adjuntos que ilustran ejemplos de realización de esta desprovistos de cualquier carácter limitativo. En las figuras:
- la figura 1 representa, de forma esquemática, un terminal, un servidor y un sistema de acuerdo con la invención en un modo particular de realización;
- la figura 2 representa la arquitectura material del terminal de la figura 1;
- la figura 3 representa la arquitectura material del servidor de la figura 1;
- la figura 4 ilustra las principales etapas de un procedimiento de construcción de un mensaje y de un procedimiento de procesamiento de un mensaje de acuerdo con la invención en un modo particular de realización en el que son implementados, respectivamente por el terminal y por el servidor de la figura 1;
- la figura 5 ilustra las principales etapas de construcción de un mensaje implementadas por el terminal de la figura 1 en el transcurso del procedimiento de construcción según la invención; y
- las figuras 6A a 6H ilustran ejemplos de página de interfaz gráfica de usuario utilizados para la definición de los metadatos de un desafío y que permiten la construcción de un mensaje de acuerdo con la invención;
- las figuras 6H y 6I ilustran ejemplos de páginas de interfaz gráfica de usuario que pueden presentarse al usuario destinatario durante la presentación de un desafío.
Descripción detallada de la invención
La figura 1 representa, en su entorno, un sistema 1 de acuerdo con la invención en un modo particular de realización. Este sistema ofrece un servicio S de intercambio de mensajes "lúdicos" entre un primer usuario A equipado con un terminal 2 de acuerdo con la invención (terminal de un usuario emisor en el sentido de la invención), y un segundo usuario B equipado con un terminal 3 (terminal de un usuario destinatario en el sentido de la invención), basado en la producción y la presentación de desafíos que acompañan a contenidos multimedia. Por contenido multimedia se entiende cualquier tipo de contenido digital y, más específicamente, contenidos de audio y/o vídeo e imágenes. En aras de simplificación en la descripción, se considera un intercambio de mensajes entre dos usuarios únicamente a través de sus respectivos terminales. Sin embargo, la invención también permite el intercambio de mensajes entre un número de usuarios superior a 2 a través de sus respectivos terminales 3.
No se adscribe ninguna limitación a la naturaleza de los terminales 2 y 3. En el ejemplo previsto en la figura 1, estos terminales son teléfonos inteligentes, también conocidos con el nombre de "smartphones", capaces de comunicarse en una red de telecomunicaciones móviles NW1 tal como por ejemplo una red de tercera generación (por ejemplo, red UMTS) o de cuarta generación. Se supone, a tal efecto, que un identificador IDA, respectivamente IDB, ha sido asignado por el operador de la red de telecomunicaciones móviles NW1 al usuario A, respectivamente al usuario B, para comunicarse en la red NW1. Los identificadores IDA e IDB son, por ejemplo, en el presente documento números de teléfono.
Los terminales 2 y 3 pueden, como variante, estar equipados con otras interfaces de comunicación, tales como, por ejemplo, una interfaz de tipo WiFI (Wireless FIdelity), o ser capaces de comunicarse en redes de telecomunicaciones móviles distintas.
En el modo de realización descrito en el presente documento, el terminal 2 está equipado con una aplicación de software APLI que permite al usuario A beneficiarse del servicio S y, más precisamente, enviar y recibir contenidos multimedia (por ejemplo, fotografía, archivo de texto, mensaje de tipo texto, archivos de audio y/o vídeo, etc.) acompañados de desafíos cuya resolución desencadena la restitución de estos contenidos multimedia. En otras palabras, en el modo de realización descrito en el presente documento, el usuario destinatario de dicho contenido multimedia solo puede acceder a él en su totalidad si resuelve con éxito el desafío que le está adjunto.
Este desafío es producido (es decir, definido o construido) por el usuario A con ayuda de un módulo de definición de desafío implementado por la aplicación APLI, que se basa en este caso en una interfaz gráfica de usuario IU implementada por la aplicación APLI y a través del cual el usuario A puede interactuar con el módulo de definición de desafío. Esta interfaz de usuario IU ofrece una herramienta de edición de un mensaje que contiene un desafío para el usuario a la vez simple y fácil de usar. El desafío producido por el usuario A es, por ejemplo, un cuestionario, un rompecabezas a reconstruir, un archivo de audio truncado o una imagen oculta o parcialmente enmascarada que debe identificar, una pregunta de opción múltiple, etc. No se adjunta ninguna limitación al tipo de desafío previsto durante la implementación de la invención.
Como se ha mencionado anteriormente, la aplicación APLI permite también aquí al usuario A acceder a contenidos multimedia emitidos por otros terminales por medio de la aplicación APLI, dicho de otro modo, acompañados de desafíos a resolver. Por lo tanto, también implementa un módulo de presentación de desafíos definidos en el marco del servicio S en el sentido de la invención.
De acuerdo con la invención, para la implementación del servicio S, el sistema 1 comprende no solamente los terminales 2 y 3 sino también un servidor 4 de procesamiento de los mensajes emitidos por el terminal 2, de acuerdo con la invención.
Este servidor 4 está en corte de flujo de todos los mensajes emitidos por el terminal 2 y construidos por medio de la aplicación APLI. Es accesible en este caso a través de una red pública NW2, típicamente la red pública Internet. La dirección de contacto del servidor 4 en esta red NW2 (es decir, la dirección con la que puede comunicarse y es accesible) expresada @oC4, se configura en la aplicación APLI.
Como variante, la dirección @oC4 se introduce en una lista de contactos (directorio) almacenada en el terminal 2 y accesible por la aplicación APLI.
Se supone en el presente documento que los intercambios implementados entre la aplicación APLI instalada en el terminal 2 y el servidor 4 están de acuerdo con los protocolos HTTP (HyperText Transfer Protocol) y HTTPs (HyperText Transfer Protocol secure). No obstante, como variante, se pueden prever otros protocolos.
En el modo de realización descrito en el presente documento, el terminal 2 tiene la arquitectura material de un ordenador, tal como se ilustra en la figura 2. Comprende, en concreto, un procesador 2A, una memoria de solo lectura 2B, una memoria de acceso aleatorio 2C, una memoria no volátil 2D en la que se memoriza en el presente documento la aplicación APLI, medios de comunicación 2E en la red de telecomunicaciones móviles NW1 que le permiten en concreto comunicarse con el servidor 4, y medios de entrada/salida 2f que le permiten interactuar con el usuario A. Estos medios de entrada/salida comprenden, en concreto, en el presente documento una pantalla táctil, un teclado virtual, así como diversos medios de restitución de contenido multimedia, tales como, por ejemplo, altavoces, un "reproductor" de vídeo, etc. La interfaz gráfica de usuario IU implementada por la aplicación APLI se basa ventajosamente en los medios de entrada/salida 2F.
La memoria de sólo lectura 2B del terminal 2 constituye un soporte de registro legible por el procesador 2A y en el que se registra un programa informático de acuerdo con la invención, que consta de instrucciones para la ejecución de las etapas de un procedimiento de construcción de un mensaje según la invención, describiéndose las etapas de este procedimiento más adelante con referencia a las figuras 4, 5 y 6A-6H en un modo particular de realización.
Este programa informático define de forma equivalente módulos funcionales del terminal 2 (módulos de software en el presente documento) y más particularmente de la aplicación de software APLI, tales como un módulo de selección de un contenido multimedia y un destinatario del mensaje, un módulo de definición de un desafío (basándose en concreto en la interfaz de usuario IU y en medios de entrada/salida 2F del terminal 2) y un módulo de envío de este mensaje al servidor 4 a través de la red NW1 (basándose en concreto en los medios de comunicación 2E del terminal 2). Las funciones de estos diversos módulos funcionales se describen con más detalle con referencia a las etapas del procedimiento de construcción.
La memoria de solo lectura 2B es también un soporte de registro legible por el procesador 2A y en el que se registra un programa informático de acuerdo con la invención, que consta de instrucciones para la ejecución de las etapas de un procedimiento de recepción de un mensaje según la invención, describiéndose las etapas de este procedimiento más adelante con referencia a las figuras 4, 5 y 6A-6I en un modo particular de realización.
Este programa informático define de forma equivalente módulos funcionales del terminal 2 (módulos de software en el presente documento) y más particularmente de la aplicación de software APLI, tales como un módulo de recepción de un mensaje y de descarga de un contenido multimedia (basándose en concreto en los medios de comunicación 2E del terminal 2), y un módulo de presentación de un desafío (basándose en concreto en la interfaz de usuario IU y en los medios de entrada/salida 2F del terminal 2). Las funciones de estos diversos módulos funcionales se describen con más detalle con referencia a las etapas del procedimiento de recepción.
El terminal 3 tiene una arquitectura material y funcional idéntica a la del terminal 2. De forma similar, el servidor 4 también tiene, en el modo de realización descrito en el presente documento, la arquitectura material de un ordenador tal como se ilustra en la figura 3. Comprende, en concreto, un procesador 4A, un disco duro (o una memoria de solo lectura) 4B, una memoria de acceso aleatorio 4C, una memoria no volátil 4D, medios de comunicación 4E en la red pública Internet NW2 y en la red de telecomunicaciones móvil NW1. Los medios de comunicación 4E permiten al servidor 4 comunicarse, en concreto, con los terminales 2 y 3, así como con otras entidades, tales como por ejemplo una base de datos 5A, en la que se memorizan diversas informaciones como los usuarios registrados en el servidor 4 que se hayan abonado al servicio S, sus números de teléfono en la red de telecomunicaciones móvil NW1 (o en otra red de telecomunicaciones móvil), etc.
La memoria no volátil 4D es en el presente documento el medio de registro de una base de datos en la que los metadatos de definición de desafíos destinados a los usuarios registrados en el servidor 4, así como un directorio en el que se memorizan los contenidos multimedia asociados a estos desafíos. El servidor 4 atribuye a cada contenido multimedia almacenado en este directorio un identificador único asociado, en la base de datos, al desafío correspondiente, es decir, al desafío destinado a ser suministrado al usuario destinatario del contenido multimedia. Cada contenido multimedia almacenado en el directorio es accesible a través de una dirección URL en el presente documento.
El disco duro 4B del servidor 4 constituye un soporte de registro legible por el procesador 4A y en el que se registra un programa informático de acuerdo con la invención, que consta de instrucciones para la ejecución de las etapas de un procedimiento de procesamiento de un mensaje según la invención, describiéndose las etapas de este procedimiento más adelante con referencia a las figuras 4, 5 y 6A-6H en un modo particular de realización.
Este programa informático define de forma equivalente módulos funcionales del servidor 4 (módulos de software en el presente documento), tales como un módulo de recepción de un mensaje compuesto con la aplicación APLI que contiene un desafío y datos de acceso a un contenido multimedia proveniente del terminal 2, en el presente documento un módulo de verificación de que el terminal del usuario destinatario del contenido multimedia está equipado con un módulo de presentación de desafío (por ejemplo de la aplicación APLI en el presente documento) que le permite leer y procesar los metadatos (dicho de otro modo, proponer el desafío definido por estos metadatos al usuario destinatario), un módulo de envío de un mensaje de invitación a instalar este módulo de presentación de desafío si el terminal receptor no está equipado con él, un módulo de almacenamiento capaz de almacenar el contenido multimedia en el directorio del servidor 4 y los metadatos de desafío en la base de datos del servidor 4, y un módulo de envío de un mensaje al terminal del usuario destinatario que comprende los metadatos y la dirección en el directorio del contenido multimedia asociado (o el propio contenido multimedia). Los módulos de recepción, de invitación y de envío se basan en concreto en los medios de comunicación 4E del servidor. Las funciones de estos diversos módulos funcionales se describen con más detalle con referencia a las etapas del procedimiento de procesamiento.
A continuación, se van a describir, con referencia a las figuras 4, 5 y 6A-6H, las principales etapas del procedimiento de construcción de un mensaje, del procedimiento de procesamiento de un mensaje y del procedimiento de recepción de un mensaje según la invención, en un modo particular de realización en el que son implementados respectivamente por el terminal 2, por el servidor 4, y por el terminal 3 del usuario B de la figura 1.
Con referencia a la figura 4, se supone que el usuario A (usuario emisor) desea compartir un contenido multimedia con el usuario B (usuario destinatario), y decide para este fin enviarle un mensaje construido (es decir, compuesto) con la aplicación APLI. A tal efecto, inicia la aplicación APLI instalada en su terminal 2, que se conecta al servidor 4 del que conoce la dirección de contacto o de accesibilidad @oC4 como se ha mencionado anteriormente, (etapa E10). El inicio de la aplicación APLI se traduce en la visualización de una sucesión de páginas de interfaz de usuario (o ventanas de composición) utilizadas para la construcción de un mensaje y la definición de un desafío destinado al usuario B. En lo sucesivo en la descripción se utilizan indistintamente los términos página de interfaz de usuario, ventana de composición o incluso ventana.
Durante la primera conexión de la aplicación APLI al servidor 4, la aplicación APLI se autentica y se registra, llegado el caso, en el servidor 4 para permitir que el usuario A se beneficie del servicio S.
Más específicamente, la aplicación APLI instalada en el terminal 2 envía al servidor 4, una solicitud de autenticación de acuerdo con el protocolo HTTP y que contiene el número de teléfono IDA del usuario A en la red de telecomunicaciones móvil NW1 (etapa E20). Esta solicitud de autenticación se envía en el presente documento a través de la red de telecomunicaciones NW1 y transita hasta el servidor 4 a través de la red pública Internet NW2. Al recibir la solicitud de autenticación del terminal 2, el servidor 4 verifica, interrogando a la base de datos 5 con ayuda del identificador IDA contenido en la solicitud de autenticación, si el usuario A está registrado y se ha abonado al servicio S (etapa E30).
Si el identificador IDA no está asociado en la base de datos 5 a un usuario que se haya abonado al servicio S (es decir, en el presente documento el usuario A no está registrado en el servidor 4 como un usuario de un servicio o de un módulo de definición y/o de presentación de desafíos), el servidor 4 solicita al terminal 2 que se abone (es decir, que se inscriba) en el servicio S (etapa E40). Esta solicitud se visualiza en una página de la interfaz de usuario IU de la aplicación APLI en la pantalla del terminal 2.
El usuario A responde a esta solicitud introduciendo, a través de los medios de entrada/salida 2F del terminal 2, su número de teléfono IDA en la red NW1 y su nombre A. Esta información es transmitida por el terminal 2, por medio de la aplicación APLI, al servidor 4 en una solicitud de inscripción o de abono al servicio S (etapa E50).
Al recibir la solicitud de abono del terminal 2, el servidor 4 almacena en la base de datos 5 el número de teléfono IDA en asociación con el nombre A del usuario A (etapa E60). El usuario A queda así registrado en el servidor 4. El servidor 4 envía un acuse de recibo que contiene un código al terminal 2 para que el usuario A introduzca este código desde una página de la interfaz IU de la aplicación APLI; el código introducido por el usuario A es reenviado al servidor 4 para la verificación y activación, llegado el caso, del servicio S (etapa E70). A partir de entonces, el usuario A puede beneficiarse del servicio S.
Cabe señalar que, en el modo de realización descrito en el presente documento, solo los usuarios equipados con la aplicación APLI pueden abonarse al servicio S y registrarse en el servidor 4. En otras palabras, para poder registrarse en el servidor 4 y abonarse al servicio S, los usuarios deben disponer de un módulo de definición de desafíos y/o de un módulo de presentación de desafíos destinados a estar provistos de contenidos multimedia.
En el modo de realización descrito en el presente documento, durante el registro del usuario A en el servidor 4, la aplicación APLI transmite también la lista de contactos del usuario A (es decir, su directorio) memorizada en el terminal 2, por ejemplo en su tarjeta SIM (Subscriber Identity Module) o en otro memoria del terminal, como por ejemplo la memoria no volátil 2D (etapa E80). Esta lista de contactos comprende, en concreto, una la lista de números de teléfono y/o de identificadores en diversas redes de telecomunicaciones fijas o móviles que permiten identificar terminales, así como los nombres de las personas (es decir, identificadores de usuarios) a los que están asociados estos números o identificadores. En el ejemplo previsto en el presente documento, esta comprende en concreto el número de teléfono del usuario B en la red NW1 y su nombre (identificadores que permiten identificar un terminal del usuario B en el sentido de la invención).
Esta lista de contactos es recibida por el servidor 4 y guardada en la base de datos 5, en asociación con el nombre del usuario A (etapa E90). A continuación, un acuse de recibo es enviado al terminal 2 (etapa E100).
Una vez se han completado el registro del usuario A y su autenticación, el usuario A puede construir (es decir, componer) un mensaje M utilizando las páginas de la interfaz de usuario IU previstas a tal efecto por la aplicación APLI (etapa E110). La interfaz gráfica de usuario IU ofrece la posibilidad a la aplicación APLI de interactuar con el usuario A para construir el mensaje M.
La etapa de construcción del mensaje M se representa de manera detallada en la figura 5. A título ilustrativo, en las figuras 6A-6H se representan ejemplos de páginas de interfaz gráfica de usuario IU que permiten guiar al usuario A lo largo de esta etapa de construcción del mensaje M en sus interacciones con la aplicación APLI.
De este modo, con referencia a la figura 6A, la interfaz de usuario IU visualiza en la pantalla del terminal 2 una página de inicio 6 que ofrece la posibilidad al usuario A de redactar un nuevo mensaje. El usuario A accede a esta posibilidad al designar el elemento "MENS" visualizado en la página de inicio, por ejemplo, pulsando en este elemento con el dedo para una pantalla táctil o con un lápiz óptico proporcionado a tal efecto (etapa E111).
La interfaz de usuario IU abre entonces en la pantalla del terminal 2 una nueva página de interfaz de usuario que comprende una ventana 7 de composición de un nuevo mensaje como se ilustra en la figura 6B. Esta ventana comprende un marco 8 en el que se invita al usuario A introducir el usuario destinatario del contenido multimedia que desea compartir el usuario A, dicho de otro modo, el usuario destinatario del mensaje. Con este fin, el usuario A puede utilizar el teclado virtual del terminal 2 o, como en el ejemplo previsto en el presente documento, seleccionar el usuario destinatario del mensaje entre la lista de sus contactos (es decir, su directorio) memorizada en su terminal móvil 2.
Se supone en el presente documento que el usuario A designa (es decir, selecciona) al usuario B como destinatario de su mensaje entre la lista de sus contactos. Esta designación permite a la aplicación APLI determinar (es decir, obtener) el destinatario del mensaje en construcción (etapa E112).
Como variante, varios usuarios destinatarios del mensaje pueden ser designados de forma similar por el usuario A.
Tras la obtención de o de los usuarios destinatarios del mensaje M, una sucesión de etapas que tienen como propósito definir un desafío destinado a ser presentado a este o a estos usuarios destinatarios es implementada de acuerdo con la invención por la aplicación APLI (y más precisamente por el módulo de definición de desafío de la aplicación APLI).
De este modo, en primer lugar, la interfaz de usuario IU visualiza una nueva ventana 9 en la pantalla del terminal 2 que propone al usuario A diferentes categorías de desafíos (o challenges, o incluso juegos). En el ejemplo ilustrado en la figura 6C, cuatro categorías de desafío predeterminadas C1, C2, C3 y C4 son propuestas al usuario A en la ventana de visualización 9. Por ejemplo, C1 es una categoría de desafíos de tipo "pruebas a ciegas", C2 es una categoría de desafíos de tipo "fotografías misteriosas", C3 es una categoría de desafíos de tipo "rompecabezas" y C4 es una categoría de desafíos de tipo "cuestionario". Estas cuatro categorías de desafíos C1, C2, c 3, C4 constituyen un catálogo de desafíos predeterminados suministrados por la aplicación APLI a través de la interfaz IU al usuario A para construir su mensaje en el sentido de la invención. Por supuesto, estos ejemplos se dan sólo a título ilustrativo y se pueden prever otros tipos de desafíos.
Se supone en el presente documento que el usuario A selecciona la categoría de desafíos C2 en la pantalla táctil del terminal 2. En el ejemplo previsto en el presente documento, tras esta selección, se visualiza una nueva ventana en la página de interfaz de usuario para permitir al usuario A introducir si lo desea, a través del teclado de su terminal 2, una dedicatoria destinada al usuario B (ejemplo, "Diviértete resolviendo este nuevo desafío", etc.) para acompañar al desafío.
A continuación, la interfaz gráfica de usuario IU de la aplicación APLI instalada en el terminal 2 propone al usuario A, por medio de una nueva página de interfaz de usuario 10 que define una ventana de composición del mensaje, construir propiamente dicho este último. Esta etapa de construcción se descompone en el presente documento en varias subetapas.
En primer lugar, el usuario A es invitado por medio de una ventana 11 que se abre en la ventana de composición 10, a definir o más generalmente a seleccionar uno (o varios) contenidos multimedia CONT que desea dirigir al usuario B. Este contenido multimedia puede ser de diferentes naturalezas: puede tratarse de una fotografía, de un archivo de audio, de un texto, de un archivo de vídeo, etc., dicho de otro modo, cualquier contenido multimedia producido por el usuario A (por ejemplo, texto introducido por el usuario A, fotografía tomada por el usuario A), memorizado previamente en su terminal 2 o en cualquier otro medio de almacenamiento (por ejemplo, en un servidor remoto).
En el marco del tipo de desafío C2 seleccionado por el usuario A (es decir, "fotografía misteriosa"), el contenido multimedia seleccionado por el usuario A es una fotografía. Varias opciones son ofrecidas en el presente documento por la interfaz IU al usuario A para elegir esta fotografía como se ilustra en la figura 6D, es decir, por ejemplo, el usuario A puede decidir tomar una nueva fotografía (seleccionando en este caso la pestaña CAM), seleccionar una fotografía ya memorizada en el terminal 2 (seleccionando en este caso la pestaña GAL) o suministrar un enlace a una fotografía almacenada en un servidor remoto (seleccionando en este caso la pestaña LINK).
Se supone en el presente documento que el usuario A selecciona la pestaña LINK. Esta selección es seguida por la visualización por la interfaz de usuario IU de una ventana 12 de introducción del enlace que permite acceder al contenido multimedia (fotografía) elegido por el usuario A. la introducción del enlace www.url-photo.jpg por el usuario A en la ventana de introducción 12 completa la obtención por la aplicación APLI de una identificación del contenido multimedia destinado a ser transmitido al usuario B (etapa E113).
Una vez terminada la definición del contenido multimedia, la interfaz de usuario IU propone al usuario A producir (es decir, construir) el desafío y la respuesta esperada a este desafío utilizados para condicionar el acceso al contenido multimedia (etapa E114). A tal efecto, la interfaz de usuario IU proporciona una nueva ventana de visualización 13 en la que se enumeran varias preguntas que pueden asociarse a la fotografía seleccionada por el usuario A en el marco del desafío "fotografía misteriosa". En el ejemplo ilustrado en la figura 6E, tres preguntas predeterminadas P1 = "¿quién es?", P2 =" ¿qué es?" y P3 = "¿dónde está?" se visualizan en la ventana 13. Las preguntas P1, P2, P3 constituyen un catálogo de elementos predeterminados suministrados por la aplicación APLI a través de la interfaz IU al usuario A para construir su desafío.
Como variante, el usuario A puede introducir estas preguntas a través del teclado del terminal 2.
En otra variante más, las preguntas pueden predeterminarse y almacenarse en la memoria no volátil 2D del terminal. De manera más general, el usuario A puede producir un desafío para el usuario B de desafíos preconcebidos y almacenados en una memoria no volátil del terminal, que a continuación es invitado a personalizar a través de la herramienta de edición y las páginas de la Interfaz (ventanas de composición) ofrecidas por la interfaz de usuario IU. Se supone en el presente documento que el usuario A selecciona la pregunta P3.
Tras esta selección, la interfaz de usuario IU presenta una ventana de visualización 14 al usuario A en la pantalla de la terminal 2 para que este introduzca respuestas múltiples destinadas a ser presentadas al usuario B y que incluyen la respuesta esperada al desafío, es decir, a la pregunta P3. En el ejemplo previsto en la figura 6F, el usuario A introduce, a través del teclado virtual del terminal 2, tres respuestas posibles, a saber, UBI1 = "en el mar de arena", UBI2 = "en el desierto de Arizona", UBI3 = "en mi jardín". Asimismo indica cuál es la respuesta esperada al desafío, en este caso la respuesta UBI2.
En el modo de realización descrito en el presente documento, el usuario A también tiene la posibilidad, por medio de la interfaz gráfica IU, de fijar una duración máxima para suministrar la respuesta esperada al desafío. Esta duración puede ser introducida por el usuario con ayuda del teclado del terminal 2, o como se ilustra en la figura 6G, deslizando su dedo en un reloj representado en la ventana de visualización 15 prevista por la interfaz de usuario a tal efecto hasta alcanzar el tiempo deseado (por ejemplo, 15 minutos en el ejemplo ilustrado).
La determinación de esta duración máxima completa la producción del desafío y de la respuesta esperada a este desafío.
Cabe señalar que la respuesta esperada al desafío puede depender implícitamente de la naturaleza del desafío seleccionado por el usuario. De este modo, cuando el desafío es un rompecabezas, la respuesta esperada al desafío es la reconstrucción correcta del rompecabezas.
Las diferentes interacciones descritas entre el usuario A y la interfaz de usuario IU que participa en la definición de un desafío a presentar al usuario B y de una respuesta esperada a este desafío son traducidos por el módulo de definición de desafío de la aplicación APLI en metadatos META (etapa E115). Los metadatos META son, en el sentido de la invención, metadatos que definen, en relación con el contenido multimedia CONT seleccionado por el usuario A, el desafío y la respuesta esperada al desafío construidos por el usuario A través de la interfaz IU.
Estos metadatos META son datos alfanuméricos (es decir, texto) que describen explícitamente o de manera codificada el desafío y la respuesta esperada al desafío definidos por el usuario A través de la interfaz de usuario IU.
Más precisamente, estos definen en el presente documento, en concreto, el tipo (categoría) de desafío seleccionado por el usuario A, los parámetros de este desafío (por ejemplo, los elementos que constituyen el desafío, es decir la pregunta formulada, y la respuesta esperada al desafío), al menos una operación a ejecutar por el módulo de presentación de desafío dependiendo de si la respuesta suministrada por el destinatario es la respuesta esperada o no, la duración máxima para suministrar una respuesta al desafío, etc.
En el contexto de un desafío de tipo cuestionario (categoría C4) basándose en la restitución parcial del contenido multimedia, una información representativa de la naturaleza del contenido multimedia CONT también puede ser incluida en los metadatos con el fin de permitir que el módulo de presentación del desafío instalado en el terminal del usuario destinatario B (de la aplicación APLI en el presente documento) seleccione el módulo correcto de restitución de contenido multimedia con la lectura de los metadatos.
Estos metadatos se presentan en el presente documento en forma de una lista de identificadores o nombres de campos de información y un valor asociado a cada campo de información enumerado. Por ejemplo, se puede usar un código alfanumérico de uno o dos bytes para codificar cada campo de información y el valor asociado con ese campo de información. Estos campos de información son, por ejemplo:
- un campo de estado (por ejemplo, "status": "200"),
- un identificador de tipo de desafío (por ejemplo, "gameType": "2"), asociado a la categoría de desafío seleccionada por el usuario A,
- un identificador del usuario destinatario o de un terminal del usuario destinatario (por ejemplo, "contactPhoneNum": "33630350911"),
- una fecha de creación del juego ("creationDate": "2014-03-04 10:33:26"),
- un número de piezas de un rompecabezas cuando el usuario selecciona un desafío de tipo rompecabezas (por ejemplo, "pieceNum": "1") y/o la posición de las piezas de este rompecabezas (respuesta esperada al desafío), - una duración máxima para suministrar una respuesta al desafío, definida, por ejemplo, en segundos, (por ejemplo, "timer", "9"),
- un identificador de la respuesta esperada al desafío (por ejemplo, "idChoice": "0"),
- un identificador de tipo de medio, es decir, que indica la naturaleza del contenido multimedia seleccionado por el usuario, cuando el desafío es del tipo cuestionario (por ejemplo, "MediaType"),
- un texto a presentar durante la presentación del desafío (por ejemplo, pregunta formulada en el desafío), etc. En el modo de realización descrito en el presente documento, el módulo de definición del desafío y el módulo de presentación del desafío son implementados por la aplicación APLI, de modo que los metadatos utilizados por uno sean comprensibles e interpretables por el otro. De manera general, se garantiza que los metadatos utilizados para definir el desafío y la respuesta esperada al desafío sean de acuerdo con una lógica de codificación común al módulo de definición de desafío instalado en el terminal 2 del usuario A y al módulo de presentación de desafío instalado en el terminal 3 del usuario B.
Los metadatos META agrupan toda la información requerida para la presentación del desafío definido por el usuario A por el módulo de presentación de desafío de la aplicación APLI instalada, llegado el caso, en el terminal del usuario B.
En el modo de realización descrito en el presente documento, al final de la etapa de producción del desafío y de su respuesta, el módulo de definición de desafío de la aplicación APLI ofrece al usuario A, por medio de la interfaz de usuario IU, una visión general del desafío que acaba de ser producido y está destinado a ser presentado al usuario B. La figura 6H ilustra el desafío correspondiente a las elecciones del usuario representadas en las figuras 6A-6G, dicho de otro modo de una fotografía misteriosa (es decir, parcialmente enmascarada), cuyo acceso está condicionado por una pregunta de opción múltiple. Los elementos de enmascaramiento de la fotografía misteriosa se definen de manera aleatoria por un algoritmo predefinido implementado por el módulo de definición de desafío. El desafío así producido se presenta en una ventana de visualización 16 de la interfaz de usuario IU.
Si el usuario A está satisfecho, puede validar la producción del desafío presionando el botón OK 17.
Por supuesto, el ejemplo descrito en el presente documento y representado en las figuras 6A-6H se da sólo a título ilustrativo. No se adjunta ninguna limitación a los tipos de desafíos que puede utilizar el usuario A para acompañar el contenido multimedia que desea transmitir al usuario B, ni a los elementos de respuesta, ni siquiera al tipo de contenido multimedia. En cada etapa de la construcción (producción) del desafío por la aplicación APLI a través de sus interacciones con el usuario A, otros elementos (desafíos, respuestas, preguntas, etc.) de los previstos en este ejemplo puede ser propuestos al usuario A para construir su desafío por medio de la interfaz gráfica IU. También cabe señalar que los elementos propuestos al usuario A para producir el desafío destinado al usuario B pueden estar condicionados por diferentes parámetros y adaptarse por ejemplo al usuario A, y/o al destinatario B del mensaje, etc., como se detalla más adelante.
Al recibir la validación del usuario A, el módulo de definición de desafío de la aplicación APLI inserta los metadatos META que definen, en relación con los contenidos multimedia CONT, el desafío, la respuesta esperada al desafío, la duración máxima fijada para responder al desafío, y el nombre o cualquier otro identificador que permita identificar un terminal del destinatario B (por ejemplo, número de teléfono presente en la lista de contactos o introducido por el usuario A) en un mensaje M (etapa E116).
En el modo de realización descrito en el presente documento, el mensaje M es una solicitud HTTP de tipo POST destinada al servidor 4. El módulo de definición de desafío también inserta en este caso el contenido multimedia CONT seleccionado por el usuario A en el mensaje M si está almacenado en el terminal 2 para transmitirlo simultáneamente a los metadatos. Cabe señalar que el contenido multimedia se inserta, llegado el caso, en forma binaria en la solicitud POST.
Más generalmente, en el modo de realización descrito en el presente documento, el módulo de definición de desafío inserta datos de acceso al contenido multimedia CONT en el mensaje M (en este caso, por ejemplo, la URL seleccionada por el usuario A en la etapa E113). Por datos de acceso se entiende en el presente documento bien el propio contenido multimedia, o bien datos tales como, por ejemplo, una dirección y una URL que permiten acceder al contenido multimedia en una entidad local o remota.
En otro modo de realización, el mensaje M es una solicitud HTTP de tipo GET en la que se insertan los metadatos. El contenido multimedia o más generalmente los datos de acceso al contenido multimedia es (son) enviados, a su vez, al servidor 4 en una petición HTTP de tipo POST después del envío por el servidor de un identificador al terminal 2 que le permite asociar los metadatos al contenido multimedia transmitido por el terminal 2 y que el terminal 2 pase un parámetro de la solicitud HTTP POST en la que el contenido multimedia o los datos de acceso a este contenido es (son) enviados.
En otro modo de realización más, los metadatos y/o los datos de acceso al contenido multimedia pueden enviarse en mensajes de acuerdo con otros tipos de formato, como por ejemplo en un mensaje SMS o MMS, etc.
Esto cierra la etapa de construcción E110 del mensaje M por el módulo de definición de desafío de la aplicación APLI instalada en el terminal 2, realizada interactuando con el usuario A por medio de las páginas de la interfaz gráfica IU.
A continuación, la aplicación APLI envía el mensaje M al servidor 4, a través de la red de telecomunicaciones NW1, utilizando la dirección de contacto @oC4 configurada en la aplicación APLI (etapa E120).
El servidor 4 extrae del mensaje M el identificador (por ejemplo, nombre) del destinatario B. Verifica con ayuda de este identificador si el usuario B está registrado y se ha abonado al servicio S interrogando a la base de datos 5 (etapa E130).
Si el usuario B está registrado, esto significa que su terminal está equipado con un módulo de presentación de desafío emitido en el marco del servicio S (es decir, en el presente documento de la aplicación APLI). Se supone en el presente documento que el usuario B no está registrado en la base de datos 5, es decir, que no se ha abonado en el servidor 4 para el servicio S, y por lo tanto que no está equipado con un módulo de presentación de desafío emitido en el marco del servicio S (capaz de interpretar, en concreto, los metadatos contenidos en el mensaje M).
En este caso, el servidor 4 almacena en su memoria volátil 4D el mensaje M.
A continuación, determina a partir del nombre del destinatario B incluido en el mensaje M y de la lista de contactos del usuario A almacenada en la base de datos 5, el número de teléfono del usuario B en la red de telecomunicaciones móvil NW1. Luego envía al terminal 3, utilizando el número de teléfono determinado de este modo, un mensaje INVIT invitándolo a instalar la aplicación APLI, y a abonarse con ella al servicio S (etapa E140). Este mensaje INVIT es un mensaje de invitación a descargar la aplicación APLI desde un enlace (por ejemplo, una URL (Uniform Resource Locator)) especificado en el mensaje.
En el modo de realización descrito en el presente documento, el mensaje de invitación INVIT es enviado por el servidor 4 al terminal 3 a través de un servidor SMS 6, capaz de gestionar el envío y la recepción de mensajes SMS en la red de telecomunicaciones móvil NW1.
En una variante de realización, el número de teléfono del destinatario B del mensaje M es suministrado en el mensaje M por la aplicación APLI a partir de la lista de contactos almacenada en el terminal 2.
En otro modo de realización, el servidor 4 identifica los contactos del usuario A, que no están registrados en la base de datos 5 y no están abonados al servicio S (y por lo tanto que no están equipadas con la aplicación APLI) después de la transmisión en el transcurso de la etapa E80 de la lista de contactos del usuario A al servidor 4 por el terminal 2. Lo mismo se aplica al envío del mensaje de invitación a descargar la aplicación APLI a los contactos no registrados identificados de este modo.
Al recibir el mensaje de invitación INVIT, el usuario B descarga la aplicación APLI en una memoria de su terminal 3, a partir de la URL especificada en el mensaje INVIT (etapa E150). Una vez instalada, la aplicación APLI del terminal 3 envía un mensaje al servidor 4 para indicarle el éxito de la instalación y proceder a registrar al usuario B (etapa E160). Este registro se realiza como se describió anteriormente para el usuario A (véanse las etapas E10 a E100).
Al final de este registro, el servidor 4 ha guardado en la base de datos 5 el nombre del usuario B en asociación con su número de teléfono en la red NW1 y su lista de contactos (etapa E170).
Si el usuario B no instala la aplicación APLI en su terminal 3 tras la invitación del servidor 4, el servidor 4 borra el mensaje M al final de un tiempo de espera predeterminado desencadenado tras el envío del mensaje de invitación INVIT. Un mensaje puede ser enviado, además, a la terminal 2 del usuario A con el fin de advertir que el o los usuarios a los que deseaba dirigir el contenido multimedia no han ejecutado el desafío que acompaña a este contenido multimedia y no han tenido acceso a él (o incluso no han deseado unirse al servicio S o instalar la aplicación APLI). Tras el registro del usuario B en el servidor 4, el servidor 4 extrae del mensaje M el contenido multimedia CONT o, llegado el caso, los datos de acceso al contenido multimedia, le asigna un identificador único ID-CONT y almacena el contenido CONT en un directorio de su memoria no volátil (espacio de almacenamiento del servidor en el sentido de la invención) (etapa E180). Esta etapa de almacenamiento comprende opcionalmente la obtención (por ejemplo, descarga) del contenido CONT a partir de los datos de acceso especificados en el mensaje M.
Se supone que el contenido multimedia CONT es ahora accesible en este directorio a través de una dirección de tipo URL @CONT (segundos datos de acceso en el sentido de la invención).
El servidor 4 extrae, asimismo, los metadatos META contenidos en el mensaje M y los memoriza en asociación con el identificador único ID-CONT asignado al contenido multimedia CONT y el identificador IDB del usuario destinatario B, en una base de datos de su memoria no volátil (etapa E180).
A continuación, en el modo de realización descrito en el presente documento, envía al terminal 3 del usuario B una notificación que tiene como propósito informar al usuario B de que hay un desafío disponible para él en el servidor 4 (etapa E190).
Se supone en el presente documento que al recibir esta notificación, el usuario B decide acceder al desafío. La aplicación APLI instalada en el terminal 3 emite una solicitud a tal efecto destinada al servidor 4 (etapa E200).
Al recibir esta solicitud, el servidor 4 envía un mensaje M' al terminal 3, que comprende los metadatos META almacenados en su base de datos, complementados opcionalmente por otros metadatos (formando así metadatos META'), así como la dirección de @CONt que permite acceder al contenido multimedia CONT almacenado en el directorio del servidor. La dirección @CONT se puede insertar en los metadatos de META'.
En otro modo de realización, el mensaje M' comprende el contenido multimedia CONT.
El mensaje M' es en el presente documento una solicitud de acuerdo con el formato JSON (JavaScript Object Notation), que, de forma conocida de por sí, es un formato genérico de datos textuales derivado de la notación de objetos del lenguaje JavaScript.
Como variante, por supuesto, se pueden prever otros formatos de mensaje.
El servidor envía entonces el mensaje M', a través de la red NW1, al terminal 3 (etapa E210).
Al recibir el mensaje M', la aplicación APLI del terminal 3 extrae los metadatos META' incluidos en el mensaje M' y descarga el contenido multimedia CONT a partir de la dirección URL @CONT especificada en estos metadatos META' (etapas E220/E230).
El contenido multimedia CONT es almacenado por la aplicación APLI en la memoria no volátil del terminal 3.
A continuación, el módulo de presentación de desafío de la aplicación APLI analiza e interpreta los metadatos de META' contenidos en el mensaje M' para presentar (es decir, para ejecutar) el desafío definido por el usuario A al usuario B en su terminal 3.
Más específicamente, durante la presentación del desafío, el módulo de presentación de desafío presenta una sucesión de páginas de interfaz de usuario (es decir, de la interfaz IU de la aplicación APLI en el ejemplo previsto en el presente documento).
El diseño de una de estas páginas de interfaz de usuario utilizadas para la presentación del desafío está predefinido, preferentemente, a partir de un modelo de interfaz de usuario o plantilla (en inglés "template"). La disposición y el tamaño de los elementos (por ejemplo, texto que compone el desafío propiamente dicho, contenido multimedia truncado o enmascarado, etc.) que aparecen en cada página, así como la sucesión de las diferentes páginas están predefinidas para un tipo de desafío dado, de modo que sólo el elemento que debe presentarse en la ubicación elegida en una página para ese elemento debe especificarse de modo que el módulo de presentación del desafío pueda presentar el desafío al usuario B de una forma comprensible y utilizable. Este elemento se identifica según una codificación común a la codificación utilizada en los metadatos META que definen el desafío. Dicho de otro modo, cada elemento que debe presentarse en cada página de interfaz de usuario durante la presentación del desafío es extraído por el módulo de presentación de desafío de los metadatos META.
Al recibir los metadatos META', la o las plantillas de página de interfaz de usuario asociadas al tipo de juego identificado en estos metadatos son, por lo tanto, utilizadas por el módulo de presentación de desafío de la aplicación APLI, y modificadas a partir de los metadatos META' para generar una o varias páginas de interfaz de usuario para presentar al usuario B el desafío al que debe responder en su terminal 3 (etapa e240).
La figura 6H ilustra un ejemplo de una página de interfaz de usuario que puede ser presentada por el módulo de presentación del desafío de la aplicación APLI al usuario B durante la presentación del desafío, a través de la interfaz gráfica IU.
El desafío está constituido, en este caso, por una fotografía enmascarada a la que está asociada la pregunta P2 y tres posibles respuestas UBI1, UBI2 y UBI3, siendo la respuesta esperada definida en los metadatos META' la respuesta UBI2. La fotografía enmascarada es generada por el módulo de presentación de desafío a partir del contenido multimedia CONT aplicando el mismo algoritmo de enmascaramiento que el implementado por el módulo de definición de desafío.
Si el usuario B no suministra una respuesta a este desafío a través de su terminal de 3 o suministra una respuesta distinta de la respuesta esperada contenida en los metadatos META', el módulo de presentación de desafío de la aplicación APLI se niega a restituir el contenido multimedia CONT en su totalidad al usuario B (es decir, visualizarlo) y borra el contenido multimedia CONT almacenado en la memoria no volátil del terminal 3. Además, puede visualizar una página de interfaz de usuario que le indica al usuario B que no suministró una respuesta correcta al desafío del usuario A.
Por el contrario, si el usuario B suministra a través de su terminal 3 la respuesta esperada al desafío (UBI2 en el presente documento), el módulo de presentación de desafío de la aplicación APLI restituye en la pantalla de su terminal de 3, en una página de interfaz de usuario, el contenido multimedia CONT seleccionado por el usuario A (etapa E250), como se ilustra, por ejemplo, en la figura 6I.
En el modo de realización descrito en el presente documento, el módulo de presentación de desafío de la aplicación APLI instalado en el terminal 3 está configurado para notificar, en un mensaje enviado al servidor 4, el fracaso o por el contrario el éxito del usuario B en suministrar la respuesta esperada al desafío (etapa E260).
En una variante de realización, dependiendo del desafío enviado al usuario B por el usuario A, el mensaje también puede contener una puntuación obtenida por el usuario B cuando suministró su respuesta al desafío.
Al recibir el mensaje de informe del terminal 3, el servidor 4 actualiza una puntuación asignada al usuario B y memorizada en la base de datos 5. Esta puntuación se actualiza en este caso cada vez que se envía un desafío al usuario B (etapa E270). Por ejemplo, se incrementa cada vez que el usuario B responde con éxito al desafío propuesto por el usuario A. Esta puntuación permite, en el modo de realización descrito en el presente documento, establecer una clasificación entre los usuarios registrados en el servidor 4 y que se hayan abonado al servicio S, o como variante, entre los usuarios presentes en la lista de contactos del usuario A.
Esta clasificación es enviada al usuario B por el servidor 4 en su terminal 3 (etapa E280). Cabe señalar que la clasificación o la puntuación actual del usuario B mantenida por el servidor 4 puede transmitirse adicionalmente en los metadatos META' cuando el servidor 4 tiene un nuevo desafío para el usuario B.
Como variante o adicionalmente, también se puede enviar al usuario A en su terminal 2.
En una variante de realización, si un fracaso del usuario B en suministrar la respuesta esperada al desafío es señalado por el terminal 3 al servidor 4, este último puede desbloquear, con el consentimiento del usuario A, la restitución del contenido multimedia CONT al usuario B en su terminal 3.
En otra variante de realización, dicho desbloqueo viene seguido de una disminución de la puntuación del usuario B mantenida por el servidor 4.
En otra variante de realización más, también se mantiene una puntuación a nivel del servidor 4 para el usuario A como productor de desafíos: cada desafío producido por el usuario A da como resultado un aumento en su puntuación. En el modo de realización descrito en el presente documento, en función de la puntuación obtenida por el usuario B (bien en un desafío particular, o bien en todos los desafíos en los que participó o una selección predeterminada de estos desafíos), el servidor 4 envía además un mensaje a la aplicación APLI instalada en el terminal 2 para que se realice una actualización del catálogo de elementos propuestos al usuario A para producir los desafíos destinados al usuario B (etapa E290). Esta actualización (etapa E300) puede comprender, por ejemplo, el desbloqueo de nuevos elementos (por ejemplo, nuevos desafíos o categorías de desafíos, o elementos que permitan hacer más complejos los desafíos ofrecidos al usuario B, etc.). El catálogo de elementos propuestos al usuario A se adapta así ventajosamente al usuario B. Una adaptación similar se realiza en el terminal 3.
Se señalará que el servicio S de intercambio de mensajes "lúdicos" que se acaba de describir se puede utilizar de forma independiente o estar integrado en otro servicio, tal como por ejemplo un paquete de comunicación, tal como RCS o "Joyn ®" o incluso una red social en línea tal como "Facebook ®". En este caso, la interfaz gráfica de usuario del módulo de definición de desafío y del módulo de presentación desafío implementados por la aplicación APLI también puede estar integrada en la interfaz gráfica del paquete de comunicación enriquecida o de la red social en línea y los mensajes M, INVIT y M' intercambiado entre las diferentes entidades del sistema 1 puede intercambiarse según un formato de mensaje aceptado por el paquete de comunicación enriquecida o por la red social en línea.

Claims (15)

REIVINDICACIONES
1. Procedimiento de recepción por un terminal (3) de un mensaje (M') proveniente de un servidor (4), a través de una red de telecomunicaciones, comprendiendo este mensaje metadatos (META) que definen, en relación con al menos un contenido multimedia un desafío a presentar, a un usuario (B) del terminal (3), una respuesta esperada a este desafío, y datos de acceso (@CONT) a dicho al menos un contenido multimedia en dicho servidor, agrupando dichos metadatos la información requerida para la ejecución de dicho desafío en dicho terminal (3), comprendiendo el procedimiento de recepción:
- una etapa de descarga (E220, E230) de dicho al menos un contenido multimedia a partir de dichos datos de acceso; - una etapa de presentación del desafío (E240, E250) definido por los metadatos por un módulo de presentación de desafío instalado en el terminal (3), comprendiendo esta etapa de presentación:
o una etapa de presentación (E240) al usuario (B) del terminal (3) de al menos una página de interfaz de usuario con el desafío;
o una etapa de obtención de una respuesta del usuario (B) a este desafío;
o una etapa de verificación de una correspondencia entre la respuesta obtenida del usuario (B) y la respuesta esperada al desafío definida en los metadatos; y
o una etapa de restitución o no de dicho contenido multimedia en su totalidad dependiendo de si la respuesta obtenida del usuario (B) corresponde o no a la respuesta esperada al desafío.
2. Procedimiento de recepción según la reivindicación 1, caracterizado por que dicho desafío propone una restitución parcial de dicho contenido multimedia o una restitución de una versión transformada de dicho contenido multimedia, siendo suministrado dicho contenido multimedia en su totalidad al usuario destinatario en caso de resolución con éxito del desafío.
3. Procedimiento de recepción según la reivindicación 1 o 2 caracterizado por que dicho al menos un contenido multimedia es descargado del servidor (4) únicamente cuando el usuario (B) de dicho terminal (3) prevé ejecutar dicho desafío, previamente a esta ejecución.
4. Terminal (3) de un usuario llamado destinatario (B) que comprende:
- un módulo de recepción de un mensaje proveniente de un servidor, a través de una red de telecomunicaciones, comprendiendo dicho mensaje datos de acceso a al menos un contenido multimedia en el servidor y metadatos, definiendo dichos metadatos, en relación con dicho al menos un contenido multimedia, un desafío a presentar al usuario destinatario (B), una respuesta esperada a este desafío y datos de acceso (@CONT) a dicho al menos un contenido multimedia en dicho servidor, agrupando dichos metadatos la información requerida para la ejecución de este desafío en dicho terminal;
- un módulo de descarga de dicho al menos un contenido multimedia a partir de dichos datos de acceso;
- un módulo de presentación de desafío capaz de analizar e interpretar los metadatos para:
o presentar al usuario destinatario al menos una página de interfaz de usuario con el desafío;
◦ obtener una respuesta del usuario destinatario a este desafío;
o verificar una correspondencia entre la respuesta obtenida del usuario destinatario y la respuesta esperada al desafío definida en los metadatos; y
o restituir o no dicho contenido multimedia en su totalidad dependiendo de si la respuesta obtenida del usuario destinatario corresponde o no a la respuesta esperada al desafío.
5. Sistema (1) que comprende:
a/ un terminal (2) de un usuario (A) emisor de un mensaje que comprende:
- un módulo de selección de al menos un contenido multimedia y de al menos un usuario destinatario (B), siendo el contenido multimedia y el usuario destinatario (B) seleccionados a través de una interfaz de usuario del terminal (2); - un módulo de definición de desafío capaz de construir dicho mensaje, a partir de al menos una interacción con un usuario emisor (A), siendo el módulo de definición de desafío capaz:
o de producir metadatos que definen, en relación con dicho al menos un contenido multimedia, un desafío a presentar a dicho al menos un usuario destinatario (B) y una respuesta esperada a este desafío, agrupando dichos metadatos la información requerida para la ejecución de dicho desafío en al menos un terminal (3) de dicho al menos usuario destinatario (3), siendo dicho desafío y dicha respuesta esperada definidos por interacciones entre el usuario emisor (A) y una interfaz de usuario de su terminal (2); y
o de insertar en el mensaje los metadatos y un identificador que sirve para identificar dicho al menos un terminal (3) de dicho al menos un usuario destinatario (B);
- un módulo de envío del mensaje y de datos de acceso a dicho al menos un contenido multimedia a través de una red de telecomunicaciones a un servidor (4) capaz de retransmitir los metadatos y dicho al menos un contenido multimedia a dicho al menos un terminal (3) de dicho al menos un usuario destinatario (B), siendo dicho al menos un terminal (3) de dicho usuario destinatario (B) de acuerdo con la reivindicación 4; y
b/ un servidor (4) que comprende:
- un módulo de recepción, capaz de recibir provenientes de dicho terminal (2) del usuario emisor (A), a través de la red de telecomunicaciones:
o dichos primeros datos de acceso a dicho al menos un contenido multimedia; y
o dicho mensaje;
- un módulo de almacenamiento capaz de almacenar dicho al menos un contenido multimedia en un espacio de almacenamiento del servidor (4); y
- un módulo de envío, a dicho al menos un terminal (3) de dicho usuario destinatario (B), de un mensaje que comprende los metadatos y segundos datos de acceso a dicho al menos un contenido multimedia almacenado en el servidor (4).
6. Procedimiento de construcción de un mensaje (M) por un terminal (2) de un usuario emisor (A), comprendiendo el procedimiento:
- una etapa de obtención (E112, E113) de una identificación de al menos un contenido multimedia (CONT) y de al menos un usuario destinatario (B), siendo el contenido multimedia y el usuario destinatario seleccionados a través de una interfaz de usuario del terminal (2);
- una etapa de construcción (E110) del mensaje por un módulo de definición de desafío (APLI) instalado en el terminal, a partir de al menos una interacción con un usuario emisor (A), comprendiendo esta etapa de construcción:
o una etapa de producción (E115) de metadatos (META) que definen, en relación con dicho al menos un contenido multimedia, un desafío a presentar a dicho al menos un usuario destinatario (B) y una respuesta esperada a este desafío, agrupando dichos metadatos la información requerida para la ejecución de dicho desafío en al menos un terminal (3) de dicho al menos usuario destinatario (B), siendo dicho desafío y dicha respuesta esperada definidos por interacciones entre el usuario emisor (A) y una interfaz de usuario de dicho terminal (2), implementando dicho al menos terminal (3) de dicho al menos usuario destinatario (B) un procedimiento de recepción según una cualquiera de las reivindicaciones 1 a 3; y
o una etapa de inserción (E116) en el mensaje de los metadatos y de un identificador (IDB) que sirve para identificar dicho al menos un terminal (3) de dicho al menos un usuario destinatario (B) del mensaje;
- una etapa de envío (E120) del mensaje (M) y de datos de acceso a dicho al menos un contenido multimedia (CONT) por el terminal, a través de una red de telecomunicaciones, a un servidor (4) capaz de retransmitir dichos metadatos y dicho al menos un contenido multimedia a al menos un dicho terminal (3) de dicho al menos un usuario destinatario.
7. Procedimiento de construcción según la reivindicación 6, en el que los metadatos comprenden:
- un tipo de desafío; y
- parámetros del desafío a presentar.
8. Procedimiento de construcción según la reivindicación 6 o 7, en el que los metadatos sirven para identificar al menos una operación a ejecutar tras la presentación del desafío por el terminal de dicho al menos un usuario destinatario dependiendo de si una respuesta suministrada por dicho al menos un usuario destinatario corresponde o no a dicha respuesta esperada.
9. Procedimiento de construcción según una cualquiera de las reivindicaciones 6 a 8 en el que los metadatos comprenden una duración máxima para suministrar una respuesta al desafío tras una presentación de dicho desafío a un llamado usuario destinatario.
10. Procedimiento de procesamiento de un mensaje implementado por un servidor (4), comprendiendo este procedimiento:
- una etapa de recepción (E120) provenientes de un terminal (2) de un usuario emisor (A), a través de una red de telecomunicaciones, de un mensaje (M) y de primeros datos de acceso a al menos un contenido multimedia (CONT), comprendiendo dicho mensaje un identificador (IDB) que sirve para identificar al menos un terminal (3) de al menos un usuario destinatario (B) y metadatos (META) que definen, en relación con dicho al menos un contenido multimedia un desafío a presentar a dicho al menos un usuario destinatario (B) y una respuesta esperada a este desafío, agrupando dichos metadatos la información requerida para la ejecución de dicho desafío en dicho al menos un terminal (3) de dicho al menos usuario destinatario (B), implementando dicho al menos un terminal (3) de dicho al menos un usuario destinatario (B) un procedimiento de recepción según una cualquiera de las reivindicaciones 1 a 3; - una etapa de almacenamiento (E180) de dicho al menos un contenido multimedia en un espacio de almacenamiento del servidor; y
- una etapa de envío (E210), a través de dicha red, a dicho al menos llamado terminal (3) de dicho al menos un usuario destinatario (B) de un mensaje que comprende los metadatos (META) y de segundos datos de acceso a dicho al menos un contenido multimedia almacenado en el servidor.
11. Procedimiento de procesamiento según la reivindicación 10, que comprende:
- una etapa de verificación (E130) de que el terminal (3) de dicho al menos un usuario destinatario (B) del mensaje está equipado con un módulo de presentación de desafío capaz de presentar el desafío definido por los metadatos a dicho al menos un usuario destinatario (B);
- si el terminal (3) de dicho al menos un usuario destinatario (B) no está equipado con el módulo de presentación de desafío, una etapa de envío (E140) de un mensaje (INVIT) que invita a este terminal a instalar este módulo de presentación de desafío (APLI);
siendo el mensaje que comprende los metadatos enviado a dicho al menos un terminal (3) cuando el módulo de presentación de desafío está instalado en éste.
12. Procedimiento de procesamiento según la reivindicación 10 u 11 que comprende, después de la etapa de envío de los metadatos, una etapa de recepción (E260) de un mensaje proveniente del terminal (3) de un llamado usuario destinatario (B) que informa de un fracaso o un éxito de dicho usuario destinatario (B) en suministrar la respuesta esperada al desafío durante la presentación de este desafío por dicho terminal.
13. Procedimiento de procesamiento según la reivindicación 12, que comprende una etapa (E270) de actualización de una puntuación asociada a dicho al menos un destinatario en función del fracaso o del éxito informado en el mensaje recibido del terminal del usuario destinatario.
14. Programa informático que consta de instrucciones para la ejecución de las etapas del procedimiento de construcción de un mensaje según una cualquiera de las reivindicaciones 6 a 9 o del procedimiento de procesamiento según una cualquiera de las reivindicaciones 10 a 13 o del procedimiento de recepción de un mensaje según una cualquiera de las reivindicaciones 1 a 3 cuando dicho programa es ejecutado por un ordenador.
15. Soporte de registro legible por un ordenador en el que está registrado un programa informático que comprende instrucciones para la ejecución de las etapas del procedimiento de construcción de un mensaje según una cualquiera de las reivindicaciones 6 a 9, o del procedimiento de procesamiento según una cualquiera de las reivindicaciones 10 a 13 o del procedimiento de recepción de un mensaje según una cualquiera de las reivindicaciones 1 a 3.
ES15160223T 2014-03-31 2015-03-23 Procedimiento de construcción de un mensaje por un terminal Active ES2881253T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1452846A FR3019424A1 (fr) 2014-03-31 2014-03-31 Procede de construction d'un message par un terminal

Publications (1)

Publication Number Publication Date
ES2881253T3 true ES2881253T3 (es) 2021-11-29

Family

ID=50933376

Family Applications (1)

Application Number Title Priority Date Filing Date
ES15160223T Active ES2881253T3 (es) 2014-03-31 2015-03-23 Procedimiento de construcción de un mensaje por un terminal

Country Status (4)

Country Link
US (1) US10447629B2 (es)
EP (1) EP2928124B1 (es)
ES (1) ES2881253T3 (es)
FR (1) FR3019424A1 (es)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103941982B (zh) * 2014-05-12 2016-08-24 腾讯科技（深圳）有限公司 一种分享界面处理的方法及终端
WO2016043530A1 (en) * 2014-09-18 2016-03-24 Samsung Electronics Co., Ltd. System and method for providing service via application
IN2015CH02514A (es) * 2015-05-19 2015-07-10 Wipro Ltd
JP6575547B2 (ja) * 2017-03-17 2019-09-18 富士ゼロックス株式会社 ドキュメント管理システム
US11604866B2 (en) * 2021-03-02 2023-03-14 At&T Intellectual Property I, L.P. Emotion-based authentication service

Family Cites Families (62)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2359640A (en) * 2000-02-23 2001-08-29 Battlemail Com Ltd A game using electronic mail
IL158337A0 (en) * 2001-04-25 2004-05-12 Celltick Technologies Ltd Mobile cellular telecommunications infrastructure based multi-user applications
US20040002382A1 (en) * 2002-06-27 2004-01-01 Inventec Appliances Corp. Method enabling mobile telephone game playing capability on wireless networks
US7320733B2 (en) * 2003-05-09 2008-01-22 Sukegawa Electric Co., Ltd. Electron bombardment heating apparatus and temperature controlling apparatus and control method thereof
US7089594B2 (en) * 2003-07-21 2006-08-08 July Systems, Inc. Application rights management in a mobile environment
US8549651B2 (en) * 2007-02-02 2013-10-01 Facebook, Inc. Determining a trust level in a social network environment
CA2676395C (en) * 2007-01-23 2015-09-15 Carnegie Mellon University Controlling access to computer systems and for annotating media files
US8495727B2 (en) * 2007-08-07 2013-07-23 Microsoft Corporation Spam reduction in real time communications by human interaction proof
US8510795B1 (en) * 2007-09-04 2013-08-13 Google Inc. Video-based CAPTCHA
US20090083826A1 (en) * 2007-09-21 2009-03-26 Microsoft Corporation Unsolicited communication management via mobile device
US20140304654A1 (en) * 2007-12-14 2014-10-09 The John Nicholas and Kristin Gross Trust U/A/D April 13, 2010 Wine Rating Tool, Simulator & Game For Portable Computing Device
US20090163272A1 (en) * 2007-12-21 2009-06-25 Microsoft Corporation Connected gaming
US7689700B2 (en) * 2008-01-08 2010-03-30 Microsoft Corporation Configuration of a peer group
US8239967B2 (en) * 2008-01-15 2012-08-07 Microsoft Corporation Simultaneous tamper-proofing and anti-piracy protection of software
US20090204819A1 (en) * 2008-02-07 2009-08-13 Microsoft Corporation Advertisement-based human interactive proof
US20090217368A1 (en) * 2008-02-27 2009-08-27 Novell, Inc. System and method for secure account reset utilizing information cards
US8315882B2 (en) * 2008-04-14 2012-11-20 International Business Machines Corporation Efficient, peer-to-peer CAPTCHA-based verification and demand management for online services
US8387122B2 (en) * 2008-05-16 2013-02-26 University Of Washington Access control by testing for shared knowledge
US8726355B2 (en) * 2008-06-24 2014-05-13 Gary Stephen Shuster Identity verification via selection of sensible output from recorded digital data
US8752141B2 (en) * 2008-06-27 2014-06-10 John Nicholas Methods for presenting and determining the efficacy of progressive pictorial and motion-based CAPTCHAs
US8499244B2 (en) * 2008-07-31 2013-07-30 Microsoft Corporation Automation-resistant, advertising-merged interactive services
US9641537B2 (en) * 2008-08-14 2017-05-02 Invention Science Fund I, Llc Conditionally releasing a communiqué determined to be affiliated with a particular source entity in response to detecting occurrence of one or more environmental aspects
US8561097B2 (en) * 2008-09-04 2013-10-15 Beezag Inc. Multimedia content viewing confirmation
US9028260B2 (en) * 2008-09-29 2015-05-12 Cisco Technology, Inc. Automated quiz generation system
US9498711B2 (en) * 2008-11-04 2016-11-22 Quado Media Inc. Multi-player, multi-screens, electronic gaming platform and system
US8196198B1 (en) * 2008-12-29 2012-06-05 Google Inc. Access using images
US8255987B2 (en) * 2009-01-15 2012-08-28 Microsoft Corporation Communication abuse prevention
US8925057B1 (en) * 2009-02-06 2014-12-30 New Jersey Institute Of Technology Automated tests to distinguish computers from humans
US8239465B2 (en) * 2009-02-19 2012-08-07 Microsoft Corporation Generating human interactive proofs
US8910251B2 (en) * 2009-03-06 2014-12-09 Facebook, Inc. Using social information for authenticating a user session
EP2433389B1 (en) * 2009-05-20 2018-05-02 Telefonaktiebolaget LM Ericsson (publ) Challenging a first terminal intending to communicate with a second terminal
US8315595B2 (en) * 2009-06-10 2012-11-20 International Business Machines Corporation Providing trusted communication
US8495518B2 (en) * 2009-11-09 2013-07-23 International Business Machines Corporation Contextual abnormality CAPTCHAs
US8707453B2 (en) * 2010-01-29 2014-04-22 Christopher Liam Ivey System and method for restricting access to a computer system to live persons by means of semantic association of images
US9682324B2 (en) * 2010-05-12 2017-06-20 Activision Publishing, Inc. System and method for enabling players to participate in asynchronous, competitive challenges
US8745729B2 (en) * 2010-06-22 2014-06-03 Microsoft Corporation Preventing abuse of services through infrastructure incompatibility
US8984292B2 (en) * 2010-06-24 2015-03-17 Microsoft Corporation Keyed human interactive proof players
US8402548B1 (en) * 2010-09-03 2013-03-19 Facebook, Inc. Providing user confidence information to third-party systems
US8839357B2 (en) * 2010-12-22 2014-09-16 Canon U.S.A., Inc. Method, system, and computer-readable storage medium for authenticating a computing device
US8776173B2 (en) * 2011-03-24 2014-07-08 AYAH, Inc. Method for generating a human likeness score
US9146917B2 (en) * 2011-07-15 2015-09-29 International Business Machines Corporation Validating that a user is human
US10558789B2 (en) * 2011-08-05 2020-02-11 [24]7.ai, Inc. Creating and implementing scalable and effective multimedia objects with human interaction proof (HIP) capabilities, with challenges comprising different levels of difficulty based on the degree on suspiciousness
US9621528B2 (en) * 2011-08-05 2017-04-11 24/7 Customer, Inc. Creating and implementing scalable and effective multimedia objects with human interaction proof (HIP) capabilities, with challenges comprising secret question and answer created by user, and advertisement corresponding to the secret question
US10452775B2 (en) * 2011-09-13 2019-10-22 Monk Akarshala Design Private Limited Learning application template management in a modular learning system
US20130160095A1 (en) * 2011-12-14 2013-06-20 Nokia Corporation Method and apparatus for presenting a challenge response input mechanism
KR101277204B1 (ko) * 2011-12-21 2013-07-22 엔에이치엔(주) 사용자 동작에 기반한 게임 도전 상대 검색 방법, 시스템 및 컴퓨터 판독 가능한 기록 매체
WO2013103019A1 (ja) * 2012-01-06 2013-07-11 Ｃａｐｙ インク キャプチャ提供方法及びプログラム
US20130217501A1 (en) * 2012-02-16 2013-08-22 Microsoft Corporation Presenting application challenges outside an application execution context
US9131374B1 (en) * 2012-02-24 2015-09-08 Emc Corporation Knowledge-based authentication for restricting access to mobile devices
US20130263230A1 (en) * 2012-03-30 2013-10-03 Anchorfree Inc. Method and system for statistical access control with data aggregation
US9258306B2 (en) * 2012-05-11 2016-02-09 Infosys Limited Methods for confirming user interaction in response to a request for a computer provided service and devices thereof
US8654329B2 (en) * 2012-06-19 2014-02-18 The United States Of America, As Represented By The Secretary Of The Navy Parallel multisensor optical particle sensors for flowing fluid systems
US20140012652A1 (en) * 2012-07-06 2014-01-09 Igt System and method for reducing loyalty point liability through gaming
WO2014014963A1 (en) * 2012-07-16 2014-01-23 Questionmine, LLC Apparatus and method for synchronizing interactive content with multimedia
US9390245B2 (en) * 2012-08-02 2016-07-12 Microsoft Technology Licensing, Llc Using the ability to speak as a human interactive proof
US8935769B2 (en) * 2012-09-28 2015-01-13 Liveensure, Inc. Method for mobile security via multi-factor context authentication
US8834277B2 (en) * 2012-12-27 2014-09-16 Sony Computer Entertainment America Llc Systems and methods for sharing cloud-executed mini-games, challenging friends and enabling crowd source rating
US10165066B2 (en) * 2013-03-15 2018-12-25 Facebook, Inc. Systems, methods, and apparatuses for implementing an interface to populate and update an entity graph through socially relevant user challenges
US9563763B1 (en) * 2013-05-21 2017-02-07 Amazon Technologies, Inc. Enhanced captchas
US9286767B2 (en) * 2013-08-09 2016-03-15 Zynga Inc. Challenging players in online game to compete in modular game
US20160048662A1 (en) * 2013-11-01 2016-02-18 Google Inc. Computerized CAPTCHA Systems Using A Direct Connection With User Computing Device
US9614837B2 (en) * 2014-08-27 2017-04-04 Verizon Patent And Licensing Inc. Systems and methods for verifying human interaction with a computer interface

Also Published As

Publication number Publication date
FR3019424A1 (fr) 2015-10-02
EP2928124A1 (fr) 2015-10-07
US10447629B2 (en) 2019-10-15
US20150281152A1 (en) 2015-10-01
EP2928124B1 (fr) 2021-04-28

Similar Documents

Publication Publication Date Title
ES2881253T3 (es) Procedimiento de construcción de un mensaje por un terminal
KR102205531B1 (ko) 소셜 네트워크 서비스의 사용자 관계정보에 기반한 지식 공유 서비스 제공 시스템 및 방법
US8271004B2 (en) User generated dynamic mobile service
TWI609342B (zh) 企業行動訊息系統與方法
ES2397478T3 (es) Métodos y sistemas para el intercambio de información a nivel de comunidades a través de terminales de comunicación individuales
US20090138546A1 (en) Device awareness; user profiling; profile storage, analysis and matching; and social interaction system for wireless mobile devices
US9137186B2 (en) Apparatus, method, and program for exchanging message or making voice call via network
US9269079B2 (en) Social network stealth and counter messaging
CN106255986A (zh) 增强通信标签
Pulver Hands-on internet of things with MQTT: build connected IoT devices with Arduino and MQ telemetry transport (MQTT)
CN112748974B (zh) 基于会话的信息展示方法、装置、设备及存储介质
US20160226810A1 (en) System and method of making messages remain on top of a mobile bulletin board
JP2020021216A (ja) メッセージ送信システム、メッセージ送信方法、メッセージ送信プログラム
US20160142361A1 (en) Image with audio conversation system and method utilizing social media communications
CN114779998A (zh) 基于图形标识的信息展示方法、装置、设备及存储介质
US12051128B2 (en) Method for negotiating a contract between two parties in a telecommunications network and devices implementing said method
ES2400642B1 (es) Método para proporcionar información de presencia social en redes de telecomunicación.
CN105933403A (zh) 一种基于亲情账号分享内容的方法和系统
WO2013121200A1 (en) Messaging system and method
CN105095454A (zh) 定向推送自定义二维码的方法与系统
de Tolly et al. Mobile phones: opening new channels for health communication
JP5960967B2 (ja) Ｓｎｓサーバ並びにその制御方法及び制御プログラム
US20170302781A1 (en) Electronic system for indirect intercommunication messaging between electronic terminals
US20120272233A1 (en) Automatic creating method of group application and couple application
KR20130057770A (ko) 게임 내 파티 생성 기능을 제공하는 게임 서버, 방법, 단말기 및 기록매체