WO2004098215A1 - Sistema multicliente/multiconversación para la realización de transacciones económicas y/o acceder a información mediante mensajes sms - Google Patents

Sistema multicliente/multiconversación para la realización de transacciones económicas y/o acceder a información mediante mensajes sms Download PDF

Info

Publication number
WO2004098215A1
WO2004098215A1 PCT/ES2003/000192 ES0300192W WO2004098215A1 WO 2004098215 A1 WO2004098215 A1 WO 2004098215A1 ES 0300192 W ES0300192 W ES 0300192W WO 2004098215 A1 WO2004098215 A1 WO 2004098215A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
messages
message
entity
client
Prior art date
Application number
PCT/ES2003/000192
Other languages
English (en)
French (fr)
Inventor
Luis Uguina Carrión
Original Assignee
Bankinter S.A
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bankinter S.A filed Critical Bankinter S.A
Priority to EP03720593A priority Critical patent/EP1624706A1/en
Priority to US10/554,729 priority patent/US20070094111A1/en
Priority to PCT/ES2003/000192 priority patent/WO2004098215A1/es
Priority to AU2003224181A priority patent/AU2003224181A1/en
Publication of WO2004098215A1 publication Critical patent/WO2004098215A1/es

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/325Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • G06Q20/3255Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks using mobile network messaging services for payment, e.g. SMS
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00Computer-aided design [CAD]
    • G06F30/30Circuit design
    • G06F30/36Circuit design at the analogue level
    • G06F30/373Design optimisation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/58Message adaptation for wireless communication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12Messaging; Mailboxes; Announcements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18Service support devices; Network management devices
    • H04W88/184Messaging devices, e.g. message centre

