ES2457040T3 - Sistema de cola, método y producto de programa de ordenador para gestionar la prestación de servicios a través de una red de comunicaciones - Google Patents

Abstract

Un método para gestionar peticiones de servicio a un anfitrión (22) de servicios a través de una red telefónica de comunicaciones, el cual método comprende los pasos de: recibir (502) desde un terminal (20) de cliente, a través de la red telefónica de comunicaciones, una petición de servicio a suministrar por el anfitrión 5 (22) de servicios; asignar (526) un identificador de cola a la petición de servicio; recibir (504) desde el terminal de cliente una posterior petición de servicio a suministrar por el anfitrión (22) de servicios; recuperar (530) el identificador de cola para la petición de servicio; realizar (528) una comparación entre el identificador de cola e información de estado de la cola; y traspasar (546) al anfitrión (22) de servicios la petición de servicio en función del resultado de la comparación, caracterizado porque los pasos del método se realizan en un servidor (30, 520) de cola y el paso de asignar (526) el identificador de cola a la petición de servicio se realiza con independencia de que la petición de servicio cumpla en ese momento los requisitos para ser atendida por el anfitrión (22) de servicios.

Description

Sistema de cola, método y producto de programa de ordenador para gestionar la prestación de servicios a través de una red de comunicaciones

Campo de la invención

La presente invención se refiere a la prestación de servicios a través de una red de comunicaciones que tiene ancho de banda limitado, debido a una limitación de la red o limitación de recursos del servidor.

Antecedentes de la invención

Cualquier servicio prestado a través de una red de comunicaciones tendrá un ancho de banda limitado, dando como resultado un número máximo de clientes que pueden ser servidos por minuto. El ancho de banda puede estar limitado por razones técnicas, tales como la velocidad del servicio de red abierta mundial ("world wide web" o simplemente "web", en inglés) o el número de líneas telefónicas entrantes, o bien puede estar limitado simplemente porque no hay suficientes operadores para gestionar la demanda de servicio.

Cuando la demanda es inferior a la máxima velocidad de servicio posible, los clientes pueden ser servidos inmediatamente. Sin embargo, cuando la demanda es mayor que la máxima velocidad de servicio posible, pueden surgir problemas a menos que se emplee un sistema de gestión del tráfico. En el comercio electrónico se produce frecuentemente una demanda excesiva cuando hay un interés muy alto en un producto particular, que puede estar disponible en cantidades limitadas cuando sale por primera vez a la venta. Un ejemplo típico es la venta de entradas para conciertos mediante un sistema de comercio electrónico. Todos los aficionados, sabiendo que las entradas son limitadas, intentarán utilizar el sistema tan pronto como se pongan en venta las entradas, creando un "pico" de demanda que puede situarse muy por encima de la velocidad máxima de transacción a la que el sistema puede hacer frente.

La presente invención está dirigida a proporcionar un sistema y método que se ocupe de este tipo de demandas excesivas de una manera que sea aceptable para los clientes y a la vez sea económicamente viable.

Una transacción de comercio electrónico es un proceso mediante el cual un cliente obtiene acceso a un producto o servicio a través del procesamiento de información de pago, consistente por lo general en detalles de una tarjeta de crédito. Un cliente que participa en una compra en línea sigue típicamente los pasos siguientes:

1.

El cliente navega por un sitio web, realizando peticiones y leyendo respuestas a través de programas informáticos ("software", en inglés) de navegación web. Las páginas del sitio web se transfieren normalmente desde el servidor web a la máquina cliente del cliente utilizando protocolo de transferencia de hipertexto no cifrado (HTTP, por sus siglas en inglés).

2.

Cuando ha tomado una decisión, el cliente solicita una página de pago, generalmente haciendo clic en un botón de "comprar", que contiene campos de formulario en los cuales puede introducir su información de tarjeta de crédito

o débito. Esta página de pago normalmente se transfiere por la red a través utilizando HTTP seguro (HTTPs).

3.

El cliente rellena sus datos, y éstos se envían utilizando HTTPs a una pasarela de pago. Con frecuencia, la transacción pendiente se almacena en una base de datos. La pasarela de pago reenvía los detalles de la transacción a una red de tarjetas de crédito dedicada, tal como VISA [RTM], para su tratamiento. Suponiendo que se autoriza la transacción, se almacena dicha transacción en la base de datos de la pasarela de pago. También se puede almacenar la transacción en bases de datos asociadas a la página de pago y al servidor web original.

4.

Se presenta al cliente una respuesta que indica indicación de que su transacción se ha realizado con éxito. Generalmente también se envía un correo electrónico confirmatorio al cliente.

En un momento posterior, se enviarán las mercancías el cliente y se deducirá de su tarjeta de crédito o cuenta bancaria el importe. Esto se conoce como la confirmación de la autorización obtenida en el paso 3, y por lo general se realiza mediante un proceso manual.

En algunas configuraciones, el sitio web, página de pago y la pasarela de pago residen todos ellos en máquinas diferentes. En otras configuraciones, el sitio web y la página de pago pueden residir en la misma máquina, mientras que la pasarela de pago se encuentra en una máquina diferente. Como alternativa, la página de pago y la pasarela de pago pueden residir en la misma máquina.

El número de usuarios que de manera simultánea pueden completar con éxito esta ruta está limitado por el ancho de banda del sistema, que a su vez está limitado por el ancho de banda del paso más intensivo en recursos. Por lo general, este es el paso 3, ya que este contiene múltiples anotaciones en bases de datos y siempre contiene al menos una conexión a una red de tarjetas de crédito externa.

Típicamente, la pasarela de pago será capaz de hacer frente satisfactoriamente a todas las transacciones solicitadas hasta una tasa óptima de transacciones por minuto. A medida de que la tasa solicitada aumenta por encima de ésta,

algunas transacciones fallarán, dando como resultado usuarios frustrados. Sin embargo, el número de transacciones correctas por minuto continuará aumentando hasta una tasa máxima. Más allá de esta tasa máxima de peticiones, el número de transacciones satisfactorias decrece, ya que el servidor tiene que gastar cada vez más recursos para denegar nuevas peticiones entrantes. Este comportamiento está ilustrado en la Figura 1. La tasa óptima se establece en 100 transacciones con éxito por minuto. Más allá de este punto, el número de transacciones con éxito por minuto es menor que el número de transacciones solicitadas por minuto. Sin embargo, el número de transacciones con éxito por minuto alcanza un máximo en aproximadamente 120 transacciones con éxito por minuto.

Con frecuencia, los volúmenes máximos de transacciones se expresan en términos de número de transacciones simultáneas. Este se puede calcular a partir de la tasa máxima de transacciones mediante la fórmula siguiente, siempre que también se conozca la duración media de cada transacción:

R = S * (60/T)

en donde R es el número máximo de transacciones por minuto, T es la duración de cada transacción en segundos (típicamente entre 6 y 8 segundos), y S es el número máximo de transacciones simultáneas. Nótese que este valor de R es un límite superior, ya que el cálculo supone que cada nueva transacción se produce inmediatamente después de que se haya completado una precedente. En la práctica esto es poco probable, y las tasas "óptimas" de transacciones son típicamente inferiores a un tercio de este valor.

Las pasarelas de pago pueden tener una tasa óptima de transacciones de aproximadamente 100 transacciones con éxito por minuto, aunque la mayoría de las pasarelas de pago son mucho menos eficientes que esto. La curva que se muestra en la Figura 1 se aplica también a cualquier servidor web, aunque el valor de la tasa óptima dependerá del número de anotaciones en bases de datos, de la complejidad y la longitud de la página servida y del protocolo de transmisión que se utilice. El protocolo HTTPs, al estar cifrado, requiere mucho más potencia de procesamiento para la misma tasa de pares petición/respuesta de página que, por ejemplo, el HTTP ordinario.

Cuando la tasa de transacciones solicitadas a la pasarela de pago aumenta por encima del nivel óptimo, los usuarios del sistema verán agotarse su tiempo de solicitud o bien recibirán una negativa. Un intento por parte del usuario de comprar el producto en venta provocará entonces que se vuelva a enviar la petición, al hacer clic de nuevo en el botón "enviar" o "comprar" del formulario, o bien al hacer clic en "recargar". Esto da lugar a que se envíe una petición adicional a la pasarela de pago, que también debe ser gestionada, e incrementa aún más la carga del servidor. Por ejemplo, haciendo referencia a la Figura 1, si 200 usuarios realizan peticiones en un minuto, en torno a 90 de ellos experimentarán transacciones fallidas. En el siguiente minuto, suponiendo que todos estos 90 usuarios repiten su petición, y otros 200 usuarios nuevos entran en el sistema, habrá 290 peticiones al servidor. Sólo alrededor de 50 de éstas conseguirán una transacción satisfactoria, dejando 440 peticiones para el siguiente minuto y así sucesivamente hasta que se produce un fallo catastrófico.

Además, a medida que falla la pasarela de pago, los usuarios pueden comenzar a atascar las etapas anteriores de la ruta de comercio electrónico, lo que origina páginas de pago (etapa 2) saturadas y eventualmente un servidor web (etapa 1) saturado. Este problema es particularmente importante si todas estas etapas residen en la misma máquina física.

Como se ha indicado antes, esta situación es particularmente grave cuando existe un interés muy alto en un producto determinado que está disponible en cantidades limitadas y sale a la venta en un momento determinado. Se forma un "pico" de peticiones de cliente que se sitúa muy por encima de la tasa máxima de transacciones a la que puede hacer frente el sistema. El fallo catastrófico se propaga entonces hacia atrás a lo largo del sistema. El fallo catastrófico continuará mientras los clientes sigan enviando peticiones, lo que para eventos populares puede durar muchas horas.

Esto crea una serie de problemas. En primer lugar, la experiencia de comprar un producto o servicio se prolonga y se hace muy frustrante, creando publicidad negativa para los proveedores del servicio. Los clientes se enojan porque malgastan su tiempo. En segundo lugar, los clientes perciben que la asignación de transacciones satisfactorias es aleatoria o bien se basa en los caprichos del componente físico ("hardware", en inglés) de la red, lo que lleva a una gran insatisfacción. En tercer lugar, la carga del servidor implica que los intentos de modificar las páginas para mejorar el sistema "sobre la marcha" pueden fracasar. Si se había previsto la carga elevada, se pueden posponer algunas comprobaciones (tales como la autorización de la tarjeta de crédito) hasta después de la "venta", con el fin de aumentar el rendimiento, lo que genera más trabajo e incertidumbre en cuanto al número de entradas realmente vendidas. La carga del servidor significa que se debe intentar aumentar la capacidad, con un coste adicional para el vendedor, y en última instancia para el cliente. También se debe contratar personal adicional para hacer frente a la afluencia de pedidos y estos empleados tendrán menos tiempo para tratar con clientes insatisfechos.

Una solución sencilla, aunque costosa, a algunos de estos problemas consiste en aumentar el ancho de banda de la parte más limitada de este sistema, generalmente la pasarela de pago, mediante la adición de servidores adicionales en paralelo. Esto se llama escalado. En la práctica, si la pasarela de pago es el cuello de botella del proceso, en general no es factible escalar hacia arriba su capacidad para satisfacer tasas de demanda arbitrarias. Esto se debe a dos razones. En primer lugar, habitualmente el ancho de banda de la red de tarjetas de crédito es limitado, y en

segundo lugar, el ancho de banda del sistema de base de datos que almacena las transacciones es limitado. El escalado de servidores de bases de datos es muy caro, y a menudo existen razones técnicas por las cuales no se puede aumentar por encima de dos el número de servidores de bases de datos.

Aunque el añadir servidores puede permitir en la práctica a un proveedor duplicar la tasa de transacciones, no se puede predecir con precisión el nivel real de demanda de un producto en particular, y no se reduce el riesgo de fallo catastrófico en el caso de ventas con muy alto interés. Todo lo que se consigue es un gasto mayor tanto en componente físico como en gastos de personal.

Por último, en el comercio electrónico real, los servidores fallan más frecuentemente por razones distintas del exceso de demanda. Los ejemplos incluyen cortes en la red o cortes de energía, fallos de componentes físicos, actualizaciones o reinicios del sistema y errores de los programas informáticos. También en estos casos los clientes se ven privados de obtener los productos y servicios ofertados, recibiendo con frecuencia un mensaje de error en lugar de la deseada transacción satisfactoria. A menos que el proveedor de servicios sea alertado del fallo y realice las reparaciones necesarias, se pueden perder estos clientes.

El documento US 2003/023734 A1 describe un método y aparato para regular el acceso a un recurso escaso, al cual se accede típicamente a través de un servidor web. Cuando se recibe una petición de acceso al recurso escaso, primeramente se determina si el nivel de acceso al recurso escaso está en un máximo. Si está al máximo, se pone al solicitante en una cola y se le notifica de esta circunstancia, quedando pendiente el solicitante de alcanzar el comienzo de la cola y de que el nivel de acceso caiga por debajo del máximo.

La presente invención proporciona una solución diferente a los problemas arriba descritos, y de una manera que es satisfactoria para los clientes y a la vez económicamente rentable para los vendedores.

Compendio de la invención

De acuerdo con un primer aspecto de la presente invención, según la reivindicación 1, un método para gestionar peticiones de servicio a un anfitrión ("host", en inglés) de servicios a través de una red telefónica de comunicaciones, comprende los pasos de:

recibir desde un terminal de cliente, a través de la red telefónica de comunicaciones, una petición de servicio a suministrar por el anfitrión de servicios;

asignar un identificador de cola a la petición de servicio;

recibir desde el terminal de cliente una posterior petición de servicio a suministrar por el anfitrión de servicios;

recuperar el identificador de cola para la petición de servicio;

realizar una comparación entre el identificador de cola e información de estado de la cola; y

traspasar al anfitrión de servicios la petición de servicio en función del resultado de la comparación,

en donde los pasos del método se realizan en un servidor de cola y el paso de asignar el identificador de cola a la petición de servicio se realiza con independencia de que la petición de servicio cumpla en ese momento los requisitos para ser atendida por el anfitrión de servicios.

De acuerdo con un segundo aspecto de la presente invención, según la reivindicación 9, un método para gestionar peticiones de servicio a un anfitrión de servicios a través de una red de comunicaciones por Internet comprende los pasos de:

recibir desde un terminal de cliente, a través de la red de comunicaciones por Internet, una petición de servicio a suministrar por el anfitrión de servicios;

asignar un identificador de cola a la petición de servicio;

proporcional al terminal de cliente acceso al identificador de cola;

recibir del terminal de cliente el identificador de cola como parte de una posterior petición de servicio a suministrar por el anfitrión de servicios;

realizar una comparación entre el identificador de cola e información de estado de la cola; y

