ES2924833T3 - Procedimiento de procesamiento de datos de conexión de una plataforma de un sitio de Internet - Google Patents

Abstract

La presente invención se refiere a un método de procesamiento de datos relativos a la conexión a una plataforma (2) de un sitio de internet por un servidor (1) que comprende al menos una unidad de procesamiento de datos y medios de almacenamiento de datos, caracterizándose el método porque comprende etapas de : (a) identificación de una situación de un usuario conectado a dicha plataforma (2) a través de un equipo (3) de entre una lista de situaciones de referencia, estando asociada cada situación de referencia a al menos una estrategia, comprendiendo cada estrategia una o más motores situacionales elegidos entre una biblioteca de motores situacionales, pudiendo cada motor situacional implementar un procesamiento dado sobre una situación de un usuario para obtener un mensaje que tenga un efecto esperado sobre la situación; (b) para al menos una de las estrategias asociadas a dicha situación identificada, implementación por los medios de procesamiento de datos del servidor (1) de los motores situacionales de dicha estrategia sobre dicha situación para obtener al menos una pila de mensajes; (c) envío al equipo (3) de dicho usuario y/o de la plataforma (2) de un subconjunto de mensajes de dicha al menos una pila de mensajes. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Procedimiento de procesamiento de datos de conexión de una plataforma de un sitio de Internet

Campo técnico general

La presente invención se refiere al campo del análisis de datos de usuario para el comercio electrónico.

Más precisamente, se refiere a un procedimiento de procesamiento de datos de conexión a una plataforma de un sitio de Internet, estando el procedimiento dedicado en particular a los tratamientos estadísticos, a la minería de datos ("datamining" en la terminología anglosajona), al diseño de herramientas de ayuda a la decisión, a los diagnósticos, a la previsión o a la aproximación, al diseño de simuladores, de sistemas de aprendizaje automático o de ayuda al aprendizaje y de una manera general, al diseño de sistemas de análisis de situaciones o análisis situacional.

Estado de la técnica

El desarrollo de Internet ha provocado el auge del comercio en línea o "e-commerce". Se han propuesto así en las redes numerosos servicios que van desde la venta de productos hasta la puesta en relación de usuarios pasando por la banca o la prensa.

El comercio electrónico ha traído consigo la aparición del "e-business", es decir todo lo que se puede implementar por anticipado para concretizar una transacción y asegurar a continuación la fidelización de cliente, en particular el marketing electrónico.

En efecto, aunque la venta en línea permite teóricamente la personalización al máximo de la relación con el cliente, el anonimato que reina en Internet impide la aplicación de las reglas de marketing tradicionales, que se basan en el reconocimiento y la diferenciación de los clientes.

Comprender al internauta es por lo tanto esencial. Algunos actores del comercio electrónico proponen así a sus clientes rellenar unos perfiles que permiten identificarlos mejor, con el fin de ofrecerles un enfoque personalizado, como lo haría un vendedor en una tienda. Sin embargo, esta solución es limitativa para el internauta, que además es reticente a menudo a dar unas informaciones personales. La publicación US 2011/029665 A1 divulga un sistema que detecta cuándo un conjunto de los valores de datos representa una situación de referencia de entre unas situaciones de referencia.

Unas técnicas conocidas proponen la recogida de "datos comportamentales" del internauta, por ejemplo a través del contenido de su historial, con el fin de identificarlo mejor y personalizar los contenidos, en particular publicitarios, que recibe. Sin embargo, estas técnicas aportan únicamente una comprensión parcial del internauta y permiten deducir de ello únicamente poca información.

La presente invención propone un procedimiento de procesamiento de datos de conexión alternativo que utiliza lo que se denomina las "situaciones" de usuarios conectados a una plataforma de un sitio de Internet, situaciones que, una vez identificadas, se analizan para obtener unos datos y predecir otras situaciones, sin depender de un modelo o de una estructura de realización física o lógica.

Presentación de la invención

La presente invención propone un procedimiento de procesamiento de datos según la reivindicación 1.

Unas características opcionales están de acuerdo con las reivindicaciones 2 a 9.

Según un segundo aspecto, la invención se refiere a un servidor que comprende por lo menos una unidad de procesamiento de datos y unos medios de almacenamiento de datos, estando dicha por lo menos una unidad de procesamiento configurada para la implementación del procedimiento según el primer aspecto de la invención cuando tiene lugar la conexión de un usuario a una plataforma de un sitio de Internet a través de un equipo, estando el servidor en conexión con dicha plataforma.

Breve descripción de las figuras

Otras características y ventajas de la presente invención aparecerán con la lectura de la descripción siguiente de un modo de realización preferido. Esta descripción se dará con referencia a los dibujos adjuntos, en los que: - la figura 1 es un esquema de una arquitectura de red en la que se inscribe la invención;

- la figura 2 es un diagrama que representa esquemáticamente las etapas del procedimiento de procesamiento de datos de conexión según la invención;

- la figura 3 es un esquema de un modo de realización de un sistema de procesamiento de datos de conexión según la invención;

- la figura 4 representa un módulo de procesamiento de un sistema de procesamiento de datos de conexión según la invención;

- la figura 5 es un esquema de un módulo de procesamiento inmediato de un modo de realización de un sistema de procesamiento de datos de conexión según la invención;

- la figura 6 es un esquema de un módulo de procesamiento diferido de un modo de realización de un sistema de procesamiento de datos de conexión según la invención.

Descripción detallada de un modo de realización preferido

Situaciones

Contrariamente a todos los procedimientos de procesamiento conocidos, el procedimiento de procesamiento de datos según la invención se basa, como se ha mencionado anteriormente, en el análisis de "situaciones" completas, y no en una simple lista de parámetros.