Definitions

  • the present invention relates to a multi-client / multi-conversation system for conducting economic transactions and / or accessing information via SMS messages, which provides essential novelty features and notable advantages over known and used means for the same purposes in the Current state of the art.
  • the invention proposes the development of a system for carrying out operations by using short SMS messages, with a multiplicity of capabilities implemented that ensure operations between, for example, a financial entity and a specific customer or user, of easy and comfortable way, and with a high level of security.
  • the system is configured according to two operating modes, so that the conversation can be initiated by both the client and the entity, by sending a message, and in the latter case admitting two alternatives corresponding to the start of the conversations on the initiative of the entity, or they are activated when a certain event occurs.
  • the system also provides for the provision of confidential information with the use of some type of security key that identifies the user.
  • the scope of the invention is within the telecommunications sector in general, and in particular the interaction between an entity (for example, a Bank), and the clients of the entity.
  • entity for example, a Bank
  • the present invention belongs precisely to the sector mentioned above, and proposes the implementation of a system through which economic transactions can be made between an entity, for example a Bank, and a client, whose main system possibilities can be summed up in:
  • Figure 1 shows a schematic representation of a preferred form of implementation of the system of the invention.
  • the HOST 1 device central processor
  • the HOST 1 device associated with the entity in question can be seen first, for example a financial entity such as a Bank or the like, linked to a first server 2, through protocols 3, existing further a first database 4 in relation to said server 2; similarly, said server 2 is located connected to a second server 6 through protocols 5, there is also a second database 7 associated with this other server 6;
  • a third server 9 is attached to the previous one by means of protocols indicated graphically with reference 8, the latter constituting a communications port for the purpose of controlling the number of messages per temporal space, as will be explained later.
  • the communication is carried out with the use of protocols identified with the numerical reference 10, and so that each communications operator 11 performs the transformation of the proprietary protocol into their respective protocols 12, to Issuance 13 of the message that corresponds to the end user.
  • the basic structure of the circuit presents a set of physical devices associated with the financial entity, trained to interact, through appropriate protocols, with the different communications operators that may exist at any time, and through which it is carried After sending the corresponding message.
  • the conversation may be initiated by the client or by the entity, by sending a message.
  • conversations initiated by the entity may be carried out based on two differentiated situations, namely, i) at the initiative of the entity itself, or ii) by the occurrence of a particular event.
  • the entity may communicate to the client a decision or operation determined at the time it deems appropriate, while in the second case, if the entity is for example a Bank, the communication may be initiated when the client has made a specific operation that requires the intervention of the entity, for example a purchase made with a credit card and that requires financing by the entity.
  • the entity's HOST 1 device establishes communication with a first server 2, through protocols 3, which is responsible for initiating the session, storing the conversation status and the necessary parameters for the correct flow of the latter. in, for example, a database 4.
  • Server 2 establishes a connection with a second server 6 by means of protocols 5, to control the life cycle of the messages.
  • this second server 6 contains three main processes that have been identified with the reference numbers ⁇ a, ⁇ b, 6c.
  • a first thread 6a is intended to control the control data of the message (for example, the date and time of sending the message, whether or not it requires confirmation, ... etc.), in order to make the appropriate decision in base to such data.
  • the subprocess 6b is responsible, for example, for controlling the life cycle of the messages, controlling actions such as if the deadline for sending and / or delivery to the final mobile device that arbitrarily or dynamically has occurred has expired. been established Thus, for example, if there is no confirmation of receipt or expiration of the message by the operator, the thread 6b destroys the message, sending confirmation of all this to the first server 2.
  • the third thread 6c contained in the second server 6, consists of a thread that runs periodically, and which is responsible for collecting the planned messages in a table of a database 7, and sending them to the corresponding operator 11 .
  • a given financial operation such as a loan or any other
  • this action can be communicated early in the morning (for example, at 8:00 a.m.), or at any other time previously planned by the system.
  • the third subprocess 6c mentioned controls the existence of messages that, at the convenience of the entity in question, intentionally block the output of new messages. This utility allows you to control, by For example, the excessive sending of messages to a device, blocking the output of new messages arriving from the first server 2, until, due to the occurrence of some predefined event, the output to that device is unlocked.
  • the set of the three processes associated with the second server 6 and described above allows, for example, when a message sending request arrives from the first server 2, both the deferred send time for execution is verified immediate or deferred, such as the device number to which it is to be addressed and its validity, and that the shipment is made.
  • the latter establishes communication with a third server 9, implemented as a communications port, with the use of the protocols referenced with 8, with the in order to control the number of messages per temporary space that is sent to each of the communications operators 11, in order to guarantee the flow of messages without exceeding the limits contracted with each of said operators 11.
  • the message Once the message has been issued, it enters the systems that the operators have established to make it reach the end user, and confirmation can also be made by those of the correct reception on the client's device.
  • the second server 6 mentioned is in charge of storing this data for the control of the conversation, and at the same time, sending it to the first server 2 where it can be used for the control of the conversation, and simultaneously sending it, for example, to the HOST device 1 for subsequent posting.
  • the end user receives a message telling him how to perform the proposed operation. That is, the client is informed of the conditions of the financial operation, logically with the limitations currently existing for the length of the SMS messages, in order to answer, if applicable, the option chosen, where appropriate, Among the different that may be offered with respect to said financial operation.
  • a preauthorized loan situation can be assumed with respect to which three terms are offered to the client.
  • the response format will be indicated in the message itself and will consist, for example, of a command recognized by the system (for example, PTM), a reference will vary depending on the operation (for example, 1 to indicate a year, or by also a session number in case the client maintains several at once), as well as some other reference (s) that may be necessary for the financial operation.
  • the SMS message must be sent by the customer to a number that will be indicated in the message initiated by the entity, or in cases where possible, it is sufficient to respond to the message received by the client.
  • the message is transmitted" by the SMS platforms of each of the operators 11, and enters the "gateways" designed for each operator.
  • These gateways transform each operator's protocol into the protocol known to the system (for example, HTTP / XML).
  • Servers 9 and 6 are transparent at this point in the process, except for the channeling of the message to the first server 2.
  • This first server 2 checks through the telephone number of the final device, if there is any conversation initiated by it, and if the message received matches any of the expected responses. In case the message does not match any of the expected ones, an error message is returned, the content of which will vary depending on the error that could be detected, and which will be issued through the same flow described above. In case of coincidence, said server 2 activates the corresponding conversation, executes the associated processes and starts the emission, if necessary, of a new message that will follow the same flow already described.
  • the issuance process composes the message based on the data received in the response of the end user by going to the systems, for example HOST, that are necessary to collect the information that the message must contain, updating all the data in the processes described previously.
  • the final device receives an SMS message, and responds to its agreement with the instructions received, following the flow of the conversation described above.
  • This flow has no limitation as to the number of output / input messages, and can be extended to infinity.
  • the first server 2 mentioned will control the end of the conversation, which will be produced following the logical flow previously defined for each conversation, and which is controlled by this server.
  • one of the outgoing SMS messages can request the end user to enter in one of their messages, the variable that corresponds to a security code (CS) known by both parties, and that allows the full identification of the person that interacts with the final device.
  • CS security code
  • this variable is correct and corresponds to what the session control is waiting for, the operation is executed, for example an economic transaction, for example in the entity's HOST 1 device.
  • the first server 2 controls the response of, for example, the HOST device 1, and issues a confirmation message to the user, following the same procedures described above, and terminating the conversation if so defined in the flow of each specific process.
  • the format of the SMS that the client initiates must contain, in the first or in some of the messages that leave his device, a security key or PIN (Personal Identification Nurnber, or Personal Identification Number), which gives you access to that type of information.
  • PIN Personal Identification Nurnber, or Personal Identification Number
  • This PIN number will be defined by each specific application, or it may be common for a group of applications, depending on the service you want to provide and the degree of security you want to obtain for such identification.
  • both the PIN and the security code (CS) cited above may be controlled by subsystems independent of the one just described, depending on the degree of security required.
  • the system of the invention although it also follows a system pattern (command + references), the only pattern that the client should know is when to start the conversation / session.
  • the client is indicated which is the pattern to be used to continue the conversation / session, and in addition the system has also foreseen the alternative possibility of giving the commands a certain degree of "intelligence" , so that, for example, in the case of a Bank-type financial entity, if "LOAN” is written instead of "PTM", the system is able to recognize it.
  • protocols used for establishing communication between the various system components will be any capable of adapting to the characteristics of the designed system, although protocols of type HTTP / XML, MQ Series, or the like are preferred.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Evolutionary Computation (AREA)
  • Signal Processing (AREA)
  • Geometry (AREA)
  • General Engineering & Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Finance (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Se describe un sistema mediante el que resulta posible establecer conversaciones entre una entidad, por ejemplo una entidad financiera tal como un Banco o similar, y un cliente final, pudiendo ser las conversaciones iniciadas tanto por la entidad como por el cliente, y utilizando para ello el envío de mensajes cortos SMS. El sistema incluye un conjunto de componentes, entre los que se distingue un HOST de la entidad, un primer servidor con una primera base de datos asociada, un segundo servidor implementado como puerto de comunicaciones y a través del cual se accede a las distintas operadoras y a través del cual se accede a las distintas operadoras de comunicaciones para el establecimiento de las conversaciones con los clientes finales. El sistema prevé también la posibilidad de acceso a información de carácter restringido con la utilización de claves personales de acceso para cada aplicación o grupo de aplicaciones.

Description

"SISTEMA MULTICLIENTE/MULTICONVERSACIÓN PARA LA
EEALISACIÓKf DE TR&EϊS CCIOϊϊES ΞCONO IC S ϊ/O ACCEDER A INFQR&EkCIQN MEDIANTE MENSAJES SMS"
DESCRIPCIÓN
Objeto de la Invención
La presente invención se refiere a un sistema multicliente/multiconversación para la realización de transacciones económicas y/o acceder a información mediante mensajes SMS, que aporta esenciales características de novedad y notables ventajas con respecto a los medios conocidos y utilizados para los mismos fines en el estado actual de la técnica.
Más en particular, la invención propone el desarrollo de un sistema para la realización de operaciones mediante la utilización de mensajes cortos SMS, con una multiplicidad de capacidades implementadas que aseguran operaciones entre, por ejemplo, una entidad financiera y un cliente o usuario determinado, de forma fácil y cómoda, y con un elevado nivel de seguridad. El sistema está configurado según dos modos operativos, de manera que la conversación puede ser iniciada tanto por el cliente como por la entidad, mediante el envió de un mensaje, y admitiendo en el último caso dos alternativas correspondientes al inicio de las conversaciones por iniciativa de la entidad, o bien se activan cuando se produce un determinado evento. El sistema prevé también la provisión de informaciones confidenciales con la utilización de algún tipo de clave de seguridad que identifique al usuario.
El campo de aplicación de la invención se encuentra comprendido dentro del sector de las telecomunicaciones en general, y en particular de la interacción entre una entidad (por ejemplo, un Banco) , y los clientes de la entidad.
Antecedentes y Sumario de la Invención
Es conocido por todos en general, las crecientes capacidades operativas ofrecidas por ciertas entidades para la atención a los clientes sin necesidad de que éstos hayan de acudir físicamente a la entidad, o al menos no tengan que hacerlo durante horarios laborales normales. En el caso concreto de los Bancos, constituyen probablemente el sector de negocio que mayor grado de comunicación ha alcanzado en este sentido, empezando por los cajeros automáticos, a través de los cuales resulta posible operar a cualquier hora, y siguiendo con el acceso del cliente a los diversos servicios bancarios sin necesidad de desplazamiento fisico, gracias a la implementación de redes de comunicación de tipo Internet o similar. Adicionalmente, en la actualidad el campo operativo se está viendo incrementado merced a la utilización de la telefonía móvil, y en especial al envió de mensajes cortos SMS para el establecimiento de las conexiones entre dos puntos alejados.
La presente invención pertenece precisamente al sector comentado en lo que antecede, y propone la implementación de un sistema mediante el que se pueden realizar transacciones económicas entre una entidad, por ejemplo un Banco, y un cliente, cuyas posibilidades principales de sistema se pueden resumir en:
- Mantenimiento de varias conversaciones simultáneas con un mismo cliente;
- Mantenimiento de conversaciones con varios clientes a la vez;
- Capacidad de inicio de la conversación por parte del administrador del sistema, o por parte del usuario final; - Incorporación de medios de seguridad suficientes en función del uso que se desee hacer del sistema;
- Conexión con varias operadoras telefónicas;
- Posibilidad de inicio de las conversaciones cuando se produzcan ciertos eventos; - Posibilidad de aplicación directa a cualquier sector económico, y
Capacidad para la realización de transacciones económicas, acceso restringido a información, o simple consulta pública. - Conexión a través de distintos protocolos.
Ya se conocen en el estado actual de la técnica, algunos documentos que describen sistemas destinados a aplicaciones similares a la propuesta por la invención. En este sentido, se puede citar en especial el documento de Patente PCT núm. F-198/00250, relativa a un método de utilización de los servicios bancarios a través de una radio digital .móvil, con la utilización de mensajes SMS, dirigidos a un centro de servicio de mensajes cortos, y enrutados a un servidor de interfaz de usuario, siendo los datos transferidos desde este último hasta la unidad de autoservicio del Banco. Este método, aunque supone un avance considerable en el campo de aplicación al que va destinado, adolece del inconveniente de que permite una conversación muy básica, y no permite retomar sesiones inicial ente abiertas con el usuario en el momento exacto en que se paralizaron.
Breve Descripción de los Dibujos
Estas y otras características y ventajas de la invención, se pondrán más claramente de manifiesto a partir de la descripción detallada que sigue de una forma preferida de realización, dada únicamente a titulo de ejemplo ilustrativo y no limitativo, con referencia a los dibujos que se acompañan, en los que:
La Figura 1 muestra una representación esquematizada de una forma preferida de implementación del sistema de la invención.
Descripción de una Forma de Realización Preferida Tal y como se ha indicado en lo que antecede, la descripción detallada de la forma de realización preferida de la invención va a ser llevada a cabo en lo que sigue con la ayuda de los dibujos anexos, cuya Figura única muestra una representación gráfica, esquematizada, del sistema de la invención, y a cuyos componentes se les han asignado referencias numéricas correspondientes. Asi, se aprecia en primer lugar el dispositivo HOST 1 (procesador central) asociado a la entidad de que se trate, por ejemplo una entidad financiera tal como un Banco o similar, unido a un primer servidor 2, a través de protocolos 3, existiendo además una primera base de datos 4 en relación con dicho servidor 2; del mismo modo, dicho servidor 2 se encuentra conectado a un segundo servidor 6 a través de protocolos 5, existiendo además una segunda base de datos 7 asociada a este otro servidor 6; a continuación, aparece un tercer servidor 9 unido al anterior mediante protocolos indicados gráficamente con la referencia 8, constituyendo este último un puerto de comunicaciones con propósitos de control del número de mensajes por espacio temporal, como se explicará mas adelante. Entre el puerto de comunicaciones 11 y las distintas operadoras 11, la comunicación se realiza con la utilización de protocolos identificados con la referencia numérica 10, y de modo que cada operadora de comunicaciones 11 realiza la transformación del protocolo propietario en sus protocolos 12 respectivos, para la emisión 13 del mensaje que corresponda al usuario final.
Como se puede apreciar, la estructura básica del circuito presenta un conjunto de dispositivos físicos asociados a la entidad financiera, capacitados para relacionarse, mediante protocolos apropiados, con las distintas operadoras de comunicaciones que puedan existir en cada momento, y a través de las cuales se lleva a cabo el envió del mensaje correspondiente.
El funcionamiento del sistema de la invención, va a ser descrito en lo que sigue.
Tal y como se indicó al comienzo de la descripción, la conversación podrá ser iniciada por el cliente o por la entidad, mediante el envió de un mensaje. Normalmente, aunque no necesariamente, el proceso más largo corresponderá con el iniciado por la entidad. A su vez, las conversaciones iniciadas por la entidad podrán llevarse a cabo en función de dos situaciones diferenciadas, a saber, i) por iniciativa de la propia entidad, o ii) por la ocurrencia de un determinado evento. Asi, en el primer caso, la entidad podrá comunicar al cliente una decisión u operación determinada en el momento que considere pertinente, mientras que en el segundo caso, si la entidad es por ejemplo un Banco, la comunicación podrá iniciarse cuando el cliente ha realizado una operación determinada que requiera la intervención de la entidad, por ejemplo una compra realizada con una tarjeta de crédito y que requiere financiación por parte de la entidad.
En ambos supuestos, el dispositivo HOST 1 de la entidad, establecen comunicación con un primer servidor 2, por medio de protocolos 3, el cual se encarga de iniciar la sesión, almacenando el estado de conversación y los parámetros necesarios para el correcto flujo de ésta en, por ejemplo, una base de datos 4. El servidor 2 establece conexión con un segundo servidor 6 mediante protocolos 5, para controlar el ciclo de vida de los mensajes. Como se puede apreciar en la representación gráfica de la Figura 1, este segundo servidor 6 contiene tres procesos principales que han sido identificados con los números de referencia βa, βb, 6c. Un primer subproceso 6a, se destina a controlar los datos de control del mensaje (por ejemplo, la fecha y hora de envió del mensaje, si requiere o no confirmación, ... etc.), con el fin de tomar la decisión oportuna en base a tales datos. Asi, si se recibe en 6a un mensaje enviado desde el primer servidor 2 cuya fecha de caducidad es anterior a la fecha del sistema, dicho mensaje es devuelto al citado primer servidor 2. También se ha previsto controlar en 6a otros factores, tales como, por ejemplo, la existencia de un dispositivo móvil al que dirigirse, o cualquier otro dato que sea necesario para acceder al cliente final.
Por su parte, el subproceso 6b se encarga, por ejemplo, de controlar el ciclo de vida de los mensajes, controlando acciones tales como si se ha producido la caducidad del plazo de envió y/o entrega al dispositivo móvil final que arbitraria o dinámicamente haya sido establecido. De este modo, por ejemplo, si no existe confirmación de recepción o expiración del mensaje por parte de la operadora, el subproceso 6b destruye el mensaje, enviando confirmación de todo ello al primer servidor 2.
Por último, el tercer subproceso 6c contenido en el segundo servidor 6, consiste en un subproceso que se ejecuta periódicamente, y que se encarga de recoger los mensajes planificados en una tabla de una base de datos 7, y enviarlos a la operadora 11 que corresponda. Por ejemplo, si una operación financiera determinada, tal como un préstamo u otra cualquiera, se genera durante la noche (por ejemplo, un préstamo preautorizado que se genera a las 3:00 de la madrugada) , esta acción puede ser comunicada a primera hora de la mañana (por ejemplo, a las 8:00 h) , o en cualquier otro momento previamente planificado por el sistema. El tercer subproceso 6c mencionado controla la existencia de mensajes que, a conveniencia de la entidad de que se trate, bloqueen intencionadamente la salida de nuevos mensajes. Esta utilidad permite controlar, por ejemplo, el envió excesivo de mensajes a un dispositivo, bloqueando la salida de los nuevos mensajes que lleguen desde el primer servidor 2, hasta que en virtud de la ocurrencia de algún evento predefinido, se desbloquee la salida hacia ese dispositivo.
El conjunto de los tres procesos asociados al segundo servidor 6 y descritos en lo que antecede, permite asi que, por ejemplo, cuando llega desde el primer servidor 2 una petición de envió de mensaje, se compruebe tanto la hora de envió diferido para su ejecución inmediata o diferida, como el número de dispositivo al que ha de dirigirse y su validez, y que se realice el envió.
Una vez que los procesos 6a, 6b, 6c anteriores han sido llevados a cabo en el segundo servidor 6, este último establece comunicación con un tercer servidor 9, implementado como puerto de comunicaciones, con la utilización de los protocolos referenciados con 8, con el fin de controlar el número de mensajes por espacio temporal que se envia a cada una de las operadoras de comunicaciones 11, con el fin de garantizar el flujo de mensajes sin rebasar los límites contratados con cada una de dichas operadoras 11.
Mediante ciertos protocolos 10, los "gateways" (o accesos de comunicación) de comunicación directa con las operadoras 11, transforman el protocolo propietario descrito hasta ahora, en los protocolos correspondientes a cada una de las operadoras de comunicaciones. una vez que se ha emitido el mensaje, éste entra en los sistemas que las operadoras tengan establecidos para hacerlo llegar hasta el usuario final, pudiéndose realizar también la confirmación por parte de aquellas, de la correcta recepción en el dispositivo del cliente. El segundo servidor 6 citado es el encargado de almacenar este dato para el control de la conversación, y a la vez, enviarlo al primer servidor 2 donde puede ser utilizado para el control de la conversación, y simultáneamente enviarlo, por ejemplo, al dispositivo HOST 1 para su posterior contabilización.
El usuario final (es decir, el cliente de la entidad) , recibe un mensaje en el que se le indica cómo realizar la operación propuesta. Es decir, al cliente se le informa de las condiciones de la operación financiera, lógicamente con las limitaciones actualmente existentes para la longitud de los mensajes SMS, con el fin de que conteste, en su caso, a la opción elegida, en su caso, entre las distintas que se le puedan ofrecer respecto a dicha operación financiera. En un caso de aplicación concreta, se puede suponer una situación de préstamo preautorizado respecto al que se le ofrecen tres plazos al cliente. El formato de respuesta vendrá indicado en el propio mensaje y constará, por ejemplo, de un comando reconocido por el sistema (por ejemplo, PTM) , una referencia variará en función de la operación (por ejemplo, 1 para indicar un año, o por también un número de sesión en caso de que el cliente mantenga varias a la vez), así como alguna (s) otra(s) referencia (s) que pueda (n) ser necesaria (s) para la operación financiera. El mensaje SMS deberá ser remitido por el cliente a un número que estará indicado en el mensaje iniciado por la entidad, o en los casos en que sea posible, bastará con responder al mensaje recibido por el cliente.
Una vez que el cliente ha respondido, puede ocurrir que la respuesta sea incorrecta (por ejemplo, si falta una variable o esa variable no está entre las admitidas) , en cuyo caso y siguiendo el proceso que se va a describir a continuación, recibirá un nuevo mensaje donde se le indica la forma de corregir el error.
En cualquier caso, tanto si la respuesta es correcta como si no lo es, el mensaje "se transmite" por las plataformas SMS de cada una de las operadoras 11, y entra en los "gateways" diseñados para cada operadora. Estos "gateways" transforman el protocolo de cada operadora en el protocolo conocido por el sistema (por ejemplo, HTTP/XML) .
Los servidores 9 y 6, son transparentes en este punto del proceso, excepto para la canalización del mensaje hacia el primer servidor 2.
Este primer servidor 2 citado, comprueba a través del número de teléfono del dispositivo final, si existe alguna conversación iniciada por él mismo, y si el mensaje recibido coincide con alguna de las respuestas esperadas. En caso de que no coincida el mensaje con alguno de los esperados, se devuelve un mensaje de error, cuyo contenido variará en función del error que se haya podido detectar, y que será emitido a través del mismo flujo descrito anteriormente . En caso de coincidencia, dicho servidor 2 activa la conversación correspondiente, ejecuta los procesos asociados e inicia la emisión, en caso de necesidad, de un nuevo mensaje que seguirá el mismo flujo ya descrito. El proceso de emisión compone el mensaje en función de los datos recibidos en la respuesta del usuario final acudiendo a los sistemas, por ejemplo HOST, que sean necesarios para recopilar la información que ha de contener el mensaje, actualizando todos los datos en los procesos descritos anteriormente.
El dispositivo final recibe un mensaje SMS, y responde su acuerdo con las instrucciones recibidas, siguiendo el flujo de la conversación descrito anteriormente. Este flujo no tiene ninguna limitación en cuanto a número de mensajes de salida/entrada, pudiendo extenderse hasta el infinito.
El primer servidor 2 mencionado, controlará el final de la conversación, que se producirá siguiendo el flujo lógico definido previamente para cada conversación, y que está controlado por este servidor.
Cuando sea necesario, uno de los mensajes SMS salientes puede solicitar al usuario final la introducción en uno de sus mensajes, de la variable que corresponda a un código de seguridad (CS) conocido por ambas partes, y que permita la identificación plena de la persona que interactúa con el dispositivo final. Así, por ejemplo, se puede pedir que se introduzca una clave contenida en una tarjeta física que previamente ha sido puesta a disposición del usuario final, o cualquier otro método que permita la plena identificación del cliente y sea a la vez suficientemente robusta como para garantizar la seguridad que en cada caso se requiera. Cuando esta variable sea correcta y corresponda con la que el control de la sesión está esperando, se ejecuta la operación, por ejemplo una transacción económica, por ejemplo en el dispositivo HOST 1 de la entidad.
En este caso, y cuando sea necesario, el primer servidor 2 controla la respuesta de, por ejemplo, el dispositivo HOST 1, y emite un mensaje de confirmación al usuario, siguiendo los mismos procedimientos descritos en lo que antecede, y dando por finalizada la conversación si así se ha definido en el flujo de cada proceso concreto.
También, según se indicó al comienzo de la descripción del funcionamiento del sistema de la invención, puede ser el cliente quién inicie la conversación. Los flujos son, en general, los mismos que han sido descritos hasta ahora, pero con algunas modificaciones en cuanto a la forma en que los subprocesos de los servidores 6, 2 realizan su tarea, así como en cuanto al acceso a, por ejemplo, el dispositivo HOST 1.
Existen también algunas consideraciones especiales en lo que se refiere, por ejemplo, a situaciones en las que el dispositivo final solicita alguna información que tiene, por ejemplo, carácter confidencial o restringido (como puede ser el caso de, por ejemplo, petición del saldo de una cuenta corriente bancaria) . En los casos que sea necesario, el formato del SMS que el cliente inicia, deberá contener, en el primero o en alguno de los mensajes que salen de su dispositivo, una clave de seguridad o PIN (Personal Identification Nurnber, o Número de identificación Personal) , que le proporcione el acceso a ese tipo de información. Este número PIN será definido por cada aplicación concreta, o podrá ser común para un grupo de aplicaciones, en función del servicio que se quiera prestar y del grado de seguridad que se desee obtener para tal identificación .
También, como característica adicional, tanto el PIN como el código de seguridad (CS) citados en lo que antecede, podrán ser controlados por subsistemas independientes del que se acaba de describir, dependiendo del grado de seguridad que se requiera.
Adicionalmente, y a diferencia con otros sistemas de la técnica anterior en los que se utilizan mensajes patrón en los que el usuario debe "rellenar" los campos, pero la posibilidad de diálogo es muy limitada, el sistema de la invención, aunque también sigue un sistema patrón (comando + referencias) , el único patrón que debe conocer el cliente consiste en cuándo ha de iniciar la conversación/sesión. Cada vez que se emite un mensaje, se indica al cliente cuál es el patrón que ha de utilizar para continuar la conversación/sesión, y además el sistema ha previsto también la posibilidad alternativa de dotar a los comandos de un cierto grado de "inteligencia", de modo que, por ejemplo, en el caso de una entidad financiera de tipo Banco, si se escribe "PRÉSTAMO" en vez de "PTM", el sistema sea capaz de reconocerlo.
Como se comprenderá, la descripción que antecede ha sido realizada con vistas a una aplicación concreta para el establecimiento de conversaciones entre una entidad que en concreto se cita como un Banco, y un cliente final. Sin embargo, esta forma de descripción ha sido elegida únicamente con el fin de ilustrar la invención y hacer que la misma resulte más fácilmente comprensible, por lo que en ningún caso debe ser entendida como limitativa, sino que, muy al contrario, la invención puede ser aplicada a otros muchos sectores de la técnica en los que se requiera una interacción entre una determinada entidad de cualquier tipo, y un cliente final.
También, debe aclararse que los protocolos utilizados para el establecimiento de comunicación entre los diversos componentes del sistema, serán cualesquiera capaces de adaptarse a las características del sistema diseñado, aunque se prefieren protocolos de tipo HTTP/XML, MQ Series, o similares.
Por último, la descripción del sistema realizada en lo que antecede, ha sido llevada a cabo en su forma de implementación más simple. No obstante, debe tenerse presente que el diseño del sistema permite el establecimiento de múltiples conversaciones simultáneas con múltiples clientes, sin necesidad de modificación alguna de los componentes que lo integran.
No se considera necesario hacer más extenso el contenido de esta descripción para que un experto en la materia pueda comprender su alcance y las ventajas derivadas de la invención, así como desarrollar y llevar a la práctica el objeto de la misma. No obstante, debe entenderse que la invención ha sido descrita según una realización preferida de la misma, por lo que puede ser susceptible de modificaciones siempre que ello no suponga alteración alguna del fundamento de dicha invención.