traspasar al anfitrión de servicios la petición de servicio en función del resultado de la comparación,

en donde los pasos del método se realizan en un servidor de cola y el paso de asignar el identificador de cola a la petición de servicio se realiza con independencia de que la petición de servicio cumpla en ese momento los requisitos para ser atendida por el anfitrión de servicios.

De acuerdo con un tercer aspecto de la presente invención, según la reivindicación 38, un sistema para gestionar peticiones de servicio desde un terminal de cliente a un anfitrión de servicios a través de una red telefónica de comunicaciones comprende un servidor para recibir desde el terminal de cliente a través de la red telefónica de comunicaciones una petición de servicio a suministrar por el anfitrión de servicios, en donde el servidor incluye:

medios para recibir una petición de servicio desde el terminal de cliente;

medios para asignar un identificador de cola a la petición de servicio;

medios para generar información de estado de la cola;

medios para recuperar el identificador de cola después de una posterior petición de servicio desde el terminal

de cliente;

medios para realizar una comparación entre la información de estado de la cola y el identificador de cola; y

medios para traspasar la petición de servicio al anfitrión de servicios en función del resultado de la

comparación, en donde el servidor es un servidor de cola y los medios para asignar el identificador de cola a la petición de

servicio están adaptados para asignar el identificador de cola con independencia de que la petición de servicio cumpla en ese momento los requisitos para ser atendida por el anfitrión de servicios. De acuerdo con un cuarto aspecto de la presente invención, según la reivindicación 44, un sistema para gestionar

peticiones de servicio desde un terminal de cliente a un anfitrión de servicios a través de una red de comunicaciones por Internet comprende un servidor para recibir desde el terminal de cliente a través de la red de comunicaciones por Internet una petición de servicio a suministrar por el anfitrión de servicios, en donde el servidor incluye:

medios para recibir una petición de servicio desde el terminal de cliente;

medios para asignar un identificador de cola a la petición de servicio;

medios para proporcionar al terminal de cliente acceso al identificador de cola;

medios para generar información de estado de la cola;

medios para recibir el identificador de cola como parte de una posterior petición de servicio desde el terminal de

cliente;

medios para realizar una comparación entre la información de estado de la cola y el identificador de cola; y

medios para traspasar la petición de servicio al anfitrión de servicios en función del resultado de la

comparación, en donde el servidor es un servidor de cola y los medios para asignar el identificador de cola a la petición de

servicio están adaptados para asignar el identificador de cola con independencia de que la petición de servicio cumpla en ese momento los requisitos para ser atendida por el anfitrión de servicios. De acuerdo con un quinto aspecto de la presente invención, según la reivindicación 37, se proporciona un producto

de programa de ordenador que tiene código ejecutable por ordenador almacenado en el mismo para hacer que un ordenador ejecute el método del primer o segundo aspectos de la presente invención. En las reivindicaciones dependientes se exponen realizaciones preferidas de los diferentes aspectos de la invención.

Breve descripción de los dibujos

Se describirán ahora con detalle ejemplos de la presente invención haciendo referencia a los dibujos adjuntos, en los cuales:

la Figura 1 es una ilustración gráfica del comportamiento de un servidor típico;

la Figura 2 es una representación esquemática de un sistema típico de comercio electrónico de acuerdo con la técnica anterior;

la Figura 3 es una representación esquemática de un sistema de comercio electrónico de acuerdo con la presente invención;

la Figura 4 ilustra la relación entre los clientes en cola, los servidores de cola y un sistema de gestión de cola en un ejemplo de la presente invención;

la Figura 5 ilustra las etapas del flujo de clientes en el sistema de gestión de cola de acuerdo con la invención; y

la Figura 6 ilustra un ejemplo de una captura de pantalla de una Página de cola presentada al navegador del usuario de acuerdo con la presente invención.

5 Descripción detallada

La Figura 2 ilustra un sistema típico de comercio electrónico que carece de colas. El cliente dispone de un terminal 20 de cliente. Se ha dibujado tres veces el terminal de cliente para representar las tres fases por las que pasa el usuario durante una compra. La compra representada en la Figura 2 se compone de los pasos siguientes, indicados por las flechas (a) - (o).

10 a) El usuario realiza una petición HTTP (HyperText Transfer Protocol) a un servidor web 21.

b) El servidor web 21 responde con una respuesta HTTP que contiene una página HTML (Hyper Text Markup Language). La página se visualiza en la pantalla del usuario.

c) El usuario hace clic en enlaces para seleccionar otras páginas, u otros productos a comprar, lo que da como resultado más peticiones.

15 d) Esto se traduce en respuestas adicionales del servidor web 21 que contiene distintas páginas. Si un usuario hace clic en un enlace que indica que se ha seleccionado un producto, dicha información se almacena en el servidor (no dibujado).

e) Finalmente, el usuario debe hacer clic en un enlace que hace que el servidor responda ...

f) ... con una página que contiene con un botón de "Comprar" o de "Salir".

20 g) Cuando el usuario hace clic en ese botón, el navegador del usuario envía una petición a un servidor web seguro 22, generalmente protegido mediante el protocolo HTTPs (seguro). Se utiliza HTTPs para proteger información sensible tal como, por ejemplo, datos de la tarjeta de crédito. El HTTPs representa una penalización de carga tanto para la máquina cliente como para la máquina servidora debido a su cifrado, por lo que las transacciones HTTPs se representan en el diagrama con líneas gruesas.

25 h) El servidor web seguro 22 responde con una página que contiene elementos de formulario en blanco para que el usuario introduzca sus datos de pago, tales como un número de tarjeta de crédito.

i) Cuando el usuario ha rellenado el formulario y pulsa el botón "Enviar", la información es enviada de vuelta al sitio web seguro. En este punto, la solicitud pendiente puede ser guardada en una base de datos (no dibujada).

j) El sitio web seguro reenvía la información a una pasarela 23 de pago, de nuevo mediante HTTPs, y espera 30 una respuesta.

k) La pasarela de pago extrae el número de tarjeta de crédito, el importe y otros detalles consignados, y los envía a una red 24 de tarjetas de crédito para su tratamiento (esto se puede o no realizar mediante HTTPs).

I) La red de tarjetas de crédito responde, o bien con una negativa o bien con una autorización por el importe solicitado. Se asumirá que sucede esto último.

35 m) La pasarela anota el pedido en una base 25 de datos.

n) La pasarela de pago envía el resultado a la lógica 26 de espera del servidor web seguro. El servidor web seguro puede anotar este hecho en una base de datos.

o) La lógica 26 del servidor web seguro envía una respuesta HTTPs al usuario indicándole que el pedido ha sido aceptado satisfactoriamente. Esto va generalmente seguido también por un correo electrónico (que se envía por 40 separado).

Este ha sido sólo un ejemplo de una transacción de comercio electrónico. Existen muchas variantes. Por ejemplo, los pasos (i) y (j) pueden no pasar por el sitio web seguro, por lo que los resultados del formulario de pago serán enviados directamente a la pasarela de pago.

Los pasos (n) y (o) pueden no pasar por el sitio web seguro, por lo que los resultados de la pasarela de pago serán

45 enviados directamente al usuario final (esto es raro, y requiere comunicación adicional entre la pasarela de pago y otros sistemas para determinar que se ha emitido un pedido).

Una vez emitido el pedido (o) se pueden producir interacciones adicionales entre los diversos sistemas del servidor, entre ellas la transferencia de información de bases de datos.

El sitio web, el sitio web seguro y la pasarela de pago pueden residir todos ellos en máquinas separadas. También pueden residir en la misma máquina. Como otra opción, uno de ellos puede residir en una máquina física y los otros dos pueden residir en una máquina distinta. Con frecuencia, el sitio web y el sitio web seguro residen en la misma máquina, pero atienden a puertos TCP/IP diferentes. En la mayoría de los casos todavía se pueden considerar sistemas lógicamente separados.

El tipo de sistema que se describe en la Figura 2 no tiene ningún mecanismo para hacer frente de manera satisfactoria a una demanda que exceda de la capacidad del sistema. Un sistema de acuerdo con la presente invención incorpora un servidor 30 adicional entre un terminal de cliente y el servidor web seguro. El servidor 30 adicional es un servidor de cola que actúa como otro sistema lógico entre el sitio web y el sitio web seguro. En la Figura 3 se muestra un sistema ilustrativo de acuerdo con la presente invención.

La Figura 3 es la misma que la Figura 2 salvo en que el paso (g) de la Figura 2 ha sido reemplazado por pasos de gestión de cola (I)-(IV). El terminal 20 de usuario se dibuja cuatro veces para representar las cuatro fases de la transacción. El sistema incluye un servidor web 21, servidor web seguro 22, pasarela 23 de pago y red 24 de tarjetas de crédito, tal como se ha descrito en relación con la Figura 2. Los nuevos pasos de gestión de cola son los siguientes:

I) Cuando el usuario hace clic en el botón "Comprar" o "Salir", en lugar de realizar una petición al sitio web seguro como antes, el navegador del usuario hace una petición a la lógica 31 de un Servidor de cola.

II) Si la lógica 31 determina que el usuario debe ser puesto en cola, el servidor responde con una página de cola, que contiene un número de petición. El número de petición se almacena en la máquina del usuario.

III) La página de cola contiene código que se ejecuta en la máquina del cliente y que determina cuándo es probable que la petición del usuario pueda ser atendida. Esta página contiene también código que actualiza automáticamente la página con otra petición HTTP (III) en dicho momento, o bien cada pocos minutos, lo que ocurra antes.

IV) Si la lógica 31 del Servidor de cola determina que el usuario está el primero de la cola, se envía la petición de actualización del usuario al Sitio web seguro mediante HTTPS, de manera idéntica al paso (g) de la configuración tradicional. De lo contrario, el servidor responde con otra página de cola (de vuelta al paso II).

Tal como se ilustra en las Figuras 2 y 3, el servidor de cola de la presente invención se integra en un sistema de comercio electrónico conocido en un punto inmediatamente después de que un usuario haya elegido el producto efectivo y haya hecho clic en el botón de "Comprar". Un Anfitrión de servicios de destino (en las Figuras 2 y 3, se trata de la pasarela de pago y el servidor web seguro 22) presenta una página de destino, por ejemplo una página de datos de tarjeta de crédito. En la Figura 2, el usuario es llevado directamente a la página de destino; sin embargo, en la Figura 3 el usuario es dirigido a un servidor 30 de cola, que a su vez está conectado a la página de datos de tarjeta de crédito. En una realización preferida, el servidor de cola se ha implementado utilizando Java en un servidor Tomcat J2EE Servlet Server. Los servidores de cola tienen las siguientes propiedades:

1.

Para tasas de peticiones entrantes inferiores a la tasa óptima de la pasarela de pago, se reenvía al usuario directamente a la página de datos de la tarjeta de crédito.

2.

Para tasas de peticiones entrantes superiores a la tasa óptima de la pasarela de pago, se mantiene al usuario en una cola gestionada automáticamente.

3.

Los usuarios salen de la cola en base a un criterio de "el primero en llegar es el primero en ser atendido", a la tasa óptima para la pasarela de pago (que puede encontrarse algunas páginas más allá de la página de destino).

4.

Mientras forman parte de la cola, a los usuarios se les informa de la duración probable de su espera. Cuando llega su turno, son enviados automáticamente a la página de destino.

5.

Los usuarios pueden abandonar la cola en cualquier momento si cierran la ventana del navegador (y opcionalmente se desconectan de Internet). Se les guarda su lugar en la cola y, en caso de que haya pasado su turno cuando vuelven a acceder, son llevados directamente a la página de destino. Esto resulta particularmente beneficioso para usuarios que se conectan a Internet a través de un módem y pueden estar sujetos a pagos por minuto de uso de Internet.

6.

Pueden emplearse simultáneamente múltiples colas para diferentes productos, o bien para proporcionar diferentes vías de acceso a un único producto.

El sistema de la presente invención, tal como se ha descrito, presenta una serie de beneficios tanto para los proveedores del sistema de comercio electrónico (y del producto que se vende), como para los clientes que utilizan el sistema. En primer lugar, se elimina el riesgo de un fallo catastrófico. En segundo lugar, los propietarios del sistema de comercio electrónico reciben un flujo casi constante de clientes a la tasa óptima para ellos, que pueden especificar y controlar durante la venta en tiempo real. Al haber recuperado el control sobre la velocidad con que se

reciben los pedidos, pueden expandir la venta a lo largo de varios días, ahorrando sustancialmente en costes de componentes físicos y de personal. En tercer lugar, los usuarios del sistema de comercio electrónico perciben que son parte de una cola justa, y que serán servidos en base a un criterio de "el primero en llegar es el primero en ser atendido". Incluso los usuarios que llegan demasiado tarde para comprar productos disponibles en cantidad limitada (por ejemplo entradas) percibirán que el sistema les ha tratado con prontitud y justicia. Esto incrementa en gran medida la satisfacción del usuario. Los usuarios tienen también una indicación de cuándo es probable que sean atendidos. Esto significa que, en lugar de tener que repetir continuamente sus acciones para obtener el producto, pueden hacer otras cosas con su tiempo, y entrar de nuevo cuando llegue su turno, lo que da como resultado una satisfacción del usuario mucho mayor.

Con un sistema de acuerdo con la presente invención, los usuarios ya no repiten sus acciones, y en consecuencia se reduce considerablemente la carga global sobre el sistema, evitando la propagación hacia atrás de un fallo catastrófico en el sitio web del producto (paso 1) y reduciendo aún más los costes de componentes físicos.

Los usuarios se encuentran con un servidor que les responde, lo que aumenta su satisfacción.

La solución de gestión de colas se puede utilizar también para evitar que algunas personas compren grandes cantidades del producto. Esto es particularmente útil para vendedores de entradas para eventos que deseen reducir el número de ventas realizadas a revendedores de entradas.

El sistema de cola de la presente invención utiliza un sistema de petición numerada para gestionar a usuarios nuevos y usuarios que retornan, de la siguiente manera:

1) Al entrar en la cola, a cada nuevo usuario se le asigna un "número de petición", que es almacenado en su ordenador como una información almacenada o "cookie" persistente. También se puede almacenar el número de petición en un correo electrónico, siempre que el cliente haya introducido su dirección de correo electrónico antes de unirse a la cola, o bien en la lista de marcadores o favoritos del navegador de Internet del usuario, o simplemente codificado en algún otro sitio de la respuesta de página web.

2) El sistema mantiene también un registro del número que está siendo atendido en ese momento (el "Número de atención"), que en una implementación preferida se incrementa automáticamente a una tasa constante (la "Tasa de incremento"). Tal como se discutirá más adelante, se puede modificar esta tasa mientras el servidor está funcionando, a fin de permitir un control preciso sobre la velocidad de paso de usuarios.