En la continuación de la presente descripción, se describirá más particularmente la aplicación del procedimiento al campo mencionado anteriormente del comercio electrónico (en este caso dichos datos son unos datos de conexión a una plataforma de un sitio de Internet), pero se comprenderá que se puede extrapolar al procesamiento de datos de usuario de manera general en un puesto de trabajo. En efecto, los datos pueden ser los correos electrónicos del usuario, sus parámetros de sistema, etc. El procesamiento de datos de conexión da excelentes resultados en términos de identificación de situación gracias al volumen y a la diversidad de dichos datos.

En la presente memoria, se entiende por "situación" de un usuario, una información más o menos compleja y más o menos vaga que describe las nociones de orden psicológico, sociológico del usuario y su escena situacional (el conjunto de las situaciones de los otros usuarios conectados). Se puede denominar una situación mediante un término portador de significado para el comerciante electrónico, como por ejemplo "navegadora de la tarde" para designar unas mujeres que navegan por Internet después de comer sin ideas preconcebidas.

El análisis situacional abre así grandes perspectivas en numerosos campos económicos que utilizan unas herramientas de análisis, de predicción y de simulación. Unos procesadores de análisis situacional (véase por ejemplo la solicitud de patente francesa FR2962823) son capaces de manera autónoma de recibir a la entrada uno o más flujos situacionales, de extraer de ellos unas situaciones, de distinguir los elementos importantes y de aplicarles en continuo unos tratamientos, de detectar unos fenómenos y de prever unas evoluciones de soluciones, en particular por inducción.

Las ventajas son múltiples: como se verá, los sistemas situacionales no están limitados por unos modelos o unas arquitecturas de realización y, se adaptan por lo tanto permanentemente. Son capaces, a semejanza del cerebro humano, de concentrarse en lo esencial gestionando sus recursos. Por último, sus posibilidades parecen mucho más universales que las de cualquier sistema experto actual, compartimentado en un dominio particular.

El principio del procedimiento de procesamiento de datos (siendo el procesamiento realizado por un servidor que comprende por lo menos una unidad de procesamiento de datos y unos medios de almacenamiento de datos, estando el servidor, en el caso del procesamiento de datos de conexión a una plataforma de un sitio de Internet, en conexión de red con dicha plataforma) según la invención es identificar así mediante un primer mecanismo la situación de uno o varios usuarios, y después procesar mediante un segundo mecanismo las situaciones recogidas en un segundo tiempo. Los usuarios en cuestión son, en el caso del comercio electrónico, unos usuarios conectados a dicha plataforma a través de un equipo, incluso todos los internautas visitantes si los recursos del servidor lo permiten (véase a continuación).

Este tratamiento puede tener varios destinatarios y numerosas finalidades, como se explicará asimismo a continuación.

La figura 1 representa la arquitectura de red en la que se inscribe la invención. Un equipo 3 (se comprenderá que puede tratarse de cualquier tipo de equipo informático en el que un usuario puede acceder a Internet, desde el puesto de trabajo hasta el terminal móvil tal como un teléfono inteligente o una tableta táctil) está conectado a la plataforma 2 de un sitio de Internet a través de la red de internet 4. El servidor 1 que comprende por lo menos una unidad de procesamiento de datos y unos medios de almacenamiento de datos para la implementación del procedimiento está en conexión de red con dicha plataforma 2.

Es importante comprender que el término "plataforma" designa uno o varios servidores interconectados del sitio de Internet en los que están alojadas la o las páginas del sitio de Internet que el usuario está consultando. El servidor 1 que realiza el procesamiento puede ser uno de estos servidores que componen la plataforma 2. El equipo de usuario 3 está en cualquier caso conectado directa o indirectamente (mediante la plataforma 2) a través de la red Internet al servidor 1 que implementa el procedimiento. Se debe observar que la conexión entre el servidor de procesamiento 1 y la plataforma 2 puede ser local, pero alternativamente nada impide que pase de nuevo por la red de internet 4.

Primer mecanismo: identificación de una situación

Como se muestra en la figura 2, la identificación de la situación de un usuario conectado a dicha plataforma se realiza de entre un listado de situaciones de referencia, que pueden estar o bien predefinidas a partir de la observación de los comportamientos de los internautas, o bien generadas de manera particularmente ventajosa automáticamente por otro mecanismo que se describirá a continuación.

Para ello, el mecanismo de identificación de situación del procedimiento según la invención utiliza unos "activadores". Los activadores, más conocidos bajo la denominación anglosajona "triggers", son unos módulos de programa que son aptos para activarse y provocar un tratamiento particular en función de eventos predefinidos.

Los triggers pueden ser de numerosos tipos. En un primer tipo, el evento es una acción del internauta como un clic de consulta, un clic de selección, etc. En un segundo tipo, el evento es la expiración de un plazo, por ejemplo tras la última visita del internauta, o con respecto a la activación precedente del trigger (en este último caso se activa con una frecuencia fija, por ejemplo cada hora). Se comprenderá que son posibles numerosas configuraciones diferentes.

Con la activación de un trigger determinado, los medios de procesamiento de datos del servidor 1 activan un intento de determinación del estado de por lo menos un "indicio". Los indicios son diversos elementos portadores de significado para una situación. Algunos indicios se refieren al "escenario situacional", es decir el conjunto o un subconjunto de las situaciones de los internautas conectados que se desarrollan simultáneamente. Se trata por ejemplo de la hora, del clima, etc. Alternativamente, algunos indicios se refieren a la "esfera situacional", es decir la situación particular del internauta. Se trata entonces por ejemplo de la edad, del género, la talla del internauta, su navegación (rápida, vacilante, etc.), su estado (apurado, buscando, etc.). Los indicios se refieren por lo tanto a unos datos personales de dicho usuario conectado a la plataforma 2 y/o se refieren a unos datos generales. La combinación de estas dos "zonas" situacionales ofrece en la práctica buenos resultados para la determinación fiable de la situación de un usuario.