Claims

REIVINDICACIONES
1.- Sistema multicliente/multiconversación para la realización de transacciones económicas y/o acceder a información mediante mensajes SMS, mediante el que resulta posible el establecimiento controlado de conversaciones entre una entidad, por ejemplo una entidad financiera, y un usuario final, con la utilización de mensajes cortos, para el planteamiento, control y conformidad de una operación financiera entre la entidad y el cliente, que se caracteriza porque el sistema comprende: un dispositivo HOST (1) asociado a la entidad financiera; un primer servidor (2) , conectado a dicho dispositivo HOST, que se encarga de iniciar la sesión, y al que se asocia una primera base de datos (4) para almacenaje del estado de la conversación y de los parámetros necesarios para el flujo correcto de aquella; un segundo servidor (6) , conectado al primer servidor (2) , en el que se lleva a cabo el control del ciclo de vida de los mensajes, y el cual incluye una segunda base de datos (7) ; y un tercer servidor (9) , implementado como puerto de comunicaciones, conectado al segundo servidor (6), en el que se efectúa un control del número de mensajes por unidad de tiempo, y desde el que se realiza el envío hasta cada una de las operadoras de comunicaciones (11) garantizando el flujo de mensajes sin rebasar los límites contratados con cada operadora de comunicaciones (11) , y porque el establecimiento de la comunicación entre los componentes del sistema se lleva a cabo con la utilización de protocolos apropiados, con preferencia protocolos de tipo HTTP/XML, MQ Series, u otros de naturaleza similar.
2.- Sistema según la reivindicación 1, que se caracteriza porque el segundo servidor (6) incorpora tres subprocesos (6a, 6b, 6c) de control de datos, de los que un primer subproceso (6a) se encarga de controlar los datos de control del mensaje, tales como fecha y hora de envío, necesidad o no de confirmación, etc., e incluso la devolución del mensaje en caso de que la fecha de caducidad sea anterior a la fecha del sistema; un segundo subproceso
(6b) que se encarga de controlar el ciclo de vida de los mensajes, incluyendo la destrucción del mensaje en caso de que no exista confirmación de recepción o expiración del mensaje por parte de la operadora de comunicaciones (11) ; y un tercer subproceso (6c), que se ejecuta periódicamente, y que se encarga de recoger los mensajes planificados en una tabla de la base de datos (7) asociada, y enviarlos a la operadora de comunicaciones correspondiente.
3.- Sistema según una de las reivindicaciones 1 ó 2, que se caracteriza porque está diseñado para admitir el inicio de las conversaciones tanto por parte de la entidad como por parte del cliente final.
4.- Sistema según una o más de las reivindicaciones 1 a 3, que se caracteriza porque incluye además la capacidad de proporcionar al cliente final información de carácter confidencial o restringido con la utilización de una clave o número PIN definidos para cada aplicación concreta o grupo de aplicaciones, y que en su caso podrán estar controlados por subsistemas independientes en función del grado de seguridad requerido.
PCT/ES2003/000192 1999-06-03 2003-04-30 Sistema multicliente/multiconversación para la realización de transacciones económicas y/o acceder a información mediante mensajes sms WO2004098215A1 (es)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP03720593A EP1624706A1 (en) 2003-04-30 2003-04-30 Multi-client/multi-conversation system for carrying out financial transactions and/or accessing information by means of sms messages
US10/554,729 US20070094111A1 (en) 1999-06-03 2003-04-30 Multiclient/multiconversation system for carrying out financial transactions and/or accessing information by means of sms messages
PCT/ES2003/000192 WO2004098215A1 (es) 2003-04-30 2003-04-30 Sistema multicliente/multiconversación para la realización de transacciones económicas y/o acceder a información mediante mensajes sms
AU2003224181A AU2003224181A1 (en) 2003-04-30 2003-04-30 Multi-client/multi-conversation system for carrying out financial transactions and/or accessing information by means of sms messages

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/ES2003/000192 WO2004098215A1 (es) 2003-04-30 2003-04-30 Sistema multicliente/multiconversación para la realización de transacciones económicas y/o acceder a información mediante mensajes sms