3) La respuesta del sistema de colas contiene el número de petición del usuario, el número de atención y la tasa de incremento. La respuesta HTML contiene código JavaScript que se ejecuta en el ordenador del usuario para transformar esta información en una presentación visual, que puede contener uno o más de los siguientes elementos.

-

El número de petición del usuario.

-

El número de atención.

-

La velocidad de paso.

-

El número de personas situadas delante del usuario en la cola (dado por el número de petición menos el número de atención).

-

El tiempo de espera estimado (dado por el número de personas situadas delante en la cola dividido por la velocidad de paso). Esto se puede mostrar en un formato de cuenta atrás.

-

Publicidad (en formato estándar de cabecera o "banner" de Internet) u otro contenido de fuentes de terceros.

La Figura 6 muestra un ejemplo de una presentación visual de "Página de cola" presentada al navegador del usuario y que muestra tanto el número de petición del usuario como el número de atención.

Además, el código que se ejecuta en el ordenador del usuario actualiza (recarga) automáticamente la página cada cinco o diez minutos o bien cuando el tiempo de espera llega a cero, lo que ocurra antes.

Cuando el usuario hace una nueva petición a la cola del servidor, ya sea mediante una recarga manual o a través del mecanismo automático de actualización, se envía automáticamente al servidor el número de petición previamente asignado en forma de una cookie, junto con la petición.

Si no se utilizan cookies, también se puede enviar el número de petición como parte de un enlace en un correo electrónico, en los marcadores del usuario (es decir, la lista de favoritos del navegador del usuario), o en una página web (en forma de una Cadena de consulta, por ejemplo ?Id=5323 dentro de una URL o un parámetro GET de HTTP), o bien como un Elemento de formulario almacenado dentro de una página web o correo electrónico HTML (que puede ser devuelto como un parámetro GET o POST de HTTP). Otros mecanismos alternativos de almacenamiento incluyen el almacenamiento del número de petición como una variable dentro de JavaScript o algún

otro elemento de la página HTML, y el almacenamiento en una base de datos dedicada.

El servidor de cola compara este número con el número de atención en ese momento. Si el número de petición es inferior o igual al número de atención, se traspasa al usuario a la página de destino. Esto permite a los usuarios retornar después de que su número haya sido "llamado", y aun así completar la transacción (suponiendo que quede producto que comprar).

Sin embargo, si el número de petición es mayor que el número de atención en el momento que se recibe la petición, al usuario se le muestra una página similar que contiene el nuevo número de atención y el nuevo tiempo de espera estimado, y/o el número de personas situadas por delante en la cola, todo lo cual puede variar si la velocidad de paso ha cambiado. En este caso no se genera ningún nuevo número de petición.

Cada cola se compone conceptualmente de dos componentes, a saber:

1.

Un único componente permanente de asignación, responsable de realizar el seguimiento del último número de petición concedido, de la tasa de incremento automático y del número de atención en ese momento.

2.

Múltiples componentes de petición, idénticos y efímeros, uno para cada petición de un usuario, responsables de conseguir, en caso necesario, nuevos números de petición desde el componente de asignación compartido, de confrontar números de petición entrantes, procedentes de usuarios que retornan, con el número de atención en ese momento, y de devolver al usuario la respuesta adecuada.

Este sistema tiene una serie de ventajas técnicas, que se combinan para permitirle hacer frente a colas de tamaño muy grande. El sistema es totalmente automático, ya que no se necesita que los usuarios introduzcan datos manualmente para participar en la cola. No se almacenan en el servidor datos individuales referidos al usuario (los números de petición individuales sólo se almacenan en las máquinas clientes), obviando la necesidad de anotaciones referidas a usuario en la base de datos, y aumentando aún más la disponibilidad. No se transmiten datos sensibles entre el usuario y el sistema de cola, obviando la necesidad de utilizar HTTPs como protocolo de transporte para el sistema, lo que aumenta aún más la disponibilidad. Aunque no sea necesario, hay que señalar que el sistema de cola de la invención puede estar adicionalmente protegido mediante HTTPs cuando ello sea necesario. Se minimiza el trabajo realizado por el servidor, ya que la lógica de presentación es realizada por la máquina cliente, permitiendo tasas de respuesta aún mayores.

Típicamente, el usuario que accede al sistema de cola ya habrá elegido un producto, aunque no haya introducido aún ninguna información personalmente identificable.

Cuando el usuario sale de la cola y es enviado a la página de destino, el anfitrión de servicios de destino necesitará típicamente información para identificar estas opciones con el fin de gestionar correctamente el pedido del usuario.

La invención aborda esta necesidad convirtiendo automáticamente en cookies cualesquiera parámetros GET (cadena de consulta) o POST de HTTP enviados al servidor cuando inicialmente se remitió el usuario a la cola, y almacenándolos en la máquina del usuario. También se pueden almacenar estos parámetros dentro de una página web, o bien por correo electrónico como antes. Si el usuario cumple los requisitos para ser atendido, estos parámetros son reenviados después al anfitrión de servicios de destino. Los diseñadores de los sistemas protegidos (los sistemas de anfitrión de servicios de destino) son libres de elegir exactamente la información que se almacene, para satisfacer sus necesidades.

En un ejemplo, la información acerca de la elección en sí misma puede ser almacenada en el ordenador del usuario por el servidor de cola. Como alternativa, el anfitrión de servicios de destino puede almacenar la información acerca de la elección, y el Servidor de cola puede almacenar una identificación de cliente en el ordenador del usuario, de manera que el anfitrión de servicios de destino pueda más tarde recuperarla.

Este último enfoque se utiliza habitualmente cuando se utiliza tecnología de sesiones para almacenar datos de usuario, aunque los Anfitriones de servicios de destino que se basan únicamente en el almacenamiento de un identificador de sesión deben cuidar de asegurar que la sesión no expire antes de que los usuarios abandonen la cola.

Aunque la solución discutida en lo que antecede envía a todos los usuarios en cola a una única página de destino, el sistema también es capaz de enviar a usuarios en cola a un abanico de páginas de destino, que pueden estar en diferentes Anfitriones de servicios de destino. Ello puede ser útil en diversos escenarios.

En un escenario, una sola cola puede ser utilizada para múltiples tipos de producto. Un ejemplo típico es la venta de un abanico de diferentes tipos de entradas (por ejemplo, entradas para residentes en el Reino Unido y entradas internacionales). Aunque es ciertamente posible encapsular esta elección utilizando los parámetros GET o POST almacenados de la sección precedente, también es posible implementarla enviando a los usuarios a páginas de destino diferentes.

Otra situación en la cual es útil la existencia de una pluralidad de páginas de destino se presenta cuando un

organizador de evento desea vender entradas a través de múltiples puntos de venta de sitios web. Se pueden enviar usuarios a una única cola desde cada uno de estos sitios web, y luego se les remitirá de vuelta a la página web correspondiente cuando les llegue su turno. Esto permite al organizador del evento asegurar una equidad de "primero en llegar, primero en ser atendido", a través de los múltiples puntos de venta, permite la protección simultánea de todos los sitios del vendedor y permite un control preciso del momento exacto en el cual están disponibles las entradas en cada uno de los sitios.

El sistema de acuerdo con la invención se puede configurar también para utilizar una pluralidad de páginas de destino para distribuir de forma equilibrada entre diferentes servidores la carga de usuarios que salen automáticamente de la cola, si se desea, utilizando una diversidad de algoritmos de distribución equilibrada de cargas.

Es deseable que el sistema responda a peticiones administrativas para gestionar la cola (por ejemplo, para reducir la tasa de incremento si el anfitrión de servicios de destino supera su tasa óptima), y también que se pueda recuperar la cola en caso de un reinicio del servidor debido a problemas imprevistos. Esto se logra de la manera siguiente.

Todos los números de petición individuales se almacenan en las máquinas clientes, por lo que el reinicio del servidor no perturba la posición de un individuo en la cola. Los números de petición y de atención actuales son registrados en el almacenamiento permanente de forma regular (por ejemplo una vez cada diez segundos), para permitir la recuperación automática de la cola en caso de un reinicio de servidor o fallo de la base de datos.

Los números de petición y de servicio actuales, así como otros parámetros de la cola, son comparados también con los datos de entrada en el almacenamiento permanente (por ejemplo, el sistema de archivos interno y/o una base de datos externa) una vez cada diez segundos, permitiendo el control de estos valores mientras el servidor está funcionando.

Los datos de entrada (y el almacenamiento permanente) son administrados de forma remota a través de una conexión de Internet dedicada separada, que garantiza que el servidor pueda ser controlado incluso bajo cargas muy altas.

Existe una serie de estrategias de tasa de incremento que son adecuadas en diferentes situaciones. Ya se ha mencionado el incremento automático del número de atención (que determina cuáles de los usuarios en cola pueden optar a ser atendidos). En la implementación más sencilla del sistema de la invención, esta tasa de incremento es una constante (expresada en usuarios por minuto), que puede ser modificada sobre la marcha por los administradores del sistema.

La tasa de incremento constante es una buena estrategia si se prevé que los clientes van a intentar utilizar el servicio muy poco tiempo después de que se haya "llamado" a su número de petición. Sin embargo, puede que no siempre sea éste el caso; por ejemplo, en el caso de una cola que funcione toda la noche, puede ocurrir que las personas eviten la compra a altas horas de la madrugada, aunque les haya llegado el turno. Esto puede producir una acumulación de clientes a primera hora de la mañana, ya que los clientes pasan a través del sistema en cualquier momento después de que su número de petición haya sido llamado.

Una estrategia más sofisticada es determinar el número real de personas que han pasado por el sistema de cola en un minuto particular, y reducir (o aumentar) la tasa de incremento si es mayor (o menor) que la tasa óptima del anfitrión de servicios de destino. En casos extremos, esto puede llevar a que, de hecho, el número de atención disminuya (en lugar de aumentar más lentamente).

Otra estrategia consiste en hacer que el anfitrión de servicios de destino controle la tasa de incremento directamente a través del uso de mensajes enviados desde el anfitrión de servicios de destino a los servidores de cola (de acuerdo con alguna fórmula calculada por el anfitrión de servicios de destino). Por lo general, esto se debe evitar debido al trabajo adicional que realiza el anfitrión de servicios de destino, pero en caso necesario se puede implementar fácilmente.

Dependiendo del tamaño del pico entrante, pueden ser necesarios muchos servidores de cola para hacer frente a todas las peticiones de personas en la cola. Una cola de servidor típica de acuerdo con la invención funciona a un ritmo de 30.000 por minuto y por servidor. Como el servidor no necesita conexiones externas a una red o base de datos de procesamiento para funcionar, se pueden agregar servidores adicionales para permitir una puesta en cola arbitrariamente grande.

En este caso, cada cola es replicada en cada uno de los servidores. Cada servidor mantiene su propio componente de asignación, con su propio número actual de petición y número actual de atención. Los servidores comparten los mismos datos de entrada y la base de datos para el control de los parámetros de cola, de manera los cambios hechos en los mismos afectan a todos los servidores en el espacio de diez segundos. Los servidores se sincronizan entre sí una vez cada diez segundos para proporcionar números congruentes a los usuarios.

Los usuarios pueden esperar resultados consistentes de cada servidor, por lo que los servidores pueden ser asignados al azar a las peticiones entrantes, con independencia de con cuál de los servidores haya interactuado

previamente un usuario. Esto elimina la necesidad de una distribución "pegajosa" de cargas entre los servidores, en el cual a un usuario en particular siempre se le dirige al mismo servidor, lo que reduce aún más los costos del componente físico.

La Figura 4 ilustra la distribución de cargas cuando se utilizan múltiples servidores de cola. También se ilustra un sistema de gestión. Un terminal 40 de administrador de cola está conectado a un sistema 41 de gestión. El sistema 41 de gestión está conectado a cada uno de los servidores paralelos 42 de cola. Las colas son establecidos por el administrador de cola. El administrador 40 de cola interactúa con el sistema 41 de gestión de colas en el paso (a). El administrador de cola carga archivos de plantilla y otros datos a través de peticiones y respuestas HTTP hacia y desde el sistema 41 de gestión. El sistema 41 de gestión almacena las plantillas y los datos en su propio almacenamiento permanente (compuesto de una base de datos y/o un sistema de archivos, según el caso). Los datos conservados por el sistema 41 de gestión son propagados a los sistemas de memoria y de archivo de los servidores 42 de cola en el paso (b).

En una realización, cada servidor 42 de cola mantiene datos relativos a varias colas diferentes creadas de esta manera. Una vez que los servidores 42 de cola han sido adecuadamente configurados por el sistema de gestión, se pueden poner en cola las peticiones de los clientes en los servidores de cola a través de un equilibrador 43 de cargas. La comunicación entre el equilibrador 43 de cargas y los clientes en cola se indica como paso (c). El equilibrador 43 de cargas se encarga de repartir equitativamente las peticiones de los usuarios entre los servidores configurados, con el fin de hacer el mejor uso del ancho de banda disponible. No se almacenan en el sistema datos referidos a usuarios, y por tanto cualquier servidor puede atender al usuario puesto en cola y no se requiere una distribución de cargas "pegajosa" o basada en la sesión. Una vez que se ha recibido la petición en un servidor de cola se le asigna a la cola apropiada y se le otorga un número de petición. A continuación, el proceso de puesta en cola prosigue como se ha descrito con referencia a la Figura 3.

En los casos en que se utilice más de un servidor, también se pueden configurar los servidores para aumentar los números de petición emitidos en incrementos distintos de la unidad. Por ejemplo, si se utilizan dos servidores, uno puede emitir números de petición dentro de la secuencia (1, 3, 5, 9, ... ), y el otro dentro de la secuencia (2, 4, 6, 8, ... ). Esto asegura que no haya dos clientes que compartan el mismo número de petición.

Opcionalmente, se pueden configurar los componentes de asignación para obtener nuevos números de petición desde una única fuente para asegurar la equidad de que se atienda primero al primero en llegar, aunque esto puede imponer límites en el número de nuevas personas admitidas en cola por minuto.

Se pueden establecer colas (dominios) separadas, basadas en datos identificadores del cliente o del producto. Cuando sea adecuado, se pueden utilizar los dominios en sí mismos para equilibrar la carga entre servidores. Esta separación de colas se conoce como "creación de colas de dominio" y se explica mejor con un ejemplo.

Considérese un organizador de evento que desea vender entradas por todo el país. Es probable que se produzca un gran exceso de peticiones, por lo que se despliega el sistema de colas. Debido al alto interés, la cola se llena (es decir, tiene tantos clientes en cola como entradas disponibles) en muy poco tiempo (por ejemplo 5 minutos).