Naturalmente, algunos indicios relativos a unos resultados esperados (por ejemplo, la conclusión o no de una transacción) están implicados especialmente, en particular con vistas al análisis de las situaciones.

La o las unidades de procesamiento del servidor 1 disponen así de una colección de indicios observables predeterminada. Se debe apreciar que observable no significa necesariamente determinable. Un intento de determinación del estado de un indicio puede no ser fructuoso. Por ejemplo, la edad del internauta no es accesible necesariamente. El indicio se considera entonces como "indistinguible". Sin embargo, no se excluye que un intento posterior (a través del mismo trigger u otro) tenga éxito esta vez.

Una lista de los indicios para intentar la determinación está asociada a cada trigger. Si este trigger está activado, serán estos indicios y solamente estos indicios cuyo estado será observado. A título de ejemplo, un trigger periódico podrá intentar determinar el clima o el número de clics por segundo del usuario. Alternativamente, un trigger vinculado al clic en el botón "enviar" al final de un formulario podrá intentar determinar la edad y el sexo del usuario en función del texto introducido.

En función de los resultados de dicho intento de determinación del estado de por lo menos un indicio, la o las unidades de procesamiento generan y almacenan en los medios de almacenamiento del servidor 1 una firma situacional del usuario (si ya existe una situación situacional, esta solo se actualiza).

La firma situacional de un usuario corresponde al conjunto de los datos relativos a los indicios, que permiten caracterizar la situación del usuario.

Ventajosamente, una firma situacional está compuesta en particular por una pluralidad de unidades de información, estando cada una asociada a un indicio (ventajosamente se encuentran dos partes en una firma situacional, siendo las unidades denominadas respectivamente "thresholds" si el indicio asociado es relativo a la escena situacional , y "trackers" si el indicio asociado es relativo a la esfera situacional), pudiendo cada unidad de información tomar por lo menos tres valores incluyendo un primer valor si el estado determinado del indicio asociado corresponde a un estado de referencia (valor "1"), un segundo valor si el estado determinado del indicio asociado no corresponde al estado de referencia (valor "0"), y un tercer valor (valor "X") si el estado del indicio asociado no se ha podido determinar (ya sea porque no se ha realizado ningún intento de determinación para el indicio asociado, o porque el intento siguiente a la activación del trigger no ha tenido éxito). Cada unidad de información es entonces un "bit" con tres valores.

Se comprenderá que las anotaciones 0, 1 y X son puramente ilustrativas y que el experto en la materia podrá seleccionar la representación de datos de su elección. En particular, se puede considerar utilizar unas unidades de información que no tienen un número determinado de valores y aptas para almacenar por ejemplo unos números, unas cadenas de caracteres, etc. Sin embargo, se observará más adelante el interés de tener unas unidades de información con n estados. Utilizando la anotación definida anteriormente, 1X10 01XX es un ejemplo de firma situacional de 8 unidades de información.

Se observa además que aunque en la presente memoria no se distinguen los casos "ningún intento de determinación"/"intento de determinación pero infructuoso" (mismo valor "X"), se puede tener en cuenta alternativamente la información según la cual se ha intentado una determinación. En efecto, aunque la información que constituye el estado del indicio no se ha podido obtener, el hecho de que el intento haya fracasado puede ser portador de información. Por ejemplo, esto puede significar que el usuario ha ocultado voluntariamente (incluso involuntariamente) unas partes de su perfil y que por lo tanto, puede ser alguien que busca aumentar su confidencialidad en Internet.

Se debe observar que determinados trackers o thresholds se pueden basar en unos integradores de ley de distribución, por ejemplo Gauss o de Poisson, con el fin de conferirles un carácter remanente. En otras palabras, los integradores "prevén" el estado que debe tener el indicio en función de las observaciones previas, lo cual evita a corto plazo la necesidad de activar de nuevo un intento de determinación cuando el anterior se ha realizado hace poco.

La firma situacional del usuario se compara entonces con una pluralidad de "máscaras". Cada máscara está asociada a una situación de referencia, y corresponde a un espacio de firmas situacionales. Para ello, cada máscara está constituida como una firma de una pluralidad de unidades de informaciones, que pueden tomar los valores 0, 1, X, pero también un cuarto valor (anotado "A") si la unidad de información puede ser cualquiera. En efecto, el estado de algunos indicios no es característico de ciertas situaciones.

Por ejemplo 10A0 AAX1 es una máscara con 8 unidades de información que agrupa las siguientes firmas: 1000 00X1, 1000 01X1, 1000 0XX1, 1000 10X1, 1000 11X1, 1000 1XX1, 1000 X0X1, 1000 X1X1, 1000 XXX1, 1010 00X1, 1010 01X1, 1000 0XX1,1010 10X1, 1010 11X1, 1010 1XX1, 1010 X0X1, 1010 X1X1, 1010 XXX1, 10X0 00X1, 10X001X1, 10X00XX1, 10X0 10X1, 10X0 11X1, 10X0 1XX1, 10X0 X0X1, 10X0 X1X1, 10X0 XXX1.