Publications (1)

Publication Number Publication Date
WO2004098215A1 true WO2004098215A1 (es) 2004-11-11

Family

ID=33396243

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/ES2003/000192 WO2004098215A1 (es) 1999-06-03 2003-04-30 Sistema multicliente/multiconversación para la realización de transacciones económicas y/o acceder a información mediante mensajes sms

Country Status (4)

Country Link
US (1) US20070094111A1 (es)
EP (1) EP1624706A1 (es)
AU (1) AU2003224181A1 (es)
WO (1) WO2004098215A1 (es)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004092967A1 (ja) * 2003-04-14 2004-10-28 Fujitsu Limited 対話装置、対話方法及び対話プログラム
US8849322B2 (en) 2010-10-11 2014-09-30 Cox Communications, Inc. Systems and methods for sharing threaded conversations on mobile communications devices

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997041654A1 (en) * 1996-04-29 1997-11-06 Telefonaktiebolaget Lm Ericsson Telecommunications information dissemination system
WO2000078067A1 (en) * 1999-06-11 2000-12-21 Telefonaktiebolaget Lm Ericsson (Publ) Arrangement for distributing stock exchange information to subscribers

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7216110B1 (en) * 1999-10-18 2007-05-08 Stamps.Com Cryptographic module for secure processing of value-bearing items
US7272662B2 (en) * 2000-11-30 2007-09-18 Nms Communications Corporation Systems and methods for routing messages to communications devices over a communications network
WO2002052798A2 (en) * 2000-12-22 2002-07-04 Research In Motion Limited Wireless router system and method
US7917888B2 (en) * 2001-01-22 2011-03-29 Symbol Technologies, Inc. System and method for building multi-modal and multi-channel applications
US8805739B2 (en) * 2001-01-30 2014-08-12 Jpmorgan Chase Bank, National Association System and method for electronic bill pay and presentment
CA2375844C (en) * 2001-03-09 2008-12-30 Research In Motion Limited Advanced voice and data operations in a mobile data communication device
EP1438673B1 (en) * 2001-09-26 2012-11-21 Interact Devices Inc. System and method for communicating media signals
US20040198322A1 (en) * 2002-04-12 2004-10-07 Infospace, Inc. Method and system for session management of short message service enabled applications
US7496687B2 (en) * 2002-05-01 2009-02-24 Bea Systems, Inc. Enterprise application platform

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997041654A1 (en) * 1996-04-29 1997-11-06 Telefonaktiebolaget Lm Ericsson Telecommunications information dissemination system
WO2000078067A1 (en) * 1999-06-11 2000-12-21 Telefonaktiebolaget Lm Ericsson (Publ) Arrangement for distributing stock exchange information to subscribers