Si sólo se utiliza una cola, las personas con mejor acceso a Internet (por ejemplo, menor latencia, mayor ancho de banda eficaz, mejor relación de contención) tienen más probabilidades de tener acceso a los servidores de cola durante este tiempo debido a la saturación de la red. Esto significa que una cantidad desproporcionada de entradas irá a parar a personas que viven en grandes ciudades, que están más cerca de la red troncal de Internet del país.

Una forma de resolver esto consiste en emplear múltiples colas basadas en datos geográficos de cliente. Por ejemplo, si los clientes introducen las primeras letras de su código postal (por ejemplo, "EX" para Exeter) antes de entrar en la cola, se puede desplegar una cola separada para cada uno de estos dominios geográficos.

Esto asegura que cada región es puesta en cola por separado. Aunque puede ocurrir que los clientes de zonas remotas necesiten más tiempo para alcanzar el servidor de cola, todavía son puestos en cola en orden y con la misma prioridad que los de las grandes ciudades.

Se pueden utilizar otros "dominios". Por ejemplo, se pueden asignar clientes a colas separadas basándose en información demográfica (es decir, edad, sexo, etc.), o en información del producto, tal como el nivel de precio.

Cuando sea posible, se debe comprobar la información de dominio en el momento de la compra del producto para prevenir el fraude (por ejemplo, en el ejemplo anterior se debe contrastar el código postal que se haya declarado frente al que se introduzca en el formulario de tarjeta de crédito cuando se compren las entradas).

Cada una de estas colas es manejada por un objeto asignador independiente dentro del marco del sistema de colas. También es posible asignar una cierta cantidad de producto a cada una de estas colas, y cerrar automáticamente cualquier cola de dominio dada cuando se haya vendido dicha cantidad. Esto proporciona a los proveedores de productos un control preciso sobre la distribución del producto incluso en situaciones de carga muy alta.

Además, es posible controlar todas estas colas utilizando, por simplicidad, un único número de atención.

Como ejemplo concreto, considérese una situación en la cual un evento desea vender 100.000 entradas. 90.000 de éstas deben ser distribuidas a residentes en el Reino Unido (dominio "UK"), mientras que el resto va a clientes internacionales (dominio "Int"). En este caso, los servidores de colas usan aritmética de coma flotante para asignar números de petición dentro de la secuencia 10, 20, 30, 40, ... a la cola "Int", y dentro de la secuencia 1, 2, 3, ... 9, 11, ... a la cola "UK". Esto significa que cuando el (único) número de atención llega a 100.000, hay 90.000 residentes del Reino Unido que pueden optar a entradas y 10.000 clientes internacionales que pueden hacerlo, según se requiera.

El sistema de cola está integrado convenientemente con el sistema de ventas que lo protege. Esta configuración sirve tanto para evitar el fraude (lo que se discutirá más adelante), como para permitir la gestión automática de colas basados en eventos de venta. Se puede ver un claro ejemplo de las ventajas de un sistema integrado de colas cuando se han vendido todas las entradas para un dominio en particular, ya que a las personas que quedan en la cola se les debe avisar de ello, de manera que puedan abandonar la cola.

También se pueden utilizar datos de seguimiento de ventas para proporcionar una indicación a los administradores del sitio de cómo está progresando la venta, y de si deben transferir entradas de un dominio a otro con el fin de venderlas todas. Esto se puede hacer sobre la marcha durante la venta utilizando el sistema de cola de la invención.

El sistema de colas de la invención admite tres maneras de cerrar colas en base a los datos de venta. En primer lugar, se puede emplear simplemente el cierre manual de cola. En este método, los administradores del sitio del anfitrión de servicios de destino utilizan una interfaz web para indicar manualmente que se han vendido todas las entradas. Esto puede hacerse sobre una base de dominio a dominio, o bien simplemente se puede declarar que se han vendido todas las entradas para todos los dominios. En cualquiera de los dos casos, a los usuarios en cola se les muestra, en su siguiente visita a los servidores de cola, una página distinta que indica que la venta ha terminado, y no se asignan nuevos números de petición a nuevos usuarios. Dependiendo de la configuración deseada, también se pueden enviar mensajes de texto SMS o mensajes de correo electrónico a los usuarios que han introducido la información necesaria.

Como alternativa, el sistema de colas puede utilizar un cierre de colas automático integrado. En este método, la compra de una o varias entradas en el anfitrión de servicios de destino hace que se envíe un mensaje a los servidores de cola indicando que se ha vendido un determinado número de entradas. El mensaje puede ser enviado directamente desde el anfitrión de servicios de destino, o bien puede ser enviado desde el navegador del usuario a través de una petición incrustada a un archivo en los servidores de cola dentro de la página web "pedido cumplimentado satisfactoriamente" que se muestra al usuario cuando le han sido asignadas entradas.

En ambos casos, el mensaje debe incluir el número de entradas adquiridas, cualquier información de dominio que se precise, y el número de petición del comprador (para evitar que mensajes duplicados sean tratados como pedidos posteriores).

Los servidores de cola deben ser preconfigurados con un número máximo de entradas a vender para cada dominio. Cuando el número de entradas vendidas indicado para un dominio particular alcanza este máximo, se cierra la cola para el dominio como en el caso anterior.

En una forma alternativa de cerrar colas en base a datos de venta, se puede utilizar un sencillo cierre automático de cola. En este método no hay mensajes enviados desde el anfitrión de servicios de destino. En lugar de ello, el servidor de cola cierra la cola para un dominio particular después de que haya pasado a través de la misma un número preespecificado de personas.

Hay una serie de tipos de fraude que deben impedirse en sistemas de comercio electrónico gestionados por colas. Son éstos:

1.

Salto de cola. Se produce cuando un usuario ya es parte del sistema de colas, pero intenta reducir el valor de su número de petición con el fin der atendido más rápidamente, posiblemente con la cooperación de otro usuario situado por delante de él en la cola.

2.

Rodeo de cola. Se produce cuando un usuario intenta acceder a la página de pago sin haber pasado en absoluto a través del sistema de gestión de cola.

3.

Compra múltiple. Se produce cuando un usuario, habiendo pasado a través del sistema de cola, realiza múltiples compras del producto. Esto sólo puede ser indeseable en algunas circunstancias, por ejemplo una venta de entradas tal como se ha discutido anteriormente.

4.

Fraude de dominio. Se produce cuando un usuario intenta comprar producto fuera del dominio que ha declarado.

Aunque ningún sistema informático está completamente libre de la posibilidad de un mal uso, la presente invención puede incluir pasos para prevenir estos fraudes.

El problema de salto de cola se ataja de la manera siguiente. En primer lugar, el uso de cookies para almacenar los

números de petición representa un obstáculo sustancial para el internauta ocasional, que necesitaría habilidades técnica considerable para modificar su contenido. Para evitar el fraude por parte de personas que tengan estas habilidades, se utiliza un sistema adicional, basado en las funciones de "hash" o "tecla almohadilla".

Una función hash es una función que toma una cadena léxica como entrada, por ejemplo "Hello World!" y produce otra cadena léxica como salida, por ejemplo, "AH74KFEu". Las funciones hash utilizadas para los procesos de seguridad producen salidas que dependen sensiblemente de la entrada. Por ejemplo, el hash de la cadena ligeramente diferente "Hellq World!" debería ser algo completamente diferente, por ejemplo: "Klo9SydP". Además, no debe haber ninguna forma de recuperar la cadena original a partir de su equivalente hash.

El sistema de cola de la presente invención puede utilizar el algoritmo de hash MD5 estándar de la industria para implementar la protección contra el fraude de la siguiente manera. Cuando a una petición del usuario se le asigna inicialmente un número de petición, por ejemplo 1537, éste se combina en el servidor con una frase secreta válida para toda la venta, produciendo una cadena léxica, por ejemplo "MyEventTickets1537". A esta cadena se le antepone una cadena adicional que (idealmente) identifica de manera única ese ordenador de usuario. Una implementación preferida utiliza los dos primeros octetos o "bytes" de la dirección IP del usuario, para generar una cadena final como, por ejemplo, "209.157MyEventTickets1537". El servidor aplica entonces una función hash a esta cadena, y el hash se almacena junto con el número de petición original en la máquina de usuario en forma de una cookie. Nunca se transmite la frase secreta directamente al ordenador del usuario.

La cadena de hash almacenada se utiliza ahora para validar números de petición cuando el usuario retorna al servidor de cola de la manera siguiente. Cuando un usuario retorna al servidor de cola, se devuelven al servidor como parte de la petición de la página tanto el número de petición original como la cadena de hash almacenada. El servidor reconstruye entonces la cadena de hash adecuada para el número de petición devuelto a partir de la frase secreta y de la dirección IP, y la compara con la cadena de hash devuelta por el ordenador del usuario.

Si las dos cadenas son idénticas, la petición del usuario es considerada válida y se trata de forma adecuada.

Si las dos cadenas difieren en cualquier aspecto, la petición del usuario es considerad no válida. Al usuario se le asigna un nuevo número de petición, más alto, y una nueva cadena de hash, y se le envía efectivamente al final de la cola como castigo por hacer trampas.

Es importante tratar de identificar de forma única el equipo de usuario en la entrada a la función hash, ya que de lo contrario se podrían compartir pares de cookies "petición-hash" que posibilitarían a muchas personas utilizar el mismo número de petición, permitiéndoles efectivamente saltarse la cola. La implementación descrita en lo que antecede utiliza los dos primeros octetos de la dirección IP, ya que muchas personas no tienen direcciones IP estáticas (constantes), sobre todo si se desconectan de Internet y vuelven más tarde. Sin embargo, las personas con direcciones IP dinámicas (cambiantes) tienen por lo general los mismos primeros dos octetos debido a la implementación técnica adoptada por su proveedor de servicios de Internet.

Además, se pueden encontrar datos de identificación únicos en la cadena de identificación del navegador que es parte de cada petición HTTP.

Se puede conseguir protección adicional contra el fraude tomando información personal, por ejemplo los últimos cuatro números de la tarjeta de crédito o un código postal asociado a la tarjeta que se va a utilizar, antes de unirse a la cola, y añadiendo esta información a la cadena de hash.

Después de haber identificado una forma de validar usuarios en cola, es posible utilizar también este sistema para evitar que usuarios accedan sin pasar por la cola, de la siguiente manera. La página de destino de la cola (normalmente la página de datos de la tarjeta de crédito) verifica que los usuarios que acceden han sido remitidos por la página de gestión de cola mediante el campo de remitente de petición HTTP. Los demás usuarios son enviados inmediatamente a la cola para su tratamiento.

La página de destino también realiza la misma comprobación de validación que el sistema de colas realiza utilizando hashes del número de petición. Los usuarios que no superan la comprobación son devueltos a la cola para ser procesados.

Si se desea, la página de destino puede realizar una comprobación de validación utilizando una frase secreta diferente, para distinguir entre usuarios que han pasado por la cola y usuarios que todavía pueden estar en la cola.

Para evitar que haya personas que realicen repetidas transacciones de compra, posiblemente con varias tarjetas de crédito, la página de respuesta de la pasarela de pago que indica al usuario que la transacción ha tenido éxito debe borrar las cookies almacenadas que representan la petición original y el hash de seguridad.

Automáticamente, cualquier intento adicional de comprar el producto dará entonces como resultado que se devuelva al usuario al final de la cola. En ventas que tengan un gran exceso de peticiones, esto evitará efectivamente que dicho usuario pueda hacer múltiples compras.

Cuando se utilizan colas de dominio, un cliente puede intentar comprar producto fuera de su dominio declarado. Por ejemplo, una persona sita en Londres, al darse cuenta de que la cola para Londres está llena, puede informar en lugar de ello que se encuentra en cualquier otro dominio. El sistema de colas almacena todas las opciones de dominio (en este caso el código postal introducido), y las reenvía al anfitrión de servicios de destino. El anfitrión de servicios de destino debe asegurarse de que éstas concuerden con cualquier información posterior suministrada por el cliente. En este ejemplo, el código postal suministrado debe coincidir con el código postal introducido en el formulario de la tarjeta de crédito, o bien con la dirección de entrega.

Opcionalmente, también se pueden incluir datos de dominio en la cadena utilizada para el hash de seguridad, o bien se pueden almacenar en la base de datos de la cola para su posterior comprobación cuando se utilicen otros puntos de venta.

Ya se ha subrayado que el almacenamiento de identificadores de cola permite a los clientes apagar sus ordenadores mientras se encuentran en la cola, sin que pierdan su lugar. Por tanto, no hay garantía de que un cliente determinado se encuentre en línea cuando le llegue el turno, sobre todo si es probable que la cola exista durante un período prolongado de tiempo.

Por tanto, es deseable que se pueda notificar a los clientes de que el número de atención ha superado a su número de petición. Para ello, los servidores de cola pueden estar configurados para almacenar datos de comunicaciones del cliente, tales como una dirección de correo electrónico y/o un número telefónico, y enviar un correo electrónico o mensaje de texto SMS cuando sea apropiado. El sistema de cola hace esto almacenando la dirección de correo electrónico y/o el número de teléfono en una base de datos, junto con el número de petición, y comprobando periódicamente esta tabla de base de datos frente al número de atención en ese momento y emitiendo automáticamente los mensajes necesarios.

Aunque se puede configurar el sistema para obtener esta información de todos los usuarios antes de entrar en la cola, esto no es recomendable por razones de rendimiento. En lugar de ello, es mejor asignar primero a cada usuario su número de petición, y proporcionarle después los medios (opcionales) para registrar su dirección de correo electrónico o su número de teléfono para que se le notifique si lo desea.

En muchos casos se puede agotar una partida inicial de producto en venta, y al cabo de un tiempo se puede disponer de más producto. Un ejemplo lo constituiría un vuelo en una aerolínea. Realmente, las compañías aéreas venden más billetes que asientos en cualquier vuelo dado, ya que esperan un cierto número de cancelaciones, y se deben asegurar que cada vuelo se llena hasta su capacidad máxima. Esto lleva a que los clientes sean "empujados" a otros vuelos cuando no se alcanza el número esperado de cancelaciones, lo que lleva a costes adicionales y a insatisfacción del cliente.

Con el sistema de cola de la invención, la aerolínea puede suspender la cola cuando se han vendido todas las plazas del vuelo. Después de ello, cada nuevo cliente potencial se une a la cola en orden, y proporciona información de contacto para la notificación al cliente. Cuando se producen cancelaciones, los billetes cancelados pueden ser ofrecidos en orden a los clientes que están en la cola, incrementando el número de atención a un ritmo lento y constante, hasta que se hayan vendido los billetes cancelados.