La comparación entre la firma y una máscara se realiza entonces fácilmente gracias a unas puertas lógicas (se compara cada unidad de la máscara que no tiene como valor "A" con la unidad correspondiente en la firma gracias a XOR, y se aplica AND en los resultados de estas comparaciones). Cuando una máscara corresponde, se identifica la situación de dicho usuario conectado a la plataforma 2 como la situación de referencia asociada a la por lo menos una máscara que contiene dicha firma situacional.

Se debe observar que una pluralidad de máscaras está almacenada ventajosamente en los medios de almacenamiento del servidor 1, y que no es imposible que algunas de las máscaras tengan unos alcances que coinciden, en otras palabras, que no haya unicidad de la máscara correspondiente a una situación determinada. Para resolver esta dificultad, las máscaras se prueban ventajosamente de forma iterativa según una rotación: si la prueba es positiva, se considera la situación de referencia asociada a la máscara, si no, se prueba la máscara siguiente. Cuando se activa un nuevo trigger, la misma máscara de situación se prueba de nuevo primero con el fin de mantener si es posible la estabilidad de la situación actual.

Al final de esta primera fase del procedimiento, se dispone por lo tanto de una situación identificada como la situación del usuario.

Segundo mecanismo: tratamiento de la situación

El segundo mecanismo del procedimiento según la invención consiste en un análisis de la situación identificada del usuario mediante unos medios físicos o lógicos de análisis situacional del servidor 1 de manera que se obtengan unos datos procesados, que serán portadores de significado para el usuario, un administrador del sitio de Internet, etc. Los medios de análisis situacional pueden consistir en una aplicación ejecutada por los medios de procesamiento de datos del servidor 1 (se puede prever un procesador multinúcleo cuyos núcleos están dedicados a este análisis situacional, véase a continuación).

Para ello, cada situación de referencia está asociada a por lo menos una "estrategia" (ventajosamente 1 a 3), es decir un conjunto compuesto por uno o varios motores situacionales (así como los eventuales parámetros de estos motores) y por contenidos de mensajes, es decir unos textos, unos contenidos gráficos (incluidas unas imágenes, unos videos, etc.), unos enlaces URL (Uniform Resource Locator), unos elementos de forma (formato, parámetros de fuente, etc.) y cualquier otro dato útil para la personalización de un mensaje. Por mensaje (denominado asimismo recomendación) se entiende cualquier forma de comunicación resultante del procesamiento de los datos de conexión y que tiene un efecto esperado en la situación.

De manera completamente convencional, puede tratarse de mensajes de notificación dirigidos al administrador del sitio (en forma de correos electrónicos por ejemplo), pero puede tratarse sobre todo de mensajes destinados al usuario cuya situación está en proceso de tratamiento. Por ejemplo, puede ser un anuncio que muestra la página de Internet que consulta, un correo electrónico, un SMS, etc.

El o los motores situacionales son unos elementos de programa seleccionados de entre una biblioteca de motores situacionales. Cada motor situacional es así apto para implementar un tratamiento determinado sobre una situación de un usuario (el motor tiene en cuenta los parámetros de toda la escena y la esfera situacionales: en efecto, si la firma situacional de un usuario es única, la situación identificada no lo es. Tener en cuenta las unidades de información, es decir los estados de los indicios observados, permite personalizar el procesamiento) de manera que se obtengan uno o varios mensajes que tienen un efecto esperado sobre la situación.

Un primer ejemplo de motor puede implementar una recomendación de uno o varios productos relacionados con los visitados (se orienta hacia las situaciones de la tienda). Un segundo ejemplo de motor puede implementar una recomendación de productos comprados por unos internautas en una situación similar a la situación identificada del usuario (se está a nivel personal). En un tercer ejemplo de motor, se puede simplemente recomendar unos productos de moda (detección de un alza de las ventas significativas, se está a nivel de la sociología de grupo).

Se debe observar que una misma estrategia puede estar asociada a varias situaciones y que cada estrategia puede depender de un nivel de "esencialidad", es decir, un criterio de prioridad que puede ser importante en caso de gran afluencia de usuarios.

Para por lo menos una de las estrategias asociadas con dicha situación identificada (se pueden analizar por orden de esencialidad), los medios de procesamiento del servidor 1 implementan los motores situacionales asociados de manera que se obtenga por lo menos una pila de mensajes. Ventajosamente, se generan por lo menos dos pilas de mensajes (ventajosamente tres), estando cada una asociada a un nivel de confidencialidad. Por nivel de confidencialidad se entiende el nivel de publicidad del mensaje. Por ejemplo, en una implementación del procedimiento con dos niveles de confidencialidad, el nivel 1 corresponde a unos mensajes personales, mientras que el nivel 2 corresponde a unos mensajes globales (por ejemplo, un anuncio en el sitio). Los tres ejemplos de motores descritos anteriormente corresponden a tres niveles de confidencialidades distintos: el primero presenta un nivel de confidencialidad "bajo", ya que está destinado a cualquier usuario; el segundo presenta un nivel de confidencialidad "elevado", ya que la recomendación es personal, y por lo tanto está destinada únicamente al usuario. El tercero corresponde a un nivel de confidencialidad "medio", ya que la exposición se realiza a nivel del grupo. Las tres recomendaciones producidas por estos tres motores se encontrarían por lo tanto en tres pilas diferentes.

Estas pilas de mensajes se despliegan entonces para "exponer" los mensajes, es decir, transmitirlos a su destinatario. Más precisamente, consiste en enviar (según el caso) con destino al equipo 3 de dicho usuario y/o a la plataforma 2 (cuando se trata de elementos de páginas) un subconjunto de los mensajes de dicha por lo menos una pila de mensajes.