Also Published As

Publication number Publication date
AU2003224181A1 (en) 2004-11-23
US20070094111A1 (en) 2007-04-26
EP1624706A1 (en) 2006-02-08

Similar Documents

Publication Publication Date Title
US8484128B2 (en) Method of implementing digital payments
JP4384117B2 (ja) データ処理システムのユーザーの認証方法及びシステム
US8332320B2 (en) Techniques for remote controlled physical transactions with dynamic key generation and authentication
US7865414B2 (en) Method, system and computer readable medium for web site account and e-commerce management from a central location
US8868458B1 (en) Remote account control system and method
ES2221379T3 (es) Metodo y aparato de sincronizacion dinamica y personalizacion de tarjetas inteligentes.
US11687894B2 (en) System and method for instant issue of personalized financial transaction cards
ES2359767T3 (es) Procedimiento y sistema de mensajería instantánea para terminales móviles equipados con un servidor de presencia virtual configurado para gestionar diferentes listas de contactos de un mismo usuario.
CN107306183A (zh) 客户端、服务端、方法和身份验证系统
CN103535090A (zh) 用于移动设备的身份管理的系统和方法
EP1433103A1 (en) Financial transaction system and method using electronic messaging
CN110073387A (zh) 证实通信设备与用户之间的关联
AU2007340015A1 (en) Mobile payment system and method using alias
CN112994892A (zh) 跨链交互方法、装置、系统和电子设备
JP2004506997A (ja) 資金メモリから電子的な金額を伝送する方法および装置
US20030050898A1 (en) Method and arrangement for the transmission of an electronic sum of money from a credit reserve
CN109711834A (zh) 一种区块链冷钱包的地址管理方法
RU2459248C2 (ru) Способ установления защищенной электронной связи между различными электронными устройствами, в особенности между электронными устройствами поставщиков электронных услуг и электронными устройствами потребителей электронной услуги
WO2004098215A1 (es) Sistema multicliente/multiconversación para la realización de transacciones económicas y/o acceder a información mediante mensajes sms
CA2779774A1 (en) Universal recognition platform
AU2000261898B2 (en) Method and system of communicating devices, and devices therefor, with protected data transfer
CN111179475B (zh) 一种离线生成临时密码的系统及方法
WO2000048146A1 (en) Method and system for the transmission of messages
KR20000037389A (ko) 무선휴대폰 혹은 이메일을 이용한 계좌이체중개시스템 및그 방법
CA3112731A1 (en) Cryptocurrency reward system

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SC SD SE SG SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2003720593

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2007094111

Country of ref document: US

Ref document number: 10554729

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 2003720593

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP

WWP Wipo information: published in national office

Ref document number: 10554729

Country of ref document: US