En vista de lo anterior, debería estar claro que la presente invención es aplicable no sólo al comercio electrónico, sino también a cualquier escenario en el que la demanda a través de una red de comunicaciones pueda exceder la capacidad. También debe dejarse claro que cuando se usa Internet, las peticiones de servicio en el método y sistema de la presente invención pueden utilizar, o bien parámetros GET de HTTP, o bien parámetros POST de HTTP, según sea más apropiado en cada circunstancia.

El método de la presente invención puede ser codificado como programa informático que se ejecute en dispositivos de componentes físicos existentes. Como alternativa, se pueden construir componentes físicos ("hardware") o programas de fabricante ("firmware") específicos para implementar la invención. La presente invención se puede poner en práctica como el uso de un servidor de cola de manera remota a través de una red de comunicaciones como un servicio a proveedores de servicio. Como alternativa, se puede integrar un servidor de cola adecuadamente programado en una arquitectura existente del proveedor de servicios.

Como será claramente obvio, la mayoría de las ventas de entradas no tienen lugar exclusivamente en línea. Por lo general, los clientes también pueden llamar a una línea telefónica. A veces se utilizan también otros puntos de venta, tales como taquillas físicas o dispositivos de mensajes de texto SMS. La invención facilita la integración de teléfono, internet y otros sistemas de cola, permitiendo así a los clientes que se unen a la cola en un punto de venta comprar producto en otro.

En una realización igualmente importante, la presente invención también se puede aplicar a sistemas de venta telefónica de productos. La realización telefónica tiene similitudes con la realización por Internet (comercio electrónico) descrita anteriormente. Hay, sin embargo, una diferencia importante: Los teléfonos no son, por lo general, capaces de almacenar datos, así que los números de petición deben ser almacenados en el servidor.

Las situaciones que ofrecen ventas u otros servicios prestados por teléfono tienen frecuentemente exceso de

peticiones. Esto puede dar como resultado una cola de clientes "en espera" debido a la escasez de operadores, o bien que nuevos clientes reciban tono de ocupado si el proveedor de servicios se ha quedado sin líneas de teléfono para conectar con ellos. Ambos casos producen insatisfacción del cliente, y pueden dar lugar a gastos adicionales en telecomunicaciones tanto para el proveedor de servicios como para el cliente.

En lugar de presentar una interfaz HTML, un sistema de cola telefónica de acuerdo con la invención está provisto de un mensaje de audio generado automáticamente. El mensaje de audio (por lo menos) indica que el cliente está en una cola, y actualiza su tiempo de espera estimado a intervalos regulares.

Existen dos implementaciones ligeramente diferentes de la realización del sistema de cola telefónica, dependiendo de si un único número de teléfono debe dar soporte a múltiples lugares de la cola.

En el sistema telefónico más simple, cada número de teléfono se asocia con un solo número de petición (un lugar en la cola). Los clientes que llaman a la línea telefónica son encaminados a través de un servidor de cola telefónica (utilizando, por ejemplo, el PBX de código abierto Asterisk). El servidor de cola comprueba primero el número de teléfono entrante mediante una función de identificación del número de la llamada entrante. Si la información de identificación del número de la llamada entrante no está disponible, se puede configurar al servidor de cola para que, o bien pida al interlocutor que cuelgue, active el identificador de número de llamada entrante, y pruebe de nuevo, o bien pida al usuario que introduzca su número de teléfono utilizando el teclado numérico. Opcionalmente, el servidor de cola telefónica puede pedir al cliente que proporcione los cuatro últimos números de su tarjeta de crédito, u otra información personal, para proporcionar protección suplementaria contra el fraude.

A continuación, el servidor de cola comprueba el número de teléfono frente a una base de datos de números de teléfono que ya están en la cola.

Si el número no está en la base de datos, la persona que llama es "nueva", y el servidor de cola telefónica emite un número de petición nuevo y lo almacena junto con el número de teléfono en la base de datos. Opcionalmente, también se puede utilizar la formación de colas por dominios, utilizando reconocimiento de voz o datos procedentes del teclado numérico para especificar la información de dominio antes de que se emita el número de petición.

Si, por el contrario, el número de teléfono ya está en la base de datos, la persona que llama es "reconocida", y se extrae de la base de datos el correspondiente número de petición.

Si el número de petición es mayor que el número de atención en ese momento y si el cliente es nuevo, se lee a la persona que llama el nuevo número de petición, y el sistema también lo puede enviar al cliente mediante un mensaje de texto SMS. A continuación se informa a la persona que llama del número de atención en ese momento, y se le proporciona una estimación de cuánto tiempo tendrá que esperar hasta cumplir los requisitos para ser atendido.

Si, como otra alternativa, el número de petición es mayor que el número de atención en ese momento, pero se reconoce al cliente, se informa a la persona que llama de que su número de teléfono ha sido reconocido, y se le puede volver a leer su número de petición. A continuación, se informa al cliente del número de atención en ese momento, y se le proporciona una estimación de cuánto tiempo durará la espera hasta cumplir los requisitos para ser atendido.

A las personas que llaman se les da la opción de colgar y volver a llamar después de transcurrido un tiempo preacordado personalizado, en cuyo momento pueden esperar ser conectados inmediatamente. Un mensaje ejemplo es: "Hola. Debido a la elevada demanda, usted ha sido puesto en una cola. Su tiempo de espera es de 10 minutos y 24 segundos. Su número de teléfono ha sido guardado en nuestro sistema y será reconocido, así que por favor cuelgue y vuelva a llamar después, con lo cual será atendido inmediatamente". Esto ahorra a quien llama el gasto de estar en espera.

Opcionalmente, el sistema puede colgar en este punto. Si el servicio se está quedando sin líneas telefónicas para atender a nuevos clientes, el cliente recibe el mensaje siguiente: "Hola. Debido a la elevada demanda, usted ha sido puesto en una cola. Su tiempo de espera es de 10 minutos y 24 segundos. Su número de teléfono ha sido guardado en nuestro sistema y será reconocido, así que por favor vuelva a llamar después, con lo cual será atendido inmediatamente. Esta llamada se terminará ahora". Esto ahorra a quienes llaman el gasto de estar en espera y ahorra al proveedor los gastos de usar múltiples líneas telefónicas para mantenerles en espera.

El sistema también puede devolver automáticamente la llamada a los clientes, a los números de teléfono almacenados, cuando les llega su turno. En lugar de obligar a los usuarios a volver a llamar al servicio, el servicio les devuelve automáticamente la llamada cuando queda disponible un operador. Esto ahorra a la persona que llama el gasto de una segunda llamada de teléfono (que es asumido, en su lugar, por el proveedor).

Si, por el contrario, el número de petición es menor que el número de atención en ese momento, el cliente cumple los requisitos para ser atendido. O bien el servidor de cola telefónica atiende la llamada del cliente, o bien se reenvía la llamada a un anfitrión de servicios de destino (otro PBX en este sistema de telefonía), o bien a un operador de atención.

En lugar de decirle al cliente su número de petición o el número de atención en ese momento, el sistema puede simplemente dar un tiempo estimado de espera.

Opcionalmente, cuando se ha vendido el producto, el anfitrión de servicios de destino (el PBX a través del cual está disponible el producto o servicio) puede hacer que el sistema de cola telefónica vete números de teléfono, o los elimine de la base de datos, para evitar el fraude (por ejemplo, por parte de revendedores de entradas).

En un sistema de cola telefónica, se pueden asignar múltiples lugares en la cola a un solo número de teléfono. Por ejemplo, podría darse el caso de que todas las personas de una oficina utilicen un único número de teléfono para realizar llamadas al exterior. El sistema de cola obtiene primeramente un número de teléfono como se ha descrito arriba, y lo compara con la lista de números de teléfono almacenados en la base de datos.

Si el número de teléfono no está en la base de datos, el teléfono es considerado "nuevo", y en caso contrario, el teléfono es considerado "reconocido".

Si el número de teléfono es "nuevo", se emite un nuevo número de petición del mismo modo que en el caso de la correspondencia "uno a uno" precedente, y también se genera un código numérico de confirmación utilizando una función de hash del número de teléfono, el número de petición, y una frase secreta del mismo modo que en la solución de Internet descrita antes arriba. El código de confirmación se almacena junto con el número de petición y el número de teléfono en la base de datos. Se lee el código de confirmación a la persona que llama, y también puede ser enviado en un mensaje de texto SMS como antes. A la persona que llama se la considera "nueva".

Si el número de teléfono es "reconocido", a la persona que llama se le pregunta si ya está en la cola, y responde pulsando el teclado numérico en su teléfono o bien a través de tecnología de reconocimiento de voz.

Si la persona que llama indica que ya está en la cola, se le pide a la persona que llama que introduzca un código de confirmación. Si éste coincide con un registro ya almacenado en la base de datos junto con un número de teléfono coincidente, a la persona que llama se la trata como "reconocido". Si no es así, se pide a la persona que llama que vuelva a introducir su código de Confirmación o bien (opcionalmente) se le asignan nuevos número de petición y código de confirmación de la manera siguiente.

Si el número de teléfono es "reconocido", pero la persona que llama indica que no se encuentra ya en la cola, se generan, almacenan y se envían como antes un nuevo número de petición y código de confirmación. A la persona que llama se la considera "nueva".

Los interlocutores nuevos y los reconocidos son tratados después como se ha descrito en el caso de correspondencia uno a uno más arriba.

Cuando el producto ha sido vendido a la persona que llama, se puede vetar a dicha persona o eliminarla de la base de datos mediante la anulación o la alteración del registro correspondiente a su número de teléfono y código de confirmación.

De esta forma, múltiples clientes pueden utilizar el mismo número de teléfono, pero son tratados individualmente por el sistema.

En una variación de las realizaciones de sistemas telefónicos de cola, se puede modificar fácilmente el sistema de cola telefónica para proporcionar un servicio de gestión de cola a través de SMS (los llamados "mensajes de texto").

Al igual que en el sistema de cola telefónica, en donde hay una realización de correspondencia "uno a uno", el cliente entra en la cola por primera vez mediante el envío de un mensaje de texto a un servidor de cola por SMS. El mensaje de texto puede contener también información de dominio que se utiliza para encaminar al cliente a la cola adecuada. El servidor responde con un mensaje de texto de vuelta al teléfono del cliente indicando (opcionalmente ) el número de petición del cliente, (opcionalmente) el número de atención en ese momento, y una estimación del tiempo que tendrá que esperar. El número de petición y el número de teléfono (móvil) son almacenados en una base de datos del mismo modo que en las realizaciones de servicio de cola telefónica.

Posteriores mensajes de texto enviados al servidor de cola por SMS generan una respuesta que indica un tiempo de espera actualizado.

Cuando el número de atención supera al número de petición emitido, el servidor puede responder comprando de forma automática el producto (y facturando al usuario a través del proveedor de servicios telefónicos del usuario), o bien notificando al cliente de que debe realizar alguna otra acción o permitiendo al cliente que realice alguna otra acción.

También se proporciona una realización de servicio de cola por SMS de la invención con correspondencia "muchos a uno". Esta realización es idéntica a la de la correspondencia "uno a uno" precedente, salvo porque el mensaje devuelto al entrar en la cola contiene un código de confirmación. Este código debe ser devuelto en mensajes posteriores por parte del cliente, para que el sistema distinga entre clientes diferentes que utilicen el mismo teléfono.

Otra realización integra los sistemas por Internet y por SMS antes descritos, utilizando las funcionalidades del correo electrónico. La mayoría de clientes de correo electrónico modernos son capaces de mostrar páginas de correo electrónico HTML, aunque algunos no lo son. Algunos clientes de correo electrónico también son capaces de almacenar cookies.

Los clientes entran en la cola al introducir su dirección de correo electrónico era una página web, o bien enviando un correo electrónico a una dirección de correo electrónico particular. La página de correo electrónico o web puede recopilar otros datos para el establecimiento de colas por dominios. Un servidor de colas (por correo electrónico) responde generando un número de petición, y enviando un correo electrónico de vuelta a la dirección recibida.

El correo electrónico de respuesta puede contener un enlace que incluya el número de la petición del usuario y un hash de seguridad (aunque puede que no haya manera de asegurar que este hash de seguridad esté construido a partir de datos específicos del terminal, se puede utilizar para ello la dirección de correo electrónico del cliente).

Después se puede hacer clic en este enlace, o bien copiarlo y pegarlo en un navegador web para unirse posteriormente a una cola de internet. El servidor responde a la petición encapsulada por el vínculo almacenando la información de cola apropiada en el terminal del cliente o en el servidor de cola, según sea apropiado. El cliente forma entonces parte de una cola de internet.

El correo electrónico puede contener también un elemento (por ejemplo un gráfico) descargado desde el servidor de cola; esta descarga puede hacer también que el navegador del usuario almacene la información necesaria para participar en la cola de Internet, sin que el cliente tenga que pegar el enlace o hacer clic en el mismo mediante el uso de cookies persistentes o de los marcadores del usuario.

Se desaconseja el uso del correo electrónico para enviar datos de tarjetas de crédito, ya que el correo electrónico no es un método seguro de transferencia de información, de modo que los usuarios que entran en la cola mediante correo electrónico probablemente completen su compra haciendo uso de otro punto de venta.

Opcionalmente, el correo electrónico puede contener también un código de confirmación que el cliente puede introducir en el sistema basado en teléfono.

Por conveniencia, las realizaciones del sistema pueden ser utilizadas en minoristas físicos (taquillas, tiendas, etc.). En este sistema, se prevé que el personal del minorista tenga acceso a Internet o teléfono, e introduzca a su nombre los detalles del cliente en la versión apropiada del sistema de colas de la invención.

Además del número de petición, el servidor web puede emitir un código de confirmación y entregarlo al cliente, quien debe usar el código, además del número de petición emitido, para tener acceso a su lugar en la cola.

Si es factible, se deben utilizar los últimos cuatro dígitos de la tarjeta de crédito del cliente, u otra información personal, para generar el código de confirmación, de manera que se puede comprobar más tarde.

El cliente puede utilizar el número de petición y el código de confirmación para acceder a su lugar en la cola a través de otros puntos de venta, en caso de que decida no volver al minorista para comprar el producto (este escenario se discutirá con mayor detalle más adelante).

Por otro lado, si los clientes desean completar la compra a través del minorista, volverían con el código de confirmación y el número de petición, y toda la información personal suministrada. A continuación, el minorista puede completar la venta en su nombre a través del sistema de cola, o bien puede completar la venta utilizando los equipos de punto de venta existentes. En este último caso, se debe notificar la venta al sistema de cola, para facilitar el cierre automático de la cola (de este modo, por ejemplo, todos los números de petición, números de teléfono y códigos de confirmación serán enviados a un servidor de cola por Internet).