Esto se puede realizar a través de una sencilla política LIFO (Last In First Out, último en entrar, primero en salir), pero ventajosamente se implementa una estrategia llamada de testigos. En esta estrategia, la página actual comprende unas zonas de exposición aptas para recibir un mensaje en un formato determinado y que presenta unos parámetros determinados. Las zonas, cuando están disponibles, emiten un testigo que comprende los diferentes parámetros de la zona. Un motor situacional recibe el testigo y constituye "bajo pedido" uno o varios mensajes en función de estos parámetros. Los mensajes que disponen del testigo se extraen entonces de la pila antes que los otros.

La exposición del o de los mensajes afecta a la situación (provocando por ejemplo una transacción si ha tenido el impacto previsto en el usuario), lo cual tiene unas probabilidades de activar nuevos triggers y provocar el cambio de la situación en la que se encuentra el usuario. El procedimiento se reinicia así y se observará el efecto de los mensajes en el próximo ciclo de análisis.

Optimización de las capacidades de procesamiento

La actividad de los internautas no es constante durante el día y, en particular en unos períodos pico, los medios de procesamiento de datos del servidor 1 pueden tener dificultades para hacer frente a la afluencia de información (en otras palabras, el volumen del flujo que debe procesarse).

Ventajosamente, el sistema tiene en cuenta estas variabilidades del tráfico y regula el procedimiento. En particular, el procedimiento moviliza ventajosamente los recursos necesarios para identificar las situaciones de todos los usuarios conectados (la primera parte del procedimiento consume menos recursos que la segunda), pero analiza únicamente una parte según las capacidades disponibles, clasificadas en particular en el nivel de "esencialidad" de las estrategias mencionadas anteriormente.