En ventas en donde el ritmo de venta llega a ser inferior a la tasa de incremento durante un cierto período de tiempo, de modo que los nuevos clientes deberían pasan a través de la cola de manera inmediata y transparente, el sistema de cola puede notificar a los minoristas de este hecho, para que, en lugar de ayudar a los nuevos clientes a entrar en la cola, se limiten a vender el producto.

Téngase en cuenta que si se utiliza dinero en metálico para comprar las entradas, entonces se necesita otra información personal para prevenir el fraude, si se desea.

Los escenarios descritos en lo que antecede no son los únicos casos en los que un cliente puede entrar en la cola utilizando un punto de venta, y comprar las entradas, servicios, etc. utilizando otro punto de venta. Los ejemplos específicos incluyen hacer cola por Internet y comprar por teléfono; hacer cola por teléfono y comprar por Internet; y hacer cola por correo electrónico y comprar por otros medios.

Téngase en cuenta que si se adopta una solución integrada, se recomienda el uso de códigos de confirmación para evitar que haya personas que introduzcan de manera fraudulenta el número de teléfono de otra persona en el sistema.

En todos los casos Integrados, una vez que el cliente ha comprado el producto a través de un punto de venta, se puede notificar a los servidores que manejan la cola para otros puntos de venta, con el fin de evitar compras adicionales (por ejemplo, para evitar la compra múltiple por revendedores de entradas).

En el escenario en donde los clientes hacen cola por Internet y compran a través del teléfono, un cliente entra en la cola en línea mediante el sistema ya discutido. En la página de la cola, al cliente se le ofrece la opción de comprar entradas por teléfono. El cliente introduce su número de teléfono, y éste se almacena junto con su número de petición, y se transmite al servidor de cola telefónica.

Si en el servidor de cola telefónica se utiliza la correspondencia "de muchos a uno", entonces se debe generar y proporcionar al cliente un código de confirmación, y enviarlo al servidor de cola telefónica.

Cuando el cliente llama después a la línea telefónica directa ("hotline", en inglés), los datos necesarios ya están presentes en la base de datos del servidor de cola telefónica, y el cliente es tratado como "reconocido".

Si se utiliza también un punto de venta por SMS, sólo se necesita que el servidor de cola por Internet envíe la información al servidor de cola por SMS para que el cliente sea tratado de manera similar.

En el escenario en el cual el cliente hace cola por teléfono y compra por Internet, dicho cliente entra en la cola utilizando el sistema de cola telefónica tal como se ha discutido, y se le asigna un número de petición y (opcionalmente) un código de confirmación. El número de teléfono, el número de petición y (si existe) el código de confirmación son enviados al servidor de cola por Internet, donde se almacenan en una base de datos. A continuación, el cliente se conecta a Internet y contacta con el servidor de cola por Internet.

Como el servidor de cola por Internet no tiene forma de reconocer de forma automática a este cliente, al cliente se le asigna un segundo número de petición, y éste se muestra en la página de cola. Dado que el cliente entró primeramente en la cola telefónica, el nuevo número de petición será por lo general superior al número de petición original obtenido por teléfono.

En la página de cola existe una opción para las personas que ya se hayan unido a la cola por teléfono para que utilicen su número de petición emitido por teléfono. Los clientes que seleccionen esta opción introducirán el número de petición que recibieron por teléfono, su número de teléfono y (si existe) su código de confirmación. Si no se encuentra un registro coincidente, se elimina cualquier número de petición u otra información de cola almacenada en el terminal de cliente, y se sobrescriben con la información hallada en la base de datos. A continuación, el cliente puede proceder a través de una cola por Internet como antes.

Como alternativa, a los clientes que llegan a Internet después de haber llamado al sistema telefónico se les puede dar la opción de introducir su número de teléfono antes de que se emita un número de petición por Internet.

Dado que el servidor de cola por SMS proporciona al cliente la misma información que al servidor de cola telefónica, el mismo mecanismo puede permitir también a los clientes que se hayan unido por teléfono a la cola que compren sus entradas por SMS (y viceversa), o bien permitir a los clientes que se hayan unido a la cola por SMS que compren producto en línea (y viceversa).

Otro ejemplo es el cual se entra en la cola en un medio y el punto de venta se encuentra en otro medio se produce cuando la entrada en la cola se hace por correo electrónico y la compra se realiza a través de otros medios. Como se ha dicho, el correo electrónico no es un medio seguro de transmitir información de tarjeta de crédito. Por lo tanto, se debe utilizar algún otro medio. Se puede dirigir por correo electrónico a los clientes que entran en la cola para que accedan a la cola de internet; desde allí, dichos clientes pueden continuar a cualquiera de los otros puntos de venta.

La Figura 5 muestra una posible configuración de flujo de clientes en el sistema de cola de la invención. La figura se ajusta a la conocida especificación de Diagrama de Actividad UML (Lenguaje de Modificación Unificado, por sus siglas en inglés). En esta representación técnica, los estados iniciales (Cliente nuevo, Cliente que regresa) están marcados como puntos negros llenos. Los estados finales están marcados como puntos negros llenos con un círculo alrededor (Cliente puesto en cola, Pedido cumplimentado). Las acciones y estados se representan como rectángulos redondeados. Las decisiones se representan como rombos y los flujos (al término de las acciones o como resultado de las decisiones) se representan mediante flechas. Por último, las flechas discontinuas representan acciones opcionales del usuario.

El sistema se divide en tres "calles de natación": cliente, servidor de cola y sistema de pago, que representan a diferentes actores (es decir, componentes) del sistema en su conjunto. La Figura se aplica tanto a la realización por Internet como a la realización telefónica del sistema de cola descrito más arriba, como se apreciará al leer la siguiente descripción.

Para el sistema por Internet, Cliente representa: el cliente; el navegador del cliente; y el sitio web a través del cual el cliente efectúa la elección de producto. Sistema de pago representa una pasarela de pago responsable de adquirir y procesar información de tarjeta de crédito. Servidor de cola representa el servidor de cola por Internet.

Para el sistema telefónico, Cliente representa el cliente y el teléfono del cliente. Sistema de pago corresponde a un centro de llamadas, sus operadores y programas informáticos asociados. Servidor de cola representa el servidor de cola telefónica.

Clientes 502 nuevos entran en el sistema y eligen un producto 510, ya sea a través de un sitio web, o bien llamando a un número de teléfono, o en algunos casos mediante el envío de un mensaje de texto o un correo electrónico. Opcionalmente, se les puede pedir que introduzcan 512 información personal adicional, que puede ser utilizada como información de seguridad posteriormente (por ejemplo, las últimas cuatro cifras de la tarjeta de crédito que utilizarán para completar la compra), o para algún otro propósito.

Una vez recopilada esta información, los clientes son reenviados 520 al servidor de cola. Como el cliente es nuevo, la elección del producto y cualquier otra información recopilada se almacena 524 (en una base de datos del servidor de cola en el caso del sistema telefónico, o bien en la máquina del usuario en forma de una cookie en el caso del sistema por Internet). Se genera 526 un nuevo número de petición y se almacena, y se compara 528 con el número de atención en ese momento.

Si el número de petición es menor que el número de atención, se traspasa al cliente al sistema de pago para el procesamiento 546.

Si el número de petición es mayor que el número de atención, entonces se proporciona al cliente información 534 de cola. En el caso de Internet, habitualmente se trata de una página web que muestra el número de petición del cliente, el número de atención en ese momento y un tiempo de espera estimado. En el caso telefónico, esta información se lee al cliente. El cliente está ahora en cola.

Esta respuesta también puede incluir también información que permita al cliente volver al sistema de cola desde otro punto de venta, y ser reconocido 536. Esto varía según el sistema:

•

para el sistema telefónico, la información de reconocimiento es por lo general el número de teléfono del cliente, y puede incluir también el número de petición del cliente y, opcionalmente, un código de confirmación generado automáticamente.

•

para el sistema por Internet, habitualmente no se envía Información de reconocimiento, pero se le puede pedir al cliente que introduzca su número de teléfono si desea comprar el producto por teléfono más tarde. Esta información de reconocimiento se almacena a continuación.

Opcionalmente, el cliente puede pedir que se le notifique cuando llegue al principio de la cola (en concreto, cuando su número de petición se haga menor que el número de atención). En este caso, el cliente introduce 538 su número de teléfono y su dirección de correo electrónico (sólo en el sistema por Internet; en el sistema telefónico su número de teléfono ya es conocido). El sistema de cola espera 540 a que el número de petición del cliente pueda optar al servicio y envía 542 un mensaje de texto SMS y/o un correo electrónico al cliente.

También se pueden enviar mensajes de notificación si se pone a disposición más producto en un momento posterior (no dibujado).

Los clientes que retornan 504 al sistema como consecuencia de haber recibido uno de estos mensajes, o bien por una llamada telefónica posterior, o una actualización automática de página, están representados por el estado inicial marcado como "cliente que regresa".

Los clientes que regresan pueden llegar a través del mismo punto de venta (es decir, ya se han incorporado a la cola a través de Internet, y están regresando a través de Internet), o bien pueden llegar a través de un punto de venta diferente (es decir, se unieron a la cola a través de internet, y están regresando al llamar al teléfono de ayuda).

Dependiendo de los puntos de venta específicos implicados 514, es posible que el cliente tenga que introducir información de reconocimiento para que el sistema recupere el número de petición que el cliente recibió anteriormente 516. En muchos casos, esta información de reconocimiento y el número de petición asociado se pueden recuperar automáticamente.

Una vez que se ha recuperado 530 el número de petición, se comprueba su validez como medida de prevención del fraude 532. Si la información del cliente no satisface la comprobación de validez, se asigna 526 al cliente un nuevo número de petición, y es efectivamente enviado al final de la cola.

Si se recupera y se valida con éxito el número de petición, se compara 528 el número de petición con el número de atención en ese momento. Si el número de petición todavía es mayor que el número de atención, se envía 534 al cliente información actualizada, que incluye un tiempo de espera actualizado.

Si el número de petición es ahora menor que el número de atención, se envía 546 al cliente al sistema de pago para realizar el proceso. Se envía igualmente toda la información recopilada al sistema de pago, donde se puede almacenar o bien se puede procesar.

El sistema de pago puede utilizar esta información para comprobar 548 que el cliente que llega ha pasado a través del sistema de cola. Esto es particularmente importante en Internet, donde se debe tener cuidado de evitar que haya usuarios que lleguen directamente al sistema de pago. El sistema de pago puede realizar esta comprobación por sí mismo, o bien puede enviar un mensaje al servidor de cola pidiendo la validación (no representado).

Cuando se ha validado satisfactoriamente el cliente, el sistema de pago pide 550 al cliente detalles de su tarjeta de crédito. Para proporcionar más protección contra el fraude, se pueden comparar (no representado) estos detalles con la información personal obtenida por el sistema antes de entrar en la cola.

Suponiendo que la información de tarjeta de crédito es procesada satisfactoriamente, se puede notificar 556 al servidor de cola de que la compra ha tenido lugar, a fin de evitar que el mismo cliente compre producto varias veces (esto es particular importante para evitar la reventa de entradas). En ese momento, el pedido ha sido cumplimentado 558.

Como será evidente para el lector, distintas etapas del flujo de clientes descrito en lo que antecede pueden ser omitidas, reemplazadas o aumentadas. Además, existe flexibilidad en cuanto al "actor" donde se realizan muchas de las etapas del diagrama de flujo, y en cuanto al orden en el que son ejecutadas.

En los modelos descritos hasta ahora, se ha supuesto que cada punto de venta, por ejemplo el teléfono o Internet, representa un dominio separado; que hay una asignación separada de entradas a cada punto de venta, y que los números de petición y de atención se incrementan separadamente en cada caso.

Estos supuestos son razonables, y puede que sean efectivamente necesarios en el caso de una venta con gran exceso de peticiones, en donde probablemente la cola de Internet se llenará mucho más rápidamente que la cola telefónica.

Se puede lograr una integración más estrecha en diversas de áreas, en particular números de atención; números de petición y conmutación de dominios.

El número de atención indica cuáles son los clientes que pueden optar a comprar entradas. Típicamente, el número de atención es incrementado al máximo ritmo al cual el anfitrión de servicios de destino puede vender entradas. Es probable que éste sea más rápido en Internet que por teléfono, sobre todo cuando operadores humanos toman los detalles de pago.

En los casos en donde se requiera un único número de atención para todos los puntos de venta, se debería escoger que éste aumentase al ritmo del anfitrión de servicios de destino más lento (normalmente el teléfono).

Los cambios en el número de atención se pueden efectuar utilizando una interfaz administrativa para el sistema de cola, o bien por medio de mensajes generados, como antes, automáticamente y, si se desea, se puede configurar el sistema para propagar estos cambios a todas los demás servidores de cola que gestionan los diferentes puntos de venta.

Los números de petición son asignados generalmente en orden ascendente para un dominio particular (aunque se pueden saltar algunos números). Esto significa que una persona que recibe números de petición a través de una fuente, tal como el teléfono, puede ser capaz de utilizar ese número para entrar en la cola de Internet en un puesto inferior.

Téngase en cuenta que esto no incumple la norma de "primero en llegar, primero en ser atendido", ya que la persona simplemente está utilizando un lugar en la cola, conseguido de manera válida, para comprar entradas por otro medio. Sin embargo, en casos en que se considere esto indeseable por otras razones, se puede proporcionar un mecanismo para sincronizar periódicamente los números de petición entre los dominios o puntos de venta.

Considérese una situación en la que una (única) cola por Internet ha emitido números de petición 1, 2, 3, ... 100, y una cola telefónica ha emitido números 1, 2, 3, ... 10. El servidor de cola telefónica envía un mensaje al servidor de cola por Internet indicando que ha puesto en cola a 10 personas. El servidor de cola por Internet reacciona saltando diez números de petición, de manera que al siguiente nuevo cliente que llegue se le asigna el número de petición

111.

Posteriores mensajes del servidor de cola telefónica indican el número de personas puestas en cola desde que se envió el último mensaje. El servidor de cola por Internet sigue reaccionando saltando ese número de personas.

Cuando están involucrados múltiples puntos de venta, se designa como "realizador de saltos" a un servidor de punto de venta, y los demás envían mensajes de "saltar" a ese servidor. Por lo general, el "realizador de saltos" debe ser el servidor que pone en cola más rápidamente a las personas, y habitualmente éste es el servidor de cola por Internet.

Para mejorar el rendimiento se recomienda que se envíen mensajes de "saltar" sólo como máximo una vez cada diez segundos, pero también es posible, si se desea, enviar mensajes de "saltar" por cada nueva persona puesta en cola.

La Conmutación de dominios se puede beneficiar de la integración. En los casos en que, por ejemplo, se consideren como dominios separados las ventas por Internet y las ventas por teléfono, a los clientes que utilizan el Internet para unirse a la cola y el teléfono para comprar entradas (o viceversa) se les conoce como "personas que conmutan dominio".

Es factible detectar el dominio original que proporcionó el número de petición que se está utilizando para comprar entradas en cualquiera de los servidores, de modo que cuando se venden entradas a personas que cambian de dominio, se actualiza la información correcta de seguimiento de ventas, y no se excluye injustamente de la compra de entradas a personas que ya estaban en el dominio al cual se ha cambiado la persona que cambia de dominio.

En algunas realizaciones, la presente invención puede facilitar - cuando se considere adecuado - la compra de grupos de entradas. A menudo se presenta este caso cuando hay grupos de personas que desean todas ellas acudir al mismo evento. En ventas con gran exceso de peticiones, puede haber dificultades para que todo el grupo reciba entradas. En un sistema convencional, la probabilidad de que todo el grupo pueda comprar entradas viene dada por pn, donde n es el número de personas que constituye el grupo, y p es el número total de entradas disponibles dividido por el número total de personas que las quieren. Por ejemplo, en una situación en la cual hay cuatro veces más personas que quieren acudir que entradas disponibles, la probabilidad de que en un grupo de diez personas todos consigan entrada es de aproximadamente ¡una en un millón!.

Esto puede ocasionar problemas, ya que los miembros del grupo que han recibido entradas pueden decidir más tarde que no desean acudir porque otros miembros del grupo han sido excluidos. Además de la insatisfacción del clientes, esto anima a tales miembros a vender sus entradas (convirtiéndose en revendedores).

Sin embargo, si se utiliza el sistema de cola de la invención, y el grupo se organiza de manera que todos ellos se unan a la cola de manera sustancialmente simultánea, las posibilidades de que el grupo reciba entradas pueden aumentar, aunque no se puede garantizar ese hecho.

Para combatir este problema, se ha desarrollado un subsistema del sistema de colas.

Para utilizar este sistema, los grupos de personas se deben inscribir en el sistema de cola (a través de cualquier punto de venta) antes de que se abra la cola (generalmente, cuando se ponen a la venta las entradas).

Al primer miembro del grupo en registrarse se le asigna, o bien lo elige él, un código de grupo único, que dicha persona comunica al resto del grupo.

Los miembros posteriores del grupo introducen después este Código de grupo en el sistema cuando se inscriben.

También se recoge información personal, por ejemplo los cuatro últimos números de la tarjeta de crédito de cada miembro, cuando se inscriben los miembros del grupo, para evitar que se puedan intercambiar los sitios dentro del grupo. Si se desea, se puede limitar el tamaño máximo del grupo.

Cuando se abre la cola, todos los miembros del grupo deben intentar unirse tan pronto como sea posible, con el fin de que el grupo tener la máxima probabilidad de recibir entradas.

Al primer miembro del grupo en unirse a la cola se le asigna un número de petición como en los casos anteriores.

A los posteriores miembros del grupo que se unen a la cola se les asigna el mismo número de petición.

Cuando este número de petición cumple los requisitos para ser atendido, todos los miembros del grupo deben completar su compra antes que se agoten las entradas, como en los casos anteriores.

Si se utiliza Internet para unirse a la cola, es posible hacer que el sistema, a través del uso de cookies u otras tecnologías de almacenamiento (tales como marcadores/favoritos) reconozca a los miembros del grupo a medida que se unen a la cola.

Si se utilizan otros puntos de venta, puede que los miembros tengan que volver a introducir su código de grupo para ser reconocidos. Opcionalmente, para desalentar el uso fraudulento, se puede pedir que los miembros vuelvan a introducir su información personal además del código de grupo.

Nótese que esto puede violar la definición más estricta de "primero en llegar, primero en ser atendido", y los grupos grandes pueden resultar favorecidos frente a los más pequeños. Sin embargo, en las colas físicas, es habitual que las personas guarden puestos para sus amigos, de forma que esta práctica puede ser considerada aceptable.

La discusión que antecede se ha centrado principalmente en aplicaciones del sistema de la invención para ventas con carga elevada. El sistema se puede aplicar también a la gestión de colas basada en error. Aunque la mayoría de los negocios en línea no venden entradas, todos los negocios en línea utilizan tecnologías similares para facilitar la compra de productos (bienes o servicios). La solución de gestión de colas que se ha presentado se puede utilizar también para evitar la pérdida de negocios cuando estas tecnologías fallan.

En particular, la mayoría de los negocios en línea utilizan un servidor web para presentar las páginas web, una base de datos para almacenar información del producto y del pedido, una pasarela de pago para procesar datos de tarjeta de crédito, y (habitualmente) un servidor de aplicaciones para integrar estos subsistemas.

Surgen problemas cuando falla uno cualquiera de estos subsistemas, o todos. Por ejemplo, si no está disponible una pasarela de pago, tal vez a causa de un reinicio del servidor, o reinicio del componente físico, o fallo de la red, o cualquier otra razón, las personas se ven incapacitadas para realizar las compras, aunque el resto del sistema puede estar funcionando correctamente. Análogamente, si el servidor de base de datos no funciona, los clientes tampoco podrán cursar pedidos.

En estas circunstancias, los clientes frustrados comprarán a menudo productos de otros proveedores, y es improbable que vuelvan al sitio web que perciben como defectuoso. Por lo tanto, incluso una operación de mantenimiento rutinaria, que puede dejar sin funcionar un componente del sistema sólo durante un minuto o dos, puede provocar una pérdida permanente.

El sistema de la invención aborda estos problemas. En primer lugar, cuando falla un componente de un sitio de comercio electrónico, a los usuarios se les presenta normalmente algún tipo de mensaje de error. El mensaje específico que se muestre dependerá del componente que esté fallando y del resto de la arquitectura del sitio de comercio electrónico, pero habitualmente los administradores del sitio tienen control sobre el mensaje que se muestra.

En pocas palabras, los administradores del sitio utilizan el sistema de cola para reemplazar el mensaje de error (que se generaría habitualmente para el cliente) por instrucciones para enviar al cliente al servidor de cola. El sistema de colas responde colocando al cliente en una cola. Todos los clientes posteriores son mantenidos en esta cola hasta se soluciona el problema, momento en el cual son devueltos al anfitrión de servicios de destino a un ritmo que pueda aceptar.

El mecanismo para ello es el siguiente.

En primer lugar, cuando el cliente es enviado al servidor de cola (por ejemplo, a través de JavaScript, un encabezado de redirección HTTP o por cualquier otro medio), la redirección contiene la siguiente información:

1)

Información acerca del tipo de error original (normalmente un código de error),

2)

Una URL de destino para enviar a los clientes una vez que se solucione el error,

3)

Una URL de prueba que se utilizada para determinar si se ha solucionado el problema,

4)

Un tiempo de retardo,

5)

Una dirección de correo electrónico y/o número de teléfono de los administradores del sitio, y/o

6)

Cualquier información adicional requerida por los administradores del sitio.

Cualquiera de estas informaciones, o todas, pueden haber sido previamente configuradas por los administradores del sitio a valores por defecto, y después pueden ser omitidas en el correo electrónico de redirección. Toda esta información se almacena utilizando los procesos descritos en lo que antecede.

Al recibir el primer cliente de un sitio que falla, el servidor de cola envía un correo electrónico y/o un mensaje de texto SMS a los administradores del sitio indicando que se ha producido un problema que necesita solución. En este mensaje se puede incluir un código de error.

A continuación, el servidor de cola asigna al cliente un número de petición, y muestra una página de cola como antes. Se inicia un temporizador. A los clientes posteriores que llegan a causa del fallo se les asignan números de petición adicionales y son unidos a la cola como en casos anteriores. La página de cola es configurable, de modo que los administradores del sitio tienen control sobre todos los mensajes que se muestran.

Cuando el temporizador ha llegado al tiempo de retardo, el siguiente cliente en llegar a los servidores de cola (sea como una nueva llegada, sea como un cliente que ya está en cola y cuya página se está refrescando automáticamente) es etiquetado por el sistema como un "usuario de prueba" ("tester", en inglés), mediante el uso de una cookie persistente u otro medio. Se envía al "usuario de prueba" a la URL de prueba, que es una página web dentro del anfitrión de servicios de destino (una página web que no está disponible debido a un error o fallo en un componente del sistema de comercio electrónico). También se envía al anfitrión de servicios de destino, junto con esta petición, la información almacenada cuando el usuario de prueba se unió a la cola. En el servidor de cola se inicia otro temporizador.

El anfitrión de servicios de destino utiliza la información enviada para probar si el componente que falló está funcionando ahora. El anfitrión de servicios de destino puede hacer esto, por ejemplo, reconstruyendo la petición original que dio lugar al error, y procesándola de nuevo.

Si se produce de nuevo el error, se devuelve inmediatamente al cliente al servidor de cola.

Si no se vuelve a producir error, el anfitrión de servicios de destino indica que el problema ha sido solucionado:

o bien mediante el envío de un mensaje directamente al servidor de cola,

o bien haciendo que el navegador web del cliente solicite una URL especial desde el servidor de cola que indique que el problema ha sido solucionado,

o bien no devolviendo al usuario de prueba al servidor de cola, el cual detecta la falta del usuario de prueba al cabo de cierto tiempo.

Si se sigue produciendo el error, el servidor de cola elimina la información que distingue al usuario de prueba del resto de los clientes, y continúa reteniendo a todos los clientes durante otro período prefijado de tiempo, repitiendo después el proceso.

Sin embargo, cuando se ha solucionado el error, el usuario de prueba es enviado a la URL de destino, ya sea por el anfitrión de servicios de destino o bien (opcionalmente) por el servidor de cola, y también se remiten los demás clientes de la cola a través de la URL de destino como antes, hasta que no quede ninguno en la cola, y se envía un correo electrónico o mensaje de texto SMS a los administradores del sitio indicando que el problema ha sido solucionado.

Si se vuelve a producir el error durante este proceso, se envía como antes el cliente que sufre el error al servidor de cola, que responde reteniendo de nuevo todos los clientes en cola hasta que se corrija el error, utilizando el mecanismo de prueba anteriormente descrito.

Opcionalmente, los administradores del sitio pueden especificar también a los servidores de cola que el problema ha sido solucionado de forma manual, sin pasar por la prueba automática.

Opcionalmente, también se pueden configurar los servidores de colas para enviar peticiones al anfitrión de servicios de destino al objeto de que realice directamente las pruebas, en lugar de enviar clientes a la URL de prueba como se ha descrito antes.

Por tanto, el sistema de cola de la invención pueden ser desplegado para hacer frente a problemas en la gestión de colas tanto por Internet como telefónicamente, en donde cargas elevadas, la gestión de múltiples puntos de venta, y/o fallos del sistema provocan ineficiencias y/o fallos, proporcionando así una reducción de riesgos y costes a los administradores del sitio y una experiencia muy mejorada a los clientes. Además, el sistema de gestión de cola se ocupa de problemas relacionados con revendedores de entradas, cancelaciones y venta de entradas a grupos. Sin embargo, la invención no se limita a aplicaciones en el comercio electrónico y la telefonía, sino que abarca la gestión de colas de peticiones de servicios y/o productos en cualquier red de comunicaciones.

Además, aunque muchos de los ejemplos específicos que se han ofrecido en lo que antecede se refieren a sistemas de gestión de colas para la compra de entradas, será evidente que la invención no se limita a estos ejemplos específicos. La invención puede emplearse igualmente en la gestión de colas para la compra de productos y/o servicios. La invención también se aplica a la gestión de colas de usuarios cuando el acceso a un servicio se ve imposibilitado por un fallo o mal funcionamiento, en lugar de porque la demanda supere a la capacidad.

Claims (58)

1. REIVINDICACIONES

   1. Un método para gestionar peticiones de servicio a un anfitrión (22) de servicios a través de una red telefónica de

   comunicaciones, el cual método comprende los pasos de: recibir (502) desde un terminal (20) de cliente, a través de la red telefónica de comunicaciones, una petición de servicio a suministrar por el anfitrión (22) de servicios;

   asignar (526) un identificador de cola a la petición de servicio;

   recibir (504) desde el terminal de cliente una posterior petición de servicio a suministrar por el anfitrión (22) de servicios; recuperar (530) el identificador de cola para la petición de servicio; realizar (528) una comparación entre el identificador de cola e información de estado de la cola; y traspasar (546) al anfitrión (22) de servicios la petición de servicio en función del resultado de la comparación, caracterizado porque los pasos del método se realizan en un servidor (30, 520) de cola y el paso de asignar (526) el

   identificador de cola a la petición de servicio se realiza con independencia de que la petición de servicio cumpla en ese momento los requisitos para ser atendida por el anfitrión (22) de servicios.

2. 2.

   Un método según la reivindicación 1, en donde el identificador de cola se almacena en una base de datos y se asocia con un número de teléfono de la terminal (20) de cliente.

3. 3.

   Un método según la reivindicación 2, en donde el identificador de cola se recupera (530) de la base de datos después de la posterior petición de servicio.

4. 4.

   Un método según cualquiera de las reivindicaciones precedentes, en donde el paso de traspasar (546) al anfitrión de servicios la petición de servicio comprende conectar una llamada desde el terminal (20) de cliente al anfitrión (22) de servicios.

5. 5.

   Un método según cualquiera de las reivindicaciones precedentes, que comprende además el paso de realizar

   (528) una comparación inicial entre el identificador de cola e información de estado de la cola después de que se ha asignado (526) el identificador de cola a la petición de servicio.

6. 6.

   Un método según la reivindicación 5, que comprende además el paso de notificar (534) al terminal (20) de cliente que la petición ha sido puesta en cola después de realizar la comparación inicial.

7. 7.

   Un método según la reivindicación 6, que comprende además el paso de proporcionar (534) al terminal (20) de cliente acceso al identificador de cola.

8. 8.

   Un método según la reivindicación 7, en donde con el acceso al identificador de cola se proporciona al terminal

   (20) de cliente acceso a información específica.
9. 9. Un método para gestionar peticiones de servicio a un anfitrión (22) de servicios a través de una red de

   comunicaciones por Internet, el cual método comprende los pasos de: recibir (502) desde un terminal (20) de cliente, a través de la red de comunicaciones por Internet, una petición de servicio a suministrar por el anfitrión (22) de servicios;

   asignar (526) un identificador de cola a la petición de servicio; proporcional (534) al terminal (20) de cliente acceso al identificador de cola; recibir (504) del terminal de cliente el identificador de cola como parte de una posterior petición de servicio a

   suministrar por el anfitrión (22) de servicios; realizar (528) una comparación entre el identificador de cola e información de estado de la cola; y traspasar (546) al anfitrión (22) de servicios la petición de servicio en función del resultado de la comparación, caracterizado porque los pasos del método se realizan en un servidor (30, 520) de cola y el paso de asignar (526) el

   identificador de cola a la petición de servicio se realiza con independencia de que la petición de servicio cumpla en ese momento los requisitos para ser atendida por el anfitrión (22) de servicios.

10. 10.

    Un método según la reivindicación 9, en donde el paso de traspasar (546) al anfitrión (22) de servicios la petición de servicio comprende proporcionar al terminal (20) de cliente acceso a una página de destino en el anfitrión (22) de servicios.

11. 11.

    Un método según la reivindicación 9 o la reivindicación 10, en donde después de que se ha asignado un identificador de cola a una petición de servicio pero antes de proporcionar al terminal (20) de cliente acceso al identificador de cola, se realiza una comparación inicial entre el identificador de cola e información de estado de la cola y se traspasa al anfitrión (22) de servicios la petición de servicio en función del resultado de la comparación inicial.

12. 12.

    Un método según una cualquiera de las reivindicaciones 9 a 11, en donde con el acceso al identificador de cola se proporciona al terminal (20) de cliente acceso a información específica.

13. 13.

    Un método según una cualquiera de las reivindicaciones 7 a 12, que comprende además el paso de proporcionar al terminal (20) de cliente acceso a información adicional referente a la cola.

14. 14.

    Un método según la reivindicación 13, en donde la información adicional incluye un número de atención, siendo el número de atención una indicación del identificador de cola que está siendo atendido en ese momento.

15. 15.

    Un método según la reivindicación 14, en donde el número de atención es incrementado automáticamente a una tasa constante.

16. 16.

    Un método según la reivindicación 14, en donde el número de atención es incrementado automáticamente, haciéndose variar la tasa de incremento en función del número de peticiones de servicio traspasadas al anfitrión (22) de servicios.

17. 17.

    Un método según la reivindicación 14, en donde el número de atención es incrementado en respuesta a mensajes procedentes del anfitrión (22) de servicios.

18. 18.

    Un método según cualquiera de las reivindicaciones precedentes, en donde el identificador de cola es un número y es asignado sobre una base secuencial.

19. 19.

    Un método según cualquiera de las reivindicaciones precedentes, que incluye además el paso de comprobar

    (548) en el anfitrión de servicios que la petición de servicio ha sido traspasada desde el servidor (30, 520) de cola.

20. 20.

    Un método según cualquiera de las reivindicaciones precedentes, que incluye además el paso de, después de la prestación de servicio por el anfitrión (22) de servicios, eliminar automáticamente del terminal (20) de cliente el identificador de cola y cualquier cadena cifrada.

21. 21.

    Un método según cualquiera de las reivindicaciones precedentes, en donde una pluralidad de servidores (42) de cola reciben peticiones de servicio, que comprende además el paso de asignar la petición de servicio desde el terminal (44) de cliente a un servidor (42) de cola en particular de acuerdo con una fórmula predeterminada.

22. 22.

    Un método según cualquiera de las reivindicaciones precedentes, en donde el identificador de cola corresponde a una de una pluralidad de colas.

23. 23.

    Un método según la reivindicación 22, que comprende además equilibrar la carga (43) de clientes entre las colas.

24. 24.

    Un método según la reivindicación 22 o la reivindicación 23, en donde cada cola corresponde a un dominio dado dentro de la red de comunicaciones.

25. 25.

    Un método según la reivindicación 24, en donde cada dominio corresponde a una zona geográfica.

26. 26.

    Un método según la reivindicación 24 o la reivindicación 25, que comprende además los pasos de:

    inquirir al terminal de cliente un identificador de dominio;

    recibir el identificador de dominio desde el terminal de cliente; y

    después de que se ha traspasado al anfitrión de servicios la petición de servicio, comprobar que el identificador de dominio corresponde a información de dominio proporcionada posteriormente por el terminal de cliente cuando se ha traspasado al anfitrión de servicios la petición de servicio.

27. 27.

    Un método según cualquiera de las reivindicaciones precedentes, que comprende además el paso de:

    recibir una petición adicional de servicio desde un terminal de cliente adicional a través de la red de comunicaciones, siendo el terminal de cliente adicional de un tipo distinto al terminal (20) de cliente.

28. 28.

    Un método según cualquiera de las reivindicaciones precedentes, en donde el terminal (20) de cliente es operado por un usuario, el cual método comprende además los pasos de:

    asociar un identificador de cliente a cada usuario;

    recibir el identificador de cliente desde el usuario; y

    validar el identificador de cliente, confirmando así que el usuario es un cliente que retorna.

29. 29.

    Un método según la reivindicación 28, en donde el identificador de cliente es un identificador de terminal de cliente que identifica a un terminal (20) de cliente dado, y en donde el paso de validar el identificador de cliente incluye comprobar si un terminal de cliente adicional, desde el cual se ha recibido una petición de servicio, concuerda con el identificador de terminal de cliente previamente asignado.

30. 30.

    Un método según la reivindicación 28 o la reivindicación 29, en donde el paso de asociar el identificador de cliente a cada usuario incluye mantener una base de datos de cola de identificadores de cliente, y en donde el paso de validar el identificador de cliente incluye comparar el identificador de terminal de cliente para el terminal (20) de cliente con cada uno de los registros de la base de datos de cola y, cuando el terminal (20) de cliente concuerda con un registro de la base de datos de cola, confirmar que el usuario es un cliente que retorna.

31. 31.

    Un método según la reivindicación 28 o la reivindicación 29, en donde el paso de asociar el identificador de cliente a cada usuario incluye obtener información adicional de identificación de cliente, y en donde el paso de validar el identificador de cliente incluye validar el identificador de cliente frente a la información adicional de cliente.

32. 32.

    Un método según una cualquiera de las reivindicaciones 28 a 31, en donde el paso de asociar el identificador de cliente al usuario incluye:

    recibir información de cliente desde el usuario;

    generar un código de confirmación único para el usuario utilizando la información de cliente; y

    asignar el código de confirmación al usuario.

33. 33.

    Un método según la reivindicación 32, en donde el identificador de cliente recibido desde el terminal de cliente incluye el código de confirmación y en donde el paso de validar el identificador de cliente incluye comprobar si el código de confirmación es un código de confirmación válido, permitiendo así a una pluralidad de clientes utilizar el mismo terminal (20) de cliente.

34. 34.

    Un método según cualquiera de las reivindicaciones precedentes, que comprende además el paso de notificar

    (534) al cliente cuando el resultado de la comparación entre el identificador de cola y la información de estado de la cola indica que la petición de servicio debe ser traspasada al anfitrión (22) de servicios.

35. 35.

    Un método según una cualquiera de las reivindicaciones precedentes, en donde la información de estado de la cola indica si cualquiera de los subsistemas del anfitrión (22) de servicios, o todos, han fallado.

36. 36.

    Un método según una cualquiera de las reivindicaciones precedentes, que comprende además los pasos de:

    antes del paso de comparación (534), alterar la información de estado de la cola para indicar que el servicio solicitado se ha agotado, de modo que se evita que la petición de servicio sea traspasada al anfitrión (22) de servicios; y

    cuando el servicio solicitado está disponible, alterar la información de estado de la cola para indicar si se debe traspasar al anfitrión (22) de servicios la petición de servicio.

37. 37.

    Un producto de programa de ordenador que tiene código ejecutable por ordenador almacenado en el mismo para hacer que un ordenador ejecute el método según cualquiera de las reivindicaciones precedentes cuando es ejecutado por el ordenador.

38. 38.

    Un sistema para gestionar peticiones de servicio procedentes de un terminal (20) de cliente a un anfitrión (22) de servicios a través de una red telefónica de comunicaciones, el cual sistema comprende un servidor (30, 520) para recibir desde el terminal (20) de cliente a través de la red telefónica de comunicaciones una petición de servicio a suministrar por el anfitrión (22) de servicios, en donde el servidor incluye:

    medios para recibir (502) una petición de servicio desde el terminal (20) de cliente;

    medios para asignar (526) un identificador de cola a la petición de servicio;

    medios para generar información de estado de la cola;

    medios para recuperar (530) el identificador de cola después de una posterior petición de servicio desde el terminal

    (20) de cliente;

    medios para realizar una comparación (528) entre la información de estado de la cola y el identificador de cola; y

    medios para traspasar (546) la petición de servicio al anfitrión de servicios en función del resultado de la

    comparación,

    caracterizado porque el servidor es un servidor (30, 520) de cola y los medios para asignar (526) el identificador de cola a la petición de servicio están adaptados para asignar (526) el identificador de cola con independencia de que la petición de servicio cumpla en ese momento los requisitos para ser atendida por el anfitrión (22) de servicios.

39. 39.

    Un sistema según la reivindicación 38, que comprende además medios para almacenar el identificador de cola en una base de datos por cuenta del terminal (20) de cliente y en donde los medios para recuperar (530) el identificador de cola lo recuperan de la base de datos.

40. 40.

    Un sistema según la reivindicación 38 o la reivindicación 39, en donde los medios para traspasar la petición de servicio están adaptados para conectar una llamada desde el terminal (20) de cliente al anfitrión (22) de servicios.

41. 41.

    Un sistema según una cualquiera de las reivindicaciones 38 a 40, en donde los medios para realizar una comparación (528) están adaptados, en uso, para realizar una comparación inicial entre el identificador de cola e información de estado de la cola después de que el medio de asignación (526) haya asignado el identificador de cola a la petición de servicio.

42. 42.

    Un sistema según la reivindicación 41, que comprende además medios para notificar (534) al terminal (20) de cliente que la petición ha sido puesta en cola después de realizar la comparación inicial.

43. 43.

    Un sistema según una cualquiera de las reivindicaciones 38 a 42, que comprende además medios para proporcionar (534) al terminal (20) de cliente acceso al identificador de cola.

44. 44.

    Un sistema para gestionar peticiones de servicio desde un terminal (20) de cliente a un anfitrión (22) de servicios a través de una red de comunicaciones por Internet, el cual sistema comprende un servidor (30, 520) para recibir desde el terminal (20) de cliente, a través de la red de comunicaciones por Internet, una petición de servicio a suministrar por el anfitrión (22) de servicios, el cual servidor incluye:

    medios para recibir (502) una petición de servicio desde el terminal (20) de cliente;

    medios para asignar (526) un identificador de cola a la petición de servicio;

    medios para proporcionar (534) al terminal (20) de cliente acceso al identificador de cola;

    medios para generar información de estado de la cola;

    medios para recibir (530) el identificador de cola como parte de una posterior petición de servicio desde el terminal

    (20) de cliente;

    medios para realizar una comparación (528) entre la información de estado de la cola y el identificador de cola; y

    medios para traspasar (546) la petición de servicio al anfitrión (22) de servicios en función del resultado de la comparación,

    caracterizado porque el servidor es un servidor (30, 520) de cola y los medios para asignar (526) el identificador de cola a la petición de servicio están adaptados para asignar (526) el identificador de cola con independencia de que la petición de servicio cumpla en ese momento los requisitos para ser atendida por el anfitrión (22) de servicios.

45. 45.

    Un sistema según la reivindicación 44, en donde los medios para traspasar la petición de servicio están adaptados para proporcionar al terminal (20) de cliente acceso a una página de destino en el anfitrión (22) de servicios.

46. 46.

    Un sistema según la reivindicación 44 o la reivindicación 45, en donde, en uso, después de que se ha asignado un identificador de cola a la petición de servicio, pero antes de proporcionar al terminal (20) de cliente acceso al identificador de cola, los medios para realizar una comparación (528) están adaptados para realizar una comparación inicial entre el identificador de cola e información de estado de la cola, y los medios para traspasar

    (546) la petición de servicio al anfitrión (22) de servicios están adaptados para hacerlo en función del resultado de la comparación inicial.

47. 47.

    Un sistema según la reivindicación 46, que comprende además medios para notificar (534) al terminal (20) de cliente que la petición ha sido puesta en cola después de realizar la comparación inicial.

48. 48.

    Un sistema según una cualquiera de las reivindicaciones 43 a 47, en donde los medios para proporcionar al terminal (20) de cliente acceso al identificador de cola están adaptados para proporcionar (534) al terminal (20) de cliente, con el identificador de cola, acceso a información adicional referente a la cola.

49. 49.

    Un sistema según la reivindicación 48, en donde la información adicional incluye un número de atención, siendo el número de atención una indicación del identificador de cola que está siendo atendido en ese momento.

50. 50.

    Un sistema según la reivindicación 49, en donde, en uso, el servidor (30, 520) de cola incrementa automáticamente el número de atención a una tasa constante.

51. 51.

    Un sistema según la reivindicación 49, en donde, en uso, el servidor (30, 520) de cola incrementa el número de

    servicio automáticamente, siendo modificada la tasa de incremento en función del número de peticiones de servicio 5 enviadas al anfitrión (22) de servicios.

52. 52.

    Un sistema según una cualquiera de las reivindicaciones 43 a 51, en donde los medios para proporcionar (534) al terminal (20) de cliente acceso al identificador de cola están adaptados para proporcionar al terminal (20) de cliente, con el identificador de cola, acceso a información específica.

53. 53.

    Un sistema según una cualquiera de las reivindicaciones 43 a 52, en donde la posterior petición de servicio

    10 desde el terminal (20) de cliente es iniciada de forma automática por código enviado al terminal (20) de cliente cuando se proporciona acceso al identificador de cola.
54. 54. Un sistema según una cualquiera de las reivindicaciones 38 a 53, en donde los identificadores de cola son números y se asignan sobre una base secuencial.
55. 55. Un sistema según una cualquiera de las reivindicaciones 38 a 54, que incluye además medios para comprobar 15 en el anfitrión (22) de servicios que la petición de servicio ha sido traspasada desde el servidor (30, 520) de cola.

56. 56.

    Un sistema según una cualquiera de las reivindicaciones 38 a 55, que incluye además medios para, después de la prestación de servicio por el anfitrión (22) de servicios, eliminar automáticamente del terminal (20) de cliente el identificador de cola y cualquier cadena cifrada.

57. 57.

    Un sistema según una cualquiera de las reivindicaciones 38 a 56, que comprende además medios para rechazar

    20 automáticamente peticiones de servicio después de que se hayan traspasado al anfitrión (22) de servicios un número predeterminado de peticiones de servicio.
58. 58. Un sistema según una cualquiera de las reivindicaciones 38 a 57, que comprende una pluralidad de servidores

    (42)

    de cola, y medios para asignar peticiones de servicio procedentes de terminales (44) de cliente a un servidor

    (42)

    de cola particular de acuerdo con una fórmula predeterminada.