Para ello, se definen tres niveles graduales de actividad (denominados en la presente memoria "alfafloor", "betafloor' y "gammafloor"), pasando el funcionamiento a un modo degradado (se dejan caducar ciertas situaciones más allá de un umbral) o diferido (unas situaciones consideradas interesantes no son procesadas inmediatamente a causa de la saturación, pero lo serán más tarde cuando la actividad sea menor). La precisión del análisis de una situación puede variar asimismo según el nivel de actividad: si faltan los recursos, se va a lo esencial (modo esencialmente deductivo), y si no, se realiza un análisis preciso (modo esencialmente inductivo) para el que se tiene más reflejo. En el caso de una semisupervisión o sin supervisión (véase a continuación), en caso de recursos disponibles, se favorece el aprendizaje.

Los tres niveles anteriores se definen en función de los niveles de actividad típicos en el sitio en número de acciones por segundo.

El alphafloor corresponde a un nivel de actividad "elevado". Por ejemplo, en un sitio en el que se observan hasta 1000 conexiones simultáneas, suponiendo que un usuario produce un clic (o cualquier otra acción como una entrada) cada 10 segundos como media, el alphafloor está a 100 Hz.

El betafloor corresponde a un nivel de actividad "medio". Por ejemplo, si en el mismo sitio se observan 100000 conexiones por día y se constata que un internauta permanece 1 min 30 segundos como media, el betafloor está a 10,4 Hz.

El gammafloor corresponde a un nivel de actividad "bajo". Por ejemplo, si se observa en el sitio una relación de 1 a 100 entre el máximo y el mínimo de conexiones simultáneas en un día (es decir un mínimo de 10 conexiones simultáneas a 9 segundos por clic), el gammafloor está a 1,11 Hz.

En el caso contrario (más capacidades de procesamiento disponibles de las necesarias), el procedimiento puede utilizar unos "Shadows", es decir, mantener unas situaciones remanentes de antiguos usuarios, con el fin de aumentar la base de aprendizaje.

Modos sem¡supervisado y no supervisado

El procedimiento necesita un conjunto de situaciones de referencia para funcionar, pero este conjunto no es fijo y puede evolucionar. En particular, las estrategias comprenden unos motores situacionales configurados para emitir mensajes para señalar en particular con destino a un administrador del sitio la aparición de una nueva situación. El administrador puede decidir hacer de ella una nueva situación de referencia.

En un modo semisupervisado, el sistema sugiere al administrador nuevas situaciones de referencia (asociadas a una máscara predeterminada por el motor situacional), y este último puede validar o no dichas propuestas. Alternativamente, en un modo no supervisado (tal como el representado en la figura 2), el sistema es completamente automático e incluye por sí mismo las nuevas situaciones de referencia.

Se debe apreciar que la observación de la aparición de nuevas situaciones por "gemación". En otras palabras, lo que detectan los motores es la aparición de una subcategoría de una situación amplia (por ejemplo, si una parte no despreciable de las firmas situacionales correspondientes a una situación de referencia resultan presentar unos estados idénticos para unos indicios que estaban clasificados como "A", es decir no tenidos en cuenta en la máscara). Alternativamente, para una situación de referencia determinada, se puede intentar seleccionar las situaciones que han desembocado en una transacción, con el fin de detectar los mensajes eficaces.

Procesadores reflejos

Según un segundo aspecto, la invención se refiere a un sistema 1, en particular un servidor 1 que comprende por lo menos una unidad de procesamiento de datos y unos medios de almacenamiento de datos, estando dicha por lo menos una unidad de procesamiento configurada para la implementación del procedimiento según el primer aspecto cuando tiene lugar la conexión de un usuario a una plataforma 2 de un sitio a través de un equipo 3. Como se ha explicado, la mayoría de las veces el procedimiento es implementado por un servidor del sitio que es distinto de los servidores que componen la plataforma 2 (es decir, los servidores que alojan las páginas del sitio y gestionan el funcionamiento del sitio), estando el equipo 3 del usuario conectado entonces a dicho servidor para la implementación del procedimiento a través de la plataforma 2.

De manera particularmente preferida, el segundo aspecto de la invención se refiere a un sistema 1 de procesamiento de datos de conexión a una plataforma 2 de un sitio de Internet del que se muestra un modo de realización particularmente preferido en la figura 3. Este sistema comprende:

- por lo menos dos módulos independientes 21,22 de procesamiento de datos de conexión (módulos "SALI2" de los cuales SALIX y SALIC son dos versiones), estando los módulos de procesamiento 21, 22 distribuidos en por lo menos dos grupos complementarios, estando los módulos 21,22 de un grupo configurados para implementar un subconjunto de las operaciones necesarias para la ejecución de un procedimiento de procesamiento de los datos de conexión de un usuario a dicha plataforma 2 que comprenden la identificación de una situación del usuario, recibiendo los módulos de procesamiento 21 de cada grupo unos datos procedentes de los módulos de procesamiento 22 de otro grupo de manera que se complete la totalidad del procedimiento de procesamiento de datos de conexión;

- un módulo distribuidor 10 ("RENZO") que recibe dichos datos de conexión y los transmite a los módulos de procesamiento 21, 22;

- un módulo reconciliador 30 ("RENALDO") que recoge los datos procedentes de los módulos de procesamiento 21, 22 y suministra unos datos procesados de conexión a dicha plataforma 2.

Estos módulos 10, 21, 22, 30 se denominan procesadores reflejos, debido a su aptitud para procesar sin a priori los datos de entrada.

Por lo tanto, el principio es tener dos (incluso más) grupos de n módulos 21,22, efectuando los módulos 21, 22 de un grupo en paralelo la misma tarea, y siendo las tareas de cada uno de los grupos complementarias para realizar el procesamiento de los datos de conexión. Los diferentes módulos 21, 22 pueden ser o bien unos procesadores físicamente independientes (y conectados por un bus), disponiendo cada uno de sus medios de procesamiento y de su espacio de almacenamiento, o bien alternativamente unos bloques de programa implementados en un equipo determinado, compartiendo entonces los módulos unos mismos recursos de procesador (eventualmente multinúcleo) y un mismo espacio de almacenamiento. Se debe observar que el sistema 1 puede estar distribuido en varios servidores, incluso estar instalado en la nube en unas máquinas virtuales. Los módulos 21, 22 intercambian ventajosamente unos datos en forma de un flujo en un lenguaje de abstracción, por ejemplo XML (eXtensible Markup Language), JSON (JavaScript Object Notation), el protocolo SOAP (Simple Object Access Protocol), Silvia o también Mawerick.

Con referencia a la figura 4 se representa esquemáticamente un módulo de procesamiento 21,22 (indistintamente del grupo) de tipo SALI2. Como se puede apreciar, tiene ventajosamente 7 puertos de entrada/salida. En efecto, es deseable que los módulos 21,22 estén conectados a una biblioteca de motores situacionales ejecutables y/o a una base de datos que contiene una ontología característica de dicho sitio de Internet con el fin de poder implementar las etapas del procedimiento explicadas anteriormente.

En particular:

- el puerto OBS (observador) recibe los datos procedentes de la plataforma 2 en forma de flujo XML;

- el puerto COL (colector) recibe los datos procedentes de los otros módulos de procesamiento 21,22 SALI2 en forma de flujo XML;

- el puerto ONT (ontología) recibe la ontología en forma de archivo XML;

- el puerto LIB (biblioteca) contiene las bibliotecas de trackers, thresholds y motores situacionales (ejecutables);

- el puerto EDI (editor) emite los datos de salida en forma de flujo XML;

- el puerto DIF (difusor) emite los datos con destino a los módulos de procesamiento 21, 22 de otros grupos en forma de flujo XML;

- el puerto MON (monitorización) emite unas estadísticas.

La distribución de las tareas entre los grupos de módulos 21, 22 permite una eficacia mucho mejor de procesamiento por la especialización de los módulos 21, 22, y el hecho de que cada grupo esté alimentado con datos asegura, como se observa en la figura 3 un "feedback". Los resultados de una parte del procesamiento permiten mejorar la otra parte de procesamiento. Se describirán a continuación varias claves de distribuciones posibles entre los grupos de módulos de procesamiento 21, 22. Se debe observar que es posible combinar estos enfoques: el sistema 1 puede tener dos grupos de módulos 21,22 distribuidos según una primera ley, estando los módulos 21, 22 de un grupo distribuidos a su vez en dos subgrupos según una segunda ley.

El trabajo de clasificación es efectuado por el módulo repartidor 10. Este último interpreta cada paquete de información y lo dirige a los módulos de procesamiento 21, 22 adecuados.

El módulo reconciliador 30 recibe los flujos relativos a unos mensajes que deben enviarse en función de los procesamientos efectuados y se ocupa de la publicación de estos mensajes. Recompone un flujo global con destino a la plataforma 2 del sitio y/o al equipo 3 del usuario.

Según una primera variante, los módulos de tratamiento 21 de un grupo son unos módulos de procesamiento previo configurados para identificar las situaciones de usuarios conectados a dicha plataforma 2, y los módulos de tratamiento 22 de otro grupo son unos módulos de procesamiento posterior configurados para tratar unas situaciones identificadas de usuarios conectados. En esta configuración particularmente ventajosa, se tiene ventajosamente un módulo de procesamiento previo 21, y N módulos de procesamiento posterior 22 (en particular 4 u 8, pero se comprenderá que no se está limitado a este número y que se puede tener cualquier número de ellos), ya que el procesamiento de las situaciones obtenidas y el envío de mensajes es la parte más consumidora de recursos del procedimiento.

El enlace de feedback, que se puede apreciar en la figura 2, permite que el o los módulos de procesamiento previo 21 recojan datos procedentes del o de los módulos de procesamiento posterior 22 de manera que influyan en la identificación de las situaciones. Esto hace posible el modo no supervisado mencionado anteriormente.

Según una segunda variante, los módulos de procesamiento 21 de un grupo implementan las operaciones en tiempo real (los módulos de "procesamiento inmediato"), y los módulos 22 de otro grupo implementan las operaciones diferidas (módulos de "procesamiento diferido"). En otras palabras, algunos módulos 21 ejecutan unas tareas que necesitan una acción inmediata (por ejemplo, los activadores relacionados con la navegación de los usuarios, el envío de mensajes de exposición inmediata), mientras que los otros módulos 22 realizan unas tareas cuya ejecución se puede desplazar en el tiempo. Los datos son almacenados en los medios de almacenamiento hasta que puedan ser procesados. Esta configuración facilita la remanencia de las informaciones y tener en cuenta el pasado, en la medida en que en cualquier momento los módulos 21 de "tiempo real" reciben unos datos relativos a unos tratamientos realizados en diferido (que son por lo tanto el fruto de datos de conexión más antiguos). El bucle de feedback permite así que los módulos de procesamiento diferido 22 comuniquen a los módulos de procesamiento inmediato 21 unas "cuadrículas de procesamiento" a través de las cuales se adapta el procesamiento inmediato. Esta configuración se adapta además muy bien a los períodos de gran afluencia transfiriendo datos de procesamiento inmediato a procesamiento diferido.

Se trata del sistema representado en la figura 3: el "SALIX" es el módulo de procesamiento diferido 22, y los "SALIC" son los módulos de procesamiento inmediato 21. En esta configuración particularmente ventajosa, se tiene ventajosamente un módulo de procesamiento diferido 22, y N módulos de procesamiento inmediato 21 (el procesamiento inmediato tiene la prioridad, y es más consumidor ya que una cierta parte de los procesamientos no se puede realizar en diferido). En una configuración con 4 módulos de procesamiento inmediato 21, se tiene entonces en total 7 módulos 10, 21, 22, 30, siendo particularmente preferido por lo tanto un procesador de ocho núcleos (gestionando el octavo núcleo el resto de las operaciones del sistema).

Las figuras 5 y 6 representan con mayor detalle respectivamente un módulo de procesamiento inmediato 21 de tipo SALIC y un módulo de procesamiento diferido 22 de tipo SALIX. En estas figuras se observan los puertos OBS, COLL, EDI y DIF (los puertos ONT, LIB y MON están cableados de manera similar entre los dos tipos de módulo).

Un módulo de procesamiento inmediato 21 SALIC se ocupa de identificar todas las situaciones de los usuarios (que debe realizarse en tiempo inmediato) a través de los vectores de consulta, selección, consumo (que comprenden los datos observados para determinar los estados de los indicios) recibidos por el puerto observador.

El puerto difusor transmite los vectores al módulo de procesamiento diferido 22 SALIX. El puerto colector recibe los vectores de información procesada en diferido y las cuadrículas procedentes del módulo de procesamiento diferido 22 SALIX.

Los trackers (así como los thresholds) generan las firmas situacionales a partir de los vectores y de las cuadrículas. Se ejecutan los motores situacionales en tiempo real asociados a las estrategias de las situaciones identificadas, y los mensajes producidos por la ejecución de los motores son enviados a través del puerto editor.

Un módulo de procesamiento diferido 22 SALIX se ocupa por su parte, de los procesamientos que no necesitan ser realizados de inmediato. El puerto observador recibe exclusivamente unos datos relativos a los servicios y a los usuarios administradores. El puerto colector recibe los vectores procedentes de los módulos de procesamiento inmediato 21 SALIC. Unos motores situacionales se implementan bajo el control de un timer (temporizador) que define en qué momento se difiere el procesamiento.

Estos motores producen los mensajes diferidos (siendo los mensajes con destino a los usuarios enviados algunas horas tras su visita, por ejemplo en forma de un correo electrónico promocional que los incita a volver al sitio) y los mensajes para los administradores del sitio que son emitidos con destino a los soportes adecuados a través del puerto editor, así como las cuadrículas de procesamiento que, como se ha explicado, son reenviadas (con algunos vectores) hacia los módulos de procesamiento inmediato 21 SALIC a través del puerto difusor.

Según una tercera variante, cada grupo de módulos 21, 22 corresponde a una "línea de servicios". Se trata de una unidad de base de clasificación de productos dentro de un sitio de Internet dentro del sistema denominado "LSO" por Líneas/Servicios/Opciones. Una línea de servicios agrupa varios servicios. Por ejemplo, la categoría "Salón" que agrupará "Mesas", "Muebles de TV", "Sofás", etc. en un catálogo de muebles es una línea de servicios. Asimismo, la categoría "Hombre" o "Talla XL" es una línea de servicios de un catálogo de ropa. En un sitio de Internet tal como un sitio comercial, se observa que es posible presentar los mismos productos bajo varios modos de clasificación, se trata entonces de líneas de servicios diferentes. Cada servicio presenta unas opciones. En el ejemplo anterior, un servicio de "Pantalones" de una línea de "Hombre" contendrá una lista de opciones que son tantos modelos de pantalones. Cada opción presenta un producto con varias variantes (talla, colores, etc.); en efecto, cada producto es único (referencia de catálogo determinado), contrariamente a la opción. Por lo tanto, un mismo producto puede presentarse en varios contextos LSO. Volviendo al presente ejemplo, se pueden encontrar los mismos pantalones en el servicio "Pantalones de hombre" de la línea "XL".

Se puede prever así separar los módulos de procesamiento 21, 22 por línea de servicios, en particular para unos sitios que presentan unos productos muy diversos para los cuales las situaciones de los usuarios serán muy diferentes. Se debe observar que es habitual para sitios grandes que el usuario sea redirigido hacia uno u otro de los servidores de la plataforma 2 según la línea de servicios en la que navega.

Además, ventajosamente, se combinan varias de estas variantes. En particular, cada uno de los módulos de procesamiento inmediato 21 SALIC de la segunda variante puede estar dedicado a una o varias líneas de servicios. En este caso, el módulo distribuidor 10 RENZO distribuye el flujo entrante dirigiéndolo hacia el módulo de procesamiento diferido 22 SALIX si se trata de datos de administración o hacia un módulo de procesamiento inmediato 21 SALIC si se trata de datos de navegación de un usuario, en función de la línea de servicios en la que se encuentra.

Claims (10)

REIVINDICACIONES

1. Procedimiento de procesamiento de datos de conexión a una plataforma (2) de un sitio de Internet por un servidor (1) que comprende por lo menos una unidad de procesamiento de datos y unos medios de almacenamiento de datos, estando el procedimiento caracterizado por que comprende las etapas siguientes:

(a) observar un conjunto de indicios observables relativos a unos datos personales de un usuario conectado a la plataforma (2) y/o relativos a unos datos generales, e identificar a partir de dichos indicios una situación de dicho usuario conectado a dicha plataforma (2) a través de un equipo (3) de entre una lista de situaciones de referencia, estando cada situación de referencia asociada a por lo menos una estrategia, comprendiendo cada estrategia uno o varios motores situacionales seleccionados de entre una biblioteca de motores situacionales, siendo cada motor situacional apto para implementar un procesamiento determinado en una situación de un usuario de manera que se obtenga un mensaje que tiene un efecto esperado en la situación;

(b) para por lo menos una de las estrategias asociadas con dicha situación identificada, implementar por los medios de procesamiento de datos del servidor (1) los motores situacionales de dicha estrategia en dicha situación de manera que se obtenga por lo menos una pila de mensajes;

(c) enviar con destino al equipo (3) de dicho usuario y/o de la plataforma (2) un subconjunto de mensajes de dicha por lo menos una pila de mensajes;

en el que las estrategias comprenden unos motores situacionales configurados para emitir mensajes para señalar la aparición de una nueva situación correspondiente a una subcategoría de una situación existente, o bien con destino a un administrador del sitio para sugerirle una nueva situación de referencia que el administrador del sitio puede validar o no, o bien para incluir automáticamente la nueva situación de referencia.

2. Procedimiento según la reivindicación anterior, en el que cada estrategia está asociada a un nivel de esencialidad, dependiendo el orden de implementación de los motores asociados a las estrategias de los niveles de esencialidad de dichas estrategias.

3. Procedimiento según una de las reivindicaciones anteriores, en el que por lo menos dos pilas de mensajes se obtienen en la etapa (b), estando cada pila asociada a un nivel de confidencialidad.

4. Procedimiento según una de las reivindicaciones anteriores, en el que cada estrategia está asociada además a una lista de textos y/o de enlaces URL y/o de imágenes, estando los mensajes producidos por los motores de dicha estrategia construidos a partir de los textos y/o enlaces URL y/o imágenes de dicha lista de la estrategia.

5. Procedimiento según una de las reivindicaciones anteriores, en el que por lo menos una pila de mensajes es una pila "Último en entrar, primero en salir" (LIFO) de tamaño fijo, siendo los mensajes más antiguos reemplazados por los mensajes más recientes.

6. Procedimiento según una de las reivindicaciones 1 a 4, en el que por lo menos una pila de mensajes es una pila de tipo "de testigos", emitiendo la plataforma (2) un testigo con destino a la pila cuando se requiere un mensaje, siendo los mensajes que reciben un testigo reemplazados por los mensajes más recientes.

7. Procedimiento según una de las reivindicaciones 5 o 6, en el que unas páginas de dicho sitio de Internet comprenden por lo menos una zona de exposición apta para recibir un mensaje en un formato determinado y que presenta unos parámetros determinados, siendo un mensaje de una pila que presenta unos parámetros y un formato compatibles con dicha zona extraído de la pila y enviado con destino a la plataforma (2) cuando la zona de exposición está libre.

8. Procedimiento según una de las reivindicaciones anteriores, en el que la situación de un usuario se identifica en la etapa (a) por comparación de una firma situacional del usuario con una pluralidad de máscaras, estando cada máscara asociada a una de las situaciones de referencia y correspondiendo a un espacio de firmas situacionales, siendo la firma situacional de un usuario obtenida observando un conjunto de indicios observables relativos a unos datos personales de dicho usuario conectado a la plataforma (2) y/o relativos a unos datos generales.

9. Procedimiento según la reivindicación anterior, en el que algunos de los espacios de firmas situacionales correspondientes a las diferentes máscaras se modifican en función de algunos mensajes enviados en la etapa (c).

10. Servidor (1) que comprende por lo menos una unidad de procesamiento de datos y unos medios de almacenamiento de datos, estando dicha por lo menos una unidad de procesamiento configurada para la implementación del procedimiento según una de las reivindicaciones anteriores cuando tiene lugar la conexión de un usuario a una plataforma (2) de un sitio de Internet a través de un equipo (3), estando el servidor (1) en conexión con dicha plataforma (